Post Proposal Feedback Updates

Good evening, readers!


My grade for my Dissertation Proposal came in last week, prompting me to make this update informing you of any changes I will be making in light of recent feedback.

So, first of all, as it will be the first thing on most of your minds, my grade: it wasn't very good. A pass, of course, that's why I'm still going ahead with my dissertation, but still a low mark.



If you're not interested in why, then please skip the next few paragraphs.



Personally, I feel that my poor grade was due to a misunderstanding on my part regarding the word count. So, we were given a form with quite large fields for us to fill in and a long list of marking criteria at the bottom for us to refer to, which we then returned in full with all of our information on the dissertation.

We were also told that there was a hard word count limit, and if we went over that then the proposal would be declined.

Like an utter fool, I assumed that the rest of the form, the field headings, the explanations, and the marking criteria all counted toward the word limit. So, of course, I stripped out everything from my proposal that wasn't absolutely necessary, cutting the word count down to exactly the limit, but also removing almost all of the content.

When I handed the proposal in, it was apparently more than five-hundred words beneath the actual limit, was worded strangely in places, and included far less information than the tutors were looking for.

So, that's that. In future, I really need to actually ask about these things. I've asked for a chance to resubmit the proposal, but have been declined.



Alright, done with that. Moving on.



Following the feedback from the proposal, and other, earlier feedback, I have updated the Marking Criteria post to explain more about some of the less clear points, namely the provide more of an explanation about some of the points. Namely, I have expanded the explanation of my interpretation of "good coding practises", and reworded parts of the rest of it to be more specific and objective, rather than leaving it to the reader's interpretation.

Unfortunately, I can't directly tie any of the rest of the feedback given to me to anything other than a lack of content in the proposal itself. It was commented that my Dissertation title ("My Not-So-Brief Introduction to C#: A Series of Mini Projects") implies a lack of clarity and discipline; I intended for this to be informal and seem more friendly to the reader, though I can't really argue with the marker. Informal isn't going to help me in my career later down the line if I ever show this to a potential employer, but I'm not certain if I can change the name at this late stage. Something to ask about, I think.



Well, all things considered, that was a poor start to my dissertation. Other than the changes I've already made and attempting to alter the name to something more professional and descriptive, I can only do my best to work hard at the dissertation itself, and produce enough good quality work to make up for this.

I hope you have a cheerful time until the next post, readers.

Second Tutorial Phase Announcement

Apologies, readers, I know this post is a day late, but I am happy to announce that the second project is officially underway. The Tutorial Phase will be running from yesterday, the 24th of November, to this Sunday, the 30th.

I will be employing a written tutorial which details the creation of a first-person maze game with randomly generated elements, which can be found here:

http://catlikecoding.com/unity/tutorials/maze/

I'll create another post once the Tutorial Phase is complete, and I begin the Conversion Phase on Monday the 1st of December.

Until then, wish me luck, good readers, and have yourselves a very fine evening!

First Conversion Phase Complete!

Another fine day to you, readers.

Getting right down to the content of this post, I've more or less completed the prototype version of the first game project, which is as far as I plan to take it for the time being. It's been a lot of work, particularly this weekend, and a lot of staring at the screen wondering what's not working, but it's finally complete.

As it stands, the three layers of platforms move at different speeds as intended, the player character jumps towards the mouse cursor as intended, and the camera moves from left to right at a gradually increasing rate, just as intended. Falling off the bottom of the screen or falling behind to the left side will result in a fail state, and restart the game.

Now, sadly this prototype isn't even close to being as complete as I would like. There is a distinct lack of polish to it, giving the game a rather bare-bones feel, and it isn't without its bugs. The only notable bug at the moment is a  very serious (and often game-breaking) problem with the game over function, whereby the parallaxing layers of platforms won't reset properly. This typically leaves the character falling off the bottom of the screen continually, and forces the player to restart the game.

Otherwise, I haven't yet tried exporting the game for use outside of the Unity engine (which is bound to be all kinds of fun with figuring out window sizes and such), and there is also only a single level to be played, which doesn't change from playthrough to playthrough, or randomly generate its feature, resulting in very limited playability in the game's current state.

However, the level that is available feels very much like I hoped it would, and feels like a sufficient departure from the original mechanics I started with. Moreover, as much as I've playtested the game myself to craft the levels and ensure the code doesn't break under any typical circumstance, I'm still finding the game to be surprisingly enjoyable, and something I might play on and off if it had more levels.

The game screen upon conclusion. In the top-centre, you can see the full map of the first level, the goal point of which is the very small red flag near the right-hand-side.

There's something about the degree of challenge, combined with the difficult-yet-oddly-satisfying movement controls that leaves me laughing frustratedly every time I fall off a platform.

I'm considering revisiting this prototype later, and perhaps making a real game out of it (in my own time, of course). I'll also try to get it uploaded to UCS's WaterFrontGames website so that any of you readers can play it for yourselves.

For now, I'm going to stop there; it's late, I'm surprisingly tired, and I have an early start in the morning. Next week, we'll be undertaking the second project's Tutorial Phase.


Until then, I wish you readers a very happy evening and a wonderful goodnight.

First Conversion Phase, Update 1

Good evening, readers.

This will be a very short post to keep you appraised of my progress with the Conversion Phase of my first project. At this point, I've only put a couple of hours at most into the project, primarily fiddling with the project settings and scene.

The basic scene is set up in my Unity project, with player and a few placeholder platforms in place. I've used very simple, block-y art for the meantime, just to get the idea of layers of platforms across to the player through some simple colour. I'm using the same pre-made player Prefab that was featured in the Brackeys tutorial; it contains some pre-constructed code, but I'll have to break that down anyway, and it has some nice animations to it to make the game look a little nicer.

I've also got the player jumping on mouse click reasonably well, although there's a lot of work to get done with the movement. I still need to make sure the player jumps towards the mouse pointer, and then affect which layer of terrain they're jumping towards by the pointer's position on the game screen (higher for a more "distant" platform in relation to the camera view, lower for a "closer" platform).

I've thought about adding a vertical beam to each of the platforms, to help sell the player on the sense of movement, but that's more a problem of design than code, so it needs to take a lower priority.

After fixing player movement, I'll need to get the platforms moving towards the left side of the screen, towards the player character, and perhaps implement some degree of random delay between their spawning. That should just be manageable with a single Script without too much difficulty.

Overall, a slow start to the project, but there's plenty of time and I'm confident I know what to do next.

First Conversion Phase!

A fine day to you, good readers!

The Tutorial Phase for my first project is now over, leading us to the Conversion Phase. As you may recall, this is the part where I apply my newly acquired knowledge of C# to adapt the mechanics learnt in the Tutorial Phase to form a new style of gameplay.

As mentioned in previous posts, I have been learning the coding techniques from a platformer-style game over the last week. This means I have available to me movement and jumping mechanics, some basic shooting, a scrolling camera, and parallaxing layers of terrain.

Overall, the tutorial was less useful than I had hoped; for one thing, many pieces of fairly critical code were pre-made class files from the Unity3D website, which the tutorial's creator didn't bother to go over. I have and will continue to review these, though they appear at first glance to be somewhat more complex than the code demonstrated. Another problem was that, unknown to me at the start of this project, the tutorial was (and still is) not complete. This means that I will be working with only partial knowledge of the game being demonstrated and the techniques used, but this should hopefully be enough to get on with.

So, then, what is my plan for the Conversion Phase? What manner of game will I be making?

In the interest of helping me to learn what I can from the tutorial, and better understand certain key components (namely the parallax scrolling and mouse position calculations), as well as mildly amusing/irritating my tutors, I will be creating a variant of an endless runner style game.



In the game I have in mind, the player will control a character using only the mouse; when the player clicks the mouse button, the character will jump towards the pointer. This will be used in conjunction with multiple layers of moving platforms, advancing towards the player at different (and gradually increasing) speeds, which the player must jump between to avoid falling off the edge of the screen.



I very much like the idea of using the parallax scrolling in a more mechanical manner. In the tutorial, it was simply used to make different layers of the fore- and background terrain move at different speeds as the player explored the game world, creating a pleasant movement effect, but I think the technique has more potential to certain types of games.

I'll begin work on this game either tonight or tomorrow, depending on how much I sleep and how much work I need to perform for a different project. Updates here will follow when I start making some decent progress and with any luck, a decent version of the game I have in mind will be ready by this Sunday.



Please do wish me luck, readers. Have yourselves a fine afternoon.

First Tutorial Project Announcement

Hello, dear readers!

This is a very quick post to declare that I am beginning my First Tutorial Project. It will be running from now (the 10th of November) to Sunday the 23rd.

The tutorial I will be using is a YouTube video series for a simple platformer, created by Brackeys CEO, Asbjørn Thirslund.

https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c

As I have explained in previous blog posts, this project will be broken into two distinct segments: the Tutorial Phase, and the Conversion Phase. What I will convert the tutorial-demonstrated game into, I don't yet know, not fully understanding the mechanics that will be explained.

My planned changes will be announced in another blog post at the end of the Tutorial Phase, on Sunday at the latest.

Until then, readers, have a great week!

Academic Reading: Fundamentals of Game Design, Part 2

Hello again, good readers.

As promised, I have read parts of the chapter of Ernest Adams' book, Fundamentals of Game Design, Game Concepts. This should be particularly useful, as I will have to create and realize my own version of several games in the coming weeks, creating concepts based on and using existing mechanics.



Jumping straight into it, we are first adviced by Adams that finding an idea for a game is surprisingly easy; inspiration can be found in almost any source, just by looking at the world around you and thinking about how certain elements or processes could be used. Common sources of inspiration include the dreams and fantasies of the designer, other forms of entertainment media (such as films, books, or television), and even other games.

In these cases, however, the designer should take care not to steal the intellectual property of other people (creating a game directly based upon a movie without the consent of the owners of the rights to that movie, for example), and it should be remembered that good games are rarely formed around a single idea. Multiple ideas or inspirations should be used to flesh out a game concept.

When creating a game inspired by another game, Adams also warns that failing to add enough of your own creativity to the idea can (and in the past often has) leave a game which is unoriginal, or outright copies its source. Find a balance between innovation and the comfortably familiar.



This idea is not enough to be called a concept on its own, however. To advance to having a usable game concept, the designer must make many decisions about the game. Adams lists a number of elements important to creating a fully realized game concept, though in the unofficial and non-competitive context of my dissertation, as well as the limited time I will have with each project, developing the items he lists for each project would be not only unnecessary, but largely unrealistic.

I will use some of the methods he suggests to help flesh my game idea out for each final project (such as the high-concept statement, platforms, and primary gameplay mode), but will otherwise ignore this particular stage of game development, as it appears to be primarily intended for explaining the concept to others, such as when trying to pitch the game.



To help explain what Adams expects from a game concept, I'll go more in-depth with one of the points he says should be included in a game concept: a general summaryof how the game will progress. For this section, I will use my first final project idea (a simple top-down shooter) as an example.

When creating a lengthy game, the player should feel some sense of progress as they advance. This can be achieved by breaking the game into stages or levels, or by applying a narrative to the game, or both. Many games, for example, use a world map with a set number of levels shown on it to let the player view their progression through the game directly, counting how many levels they've already completed and how many they have left before finishing.

With the short amount of time available to me, I doubt I would be able to create a storyline for my game to offer the player, nor would it particularly emphasise coding aptitude beyond the presentation of the narrative. A level system, on the other hand, is probably very much accomplishable in the time I have, and would be effectively applicable in many future projects. These levels could take the form of a linear track, or could branch outwards into multiple paths the player can take, if I dedicate enough time to it.

Adams next asks what conditions should be met to complete a level. In a top-down shooter, there are a number of possibilities, the most obvious of which being shooting down a certain number of opponents. Other possibilities, however, include clearing and/or defending a particular area of the game world, reaching a location elsewhere in the world, or even completing small puzzles using the game's environment.

While Adams also goes into detail discussing storylines and whether they're necessary to a game, what they can offer, and how well the designer needs to understand the narrative at the game's conceptual stage, it doesn't offer us much help for this dissertation project series.



And that should about cover it for the Game Concepts chapter. I may refer back to this post later on in my dissertation, once I focus on the conceptualisation of my final projects, and may create posts going into more depth with this chapter if it becomes necessary.

For now, however, that should be all. The submission deadline for proposals is today, so please do wish me luck.

Until next time, good readers.



Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.

Academic Reading: Fundamentals of Game Design, Part 1

Good... morning, readers! (Good lord, is that the time?)

There is one element of my dissertation proposal that I've been putting off for a considerable amount of time: the academic reading. This is largely due to the fact that I had a great deal of difficulty thinking what I should (or could) read for the subject of my dissertation.

With the deadline fast approaching, however, I certainly couldn't put it off any longer, so I picked up some books and got to it.

In the end, I decided to use this portion of the dissertation to refresh and reinforce my knowledge of the fundamental elements of game design and creation.

Hence, one of the books I picked up from the library to go through was Ernest Adams' Fundamentals of Game Design. I will continue to read and refer to this book over the course of my dissertation, hopefully enabling me to produce better-realised games in at least the final project of each semester.

Going through it, I searched for areas that I would find helpful when conceptualising small or simple games, and how to boil a video game down to its essential elements.



The first section I read was entitled How Video Games Entertain.

Adams first emphasises here that, while a game is typically created to entertain, no one game will please every person. A good games designer should be able to produce games which entertain the player in a variety of ways, allowing them to target a specified audience every time they create a game.

Next, he highlights that the core entertainment value of a game lies in its gameplay, which hinges on the challenge the game lays out before the player. The player must have a reasonable expectation of being able to overcome this challenge, or else the game may seem unfair; if a powerful opponent is presented to the player, they should be able to believe that they in turn are suitably powerful enough to defeat it.

Gameplay, being at the centre of a game and the experience it offers, should be the first thing the designer considers when making a game.



Next, I delved into the factors that make a well-conceived video game, starting with The Key Components of Video Games.

Adams split this into Core Mechanics and User Interface: Core Mechanics generate the gameplay, defining the challenges of the game and the actions the player may take to overcome them, while the User Interface acts as a translator between the Core Mechanics and the player, converting input and output into something each can understand.

The example Adams offers is a player pressing a button to apply brakes in a driving game; the User Interface reads the button press, and tells the Core Mechanics to slow the car. The car slows, and the User Interface gives the player the appropriate animations and other visual and audio outputs to tell them that the braking has taken effect.

The User Interface can be broken down into two main elements: the interaction model and the camera model. The interaction model converts player input into actions within the game's Core Mechanics, while the camera model takes the events and challenges of the Core Mechanics and translates them for the player in the forms of images, sound, and/or other forms of output.



In the same chapter was a section entitled The Structure of a Video Game:

Adams explains that most games (except for the very simple) only present a subset of their complete gameplay at any one time. For example, a driving game could be split between driving the car and managing upgrades; two elements of the same game which offer starkly different challenges and actions available to the player (the player should not be allowed to purchase upgrades while driving, or to accelerate the vehicle while they're adding a better engine).

These different parts of a game are called gameplay modes.

Each gameplay mode should have a different User Interface from the others, necessary to give the player the appropriate feedback and input options.

Another element of a game's structure is shell menus. Shell menus typically exist before, in-between, and after segments of gameplay, during times when the player is unable to affect the game world. Examples of this are loading and saving the game, options menus, and often pause menus. If the pause menu allows the player to affect the game world in some way, though, such as purchasing upgrades, then it should be considered a gameplay mode rather than a shell menu.

Title screens, credit screens, and loading screens can be similarly termed shell screens, as they offer the player no interaction or feedback from the game's Core Mechanics.



This should do for the first post; after some further reading, I'll be back with my notes from the next chapter of Adams' Fundamentals of Game Design: Game Concepts.

Until then, stay well, readers.



Adams, Ernest. Fundamentals of Game Design, Second Edition. New Riders, Berkeley, CA, 2010.

A More Thorough Breakdown of the First Semester

A fine day to you, dear readers.

Following my previous post explaining the timetable for the first semester, it been recommended to me that I go into more depth about the games I will be creating, and the mechanics I'll be focusing on with them. Remember, my intended final project of this semester is a top-down shoot-'em-up.


So, straight into it with the First Tutorial Project:

I've chosen a fairly generic platformer tutorial series from YouTube to base my first project on.

https://www.youtube.com/playlist?list=PLPV2KyIb3jR42oVBU6K2DIL6Y22Ry9J1c

While platformers are considered (by developers, at least) to be fairly complex, I feel that this will carry a great deal of value for my final project in terms of mechanics, and will give me a strong knowledge basis to continue the project series on.

This tutorial will help me to produce the following relevant game mechanics:

• Precise controlled movement
• A scrolling camera
• Basic aim-and-shoot mechanics
• Scrolling backgrounds

This tutorial will cover the first two weeks of the practical part of my dissertation, spanning from Monday the 10th of November to Sunday the 23rd of November. As I have stated previously, in that time I will spend the first week (the 10th to the 16th) following the tutorial, and the second week (the 17th to the 23rd) using the same code to produce my own variant of the game, demonstrating my learning.

Next, the Second Tutorial Project:

The second project will use a text-based tutorial describing the creation of a maze game as its basis.

http://catlikecoding.com/unity/tutorials/maze/

The concept for this is fairly simple; the maze is created via random generation, and the player must explore the maze and find the way out from a first-person perspective.

This tutorial will provide me with the following mechanics and techniques:

• Simple randomly-generated three-dimensional environments
• A basic three-dimensional mini-map covering the level and player

This tutorial will span from Monday the 24th November to Sunday the 7th of December, the tutorial phase lasting from the 24th to the 30th, and the conversion phase lasting from the 1st to the end of the project on the 7th.

The Third Tutorial Project:

After a great deal of searching, I have had to settle for the final tutorial of the semester. The third tutorial describes the creation of a tower defence game in Unity; the problem with it is that the code is written in JavaScript, not C#.

https://www.youtube.com/playlist?list=PLRMBv-LswoRSfO5mbsX3Iv-VKRDl0JpF-

Being (somehow) unable to find a reasonably good quality tutorial for a similar game in English which uses C#, I have decided to simply use this tutorial and translate the code to the best of my ability as I go. It will certainly be challenging, but the rewards of studying a tower defence game should make it worth it:

• Object tracking (rotating one object to follow another)
• More advanced shooting mechanics
• AI pathing

This project will run from Monday the 8th to Sunday the 21st of December. The tutorial phase will conclude on Sunday the 14th, and the conversion phase will begin on Monday the 15th.

Lastly, The Final Project:

With all of the mechanics I will learn in the coming weeks, the final project should feature:

• Reasonably precise player movement
• A scrolling camera that follows the player around the game world
• Randomly generated environments
• A three-dimensional map of the game world, including the player's position
• AI opponents which track and follow the player with some basic pathing
• And, of course, a good deal of shooting (with player-controlled aiming)

The final project will be running over Christmas and into the new year, beginning on Monday the 22nd of December, and concluding on Friday the 16th of January. While I fully expect my progress to slow over Christmas, with four weeks and no time set aside for any tutorials, I'm confident I will be able to complete the project on time.

I'm frankly optimistic about this project series. I'm eager to begin, and looking forward especially to the final project where I'll really be able to play around with the code techniques I've already started learning, and will continue to discover in the coming weeks.

Before I can get to that, though, I do of course need to finish my proposal, the next part of which will be academic reading. More blog posts will follow with that and any other areas I need to add to.

Until then, have a glorious day, readers.

A More Realized Project Process, and Timetable for the First Semester

Good day, readers, I hope this post finds you well! Before anyone asks, yes, I have applied a new colour design to the blog; I was finding it difficult to read the old one, and it was rather boring and drab, I thought.

Anyway, onto business!

During the course of searching for tutorials and other sources of C# knowledge, I've been mulling over the project process my dissertation will follow, and with some inspiration from the sources themselves, I've come to what I think is a well-rounded timetable for my dissertation to follow during the rest of the academic year.

As stated previously, I'll be undergoing multiple smaller, tutorial-led game projects, leading up to a larger, more cohesive game project at the end of each semester, one at the beginning of January, and another perhaps due around Easter.

3 - 7 Nov	FRIDAY 7th NOVEMBER 4:00 PM SUBMISSION DEADLINE FOR PROJECT PROPOSAL
10 - 14 Nov	First Project – Tutorial Phase w/ progress updates on blog
17 - 21 Nov	First Project – Conversion Phase w/ progress updates and game breakdown on blog
24 - 28 Nov	Second Project – Tutorial Phase w/ progress updates on blog
1 - 5 Dec	Second Project – Conversion Phase w/ progress updates and game breakdown on blog
8 - 12 Dec	Third Project – Tutorial Phase w/ progress updates on blog
15 - 19 Dec	Third Project – Conversion Phase w/ progress updates and game breakdown on blog
22 - 26 Dec	First Semester Final Project
29 Dec - 2 Jan	First Semester Final Project
5 - 9 Jan	First Semester Final Project
12 - 16 Jan	First Semester Final Project – FRIDAY 16TH JAN 4:00 PM SUBMISSION DEADLINE FOR FINAL PROJECT

I have decided that the first of these final projects (due after the Christmas vacation) will be a simple top-down shoot-'em-up game built in Unity with its integrated C# functionality.

In preparation for this, I will undergo three projects, each lasting two weeks, following online tutorials, and producing a game unlike the one the tutorial originally demonstrates.

I'm aware that this is unhelpfully subjective, and something that I could conceivably talk my way out of when breaking down each game at the end of the project, so I'll be asking my tutors to judge if the product is sufficiently different from the tutorial to effectively demonstrate my ability to use code to achieve my own designs. If it isn't, then I will aim to perform better in the next project.

After these three projects, the final project, lasting approximately four weeks, will use as many of the mechanics and techniques I have learnt from the tutorials as possible in a single game (subject to whether or not they are appropriate), to be completed and submitted at the end of the semester, on Friday the 16th of January. I will be using the same submission deadline time as the project proposal, to ensure that it can be handed in via the same methods. This will also be just in time for the Project Presentations, to take place in the following week.

The second semester is harder to predict, as much of my planning and intended goals will be based on what I learn during the course of the first semester. What I can say for sure now is that I don't intend to use Unity, preferring to broaden my range of knowledge to cover other platforms. Otherwise, it will likely take a similar structure of tutorial-led projects, concluded by a final project at the end of the semester.

Hopefully that sufficiently explains my plans for the coming semester, and doesn't leave you with more questions than you came here with. If you do have any questions, readers, leave a comment and I will be more than happy to answer them.

Until the next post, good readers, I wish you a very fond farewell.

Mini Project Progress Update 2/2

Readers! Good evening!

Apologies for no update yesterday, I ended up focusing on other work that day, and made very little progress with the C# tutorials. Today, however, oh, such wonderful progress was made!

First of all, triggers for OnCollisionEnter and OnTriggerEnter; whenever one object bumps into another or goes inside a particular space, the function is called. Very useful for a great number of things, including death events, and in Unity surprisingly easy to accomplish.

Just as useful, and perhaps more exciting, is the knowledge of importing assets from modelling programs such as 3DS Max, and animating elements of them. This technique was only demonstrated with a simple spike trap in the game, but my mind is buzzing with possibilities to apply this to.

Among these treasures were some equally important pieces, including level setup and progression, delay timers in progressing mechanics, and applying relative force based on an object's orientation.

So much potential for my dissertation projects, I can't wait to lay into them.

Anyway, I think this is pretty much everything I needed from the tutorial, but I'm going to continue with the series for a few more ideas and techniques. I probably won't document them here unless I make a major breakthrough with anything.

For now, I need to focus on the final components of my dissertation proposal, including academic reading and finishing the timeline. Should be fun.

Until the next post, I wish you a very good day, readers.