Project One Self Evaluation

The brief for project one was to create a 2D game, using GameMaker:Studio. A very broad brief, it gave me a lot of room to make decisions about what kind of game I wanted to create, what themes I wanted to explore, what stories I wanted to tell. I set about researching different styles of games and different games, trying to find something that I thought was a game I would want to create, whilst trying to be realistic in ambition as I only had six weeks to finish the project. I decided to make a top down shooter, with a wild west theme. I have had previous experience using GameMaker:Studio, and believed that with this prior knowledge that this kind of game was achievable in the given timeframe. I created design documents, production schedules, and after the end of a week of pre-production I was ready to begin development. However, before that I decided to re-familiarize myself with GameMaker:Studio, and with object-oriented design(OOD).

GameMaker:Studio is a 2D game development software program, that I have had some previous experience with, but before I began my first full project I wanted to understand the program more. GameMaker was created by Mark Overmars, as a game development tool intended to be both accessible to those new to programming and development, whilst also being a powerful tool in capable hands.

1. “Figure 1 shows the GameMaker interface, which uses an object-oriented, event-driven approach. With GameMaker’s drag-and-drop techniques, users can create games without writing a single line of code - but it also includes an interpreted programming language.” - Mark Overmars, creator of GameMaker: Studio

The program uses an object-oriented design approach, which is a common, modern industry standard method of development. When making games, literally everything in the game is an object, each with it’s own properties and behaviour. These objects and their behaviour will define outcomes when two object interact. Using an object-oriented approach has many different pros and cons:

Pros:

• Increased productivity - Working on individual objects allows for a modular approach to development, meaning that code is easy to maintain, easy to share with collaborators, and easy to reuse.
• Faster development - Increased productivity means faster development times, or the time to work further on certain aspects to perfect them.
• Cheaper development - Lower costs for developers means less reliance on publishers, which results in more original and inventive games.
• Iterative design - Code and objects that can be reused and adapted means that developers can quickly improve upon their previous games when making their next title.

Cons:

• Larger file sizes - Many different objects containing lots of lines of code results in larger files, which equates to more loading and worse performance.
• Slower programs - Calling lines of code from various objects slows the program, as does the increase in instructions that comes with OOD.
• Iterative design - Some developers see the ease at which code can be repurposed, and choose to make very similar games over and over, rather than creating original ideas.

2. “Iteration, as it’s generally known within game development, is the progressive process of planning, creating and testing content.  This is typically expressed as a cycle, where a process is repeated, with each repetition applying lessons learned from the prior.  This cycle is progressive, with each iteration building upon and refining the last.  This concept is widely embraced: many game developers have espoused iteration when discussing the design process.” - Matt Grandstaff, Community Manager at Bethesda Softworks

Gamemaker is an event driven program, meaning that the program is checking for certain events to happen each frame of the game. If one of these events returns true, then the actions specified by the developer will be carried out. This method of development allows the development to set up parameters for certain actions to occur under. Some common examples of events would be collisions, alarms, which would produce actions such as destroying the instance, or creating one.

I chose to develop my game using GameMaker-Language (GML), the coding language used within the program. Whilst you can create a game with the drag-and-drop interface, using GML gives more control over the actions and events in your game. Here are some examples of those events and actions I used within my game:


if keyboard_check_released(ord('R')) { room_restart();}

This piece of code is checking for the the event where the player presses and releases the 'R' key, which upon happening will carry out the action of restarting the room.

if keyboard_check_pressed(vk_escape) { game_end(); }

This piece of code is checking for the event where the player presses the 'escape' key, which upon happening will carry out the action of ending the game.

if x > room_width or x < 0 or y > room_height or y < 0 { instance_destroy(); }

This piece of code is checking for the event where the instance is leaving the room, which upon happening will carry out the action of destroying the instance.

Overall I believe that the project went well. The finished product at the end of the six weeks was a top down shooter, with a wild west theme. Admittedly, it wasn’t precisely what I envisioned the game turning out like, but given that this was my first experience of development, and considering the slender time constraints, I think that I have completed a good amount. The state that the game is currently in is one that can be built upon if desired, I’ve created a good foundation to move forward from.

An example of the level of coding I have achieved during this project

The main take away from this project is that I have learnt a lot. I have learnt practical skills, such as improving my knowledge of GML to the point where I can create scripts that interlink with each other, using equations consisting of variables called from various objects to produce outcomes in the form of actions. The quote below is from the first week of production, where I state that I was struggling with coding, to now, where I feel very confident with GML. Other skills I have learnt include using Photoshop and Illustrator, I have learnt about game feel, I have a better understanding of randomisation in games, and more. Alongside these practical skills, I have learnt a lot about how the development process works. I now understand more about the order in which to develop certain features, I learnt that some things take longer and other shorter than anticipated, I learnt the importance of sticking to a plan. This experience has taught me a lesson in managing expectations as well as time, and not to get carried away with adding features before I have accomplished what I set out to do.

3.  “The majority of my time and effort this week went towards random level generation. Gun Smoke has a pre-determined level layout, with 8 ‘room slots’ which are randomly filled from a list of around 15 different rooms. Getting the slots filled is easy, it’s tuning the composition of these rooms that proved difficult. Early tests resulted in three or four of the same room being thrown up on a level, which was undesirable. I’m no programmer, and after tussling with GameMaker for a few days, it became clear that programming wasn’t a natural talent of mine” - Jake Benbow

As I said previously, the project didn’t turn out quite as I had envisioned, and there were plenty of things that went wrong. The big example was that my game was supposed to be based around the player moving through different rooms and different levels, a system I had to completely cut out to the point of having one single room for the game because time was running out. This wasn’t an easy decision to make, as much of my work up until that decision had been creating that system, which in hindsight equates to a wasted two weeks of development. Other issues that arose were a change in art style to a more reductive aesthetic, not as many enemies and items being in the game as I would have liked. Art style was again due to a lack of time being available to me, whilst the enemies and items were due to myself not allotting enough time during development to create them as they threw up more issues than anticipated.

Upon finishing the game, I conducted a survey as part of the reflection process on how my finished game turned out. The survey creation program we used was SurveyMonkey, a platform which allows you to create your own questions and choose how they are answered. The questions covered topics such as gameplay, controls, graphics, audio, and the answer fields were star ratings out of five, with comment boxes for people to add some notes as to why they answered the way they did. This kind of feedback allows me to, at a glance, quickly see which areas of my game were successful and people liked, and those that people didn’t like so much. But with having comment boxes on the questions, it allows me to take a deeper dive into each question, to get a sense of not just what people liked or disliked, but why. Getting feedback on my game is important. With the game being a product of my own creation, it is hard to be objective about it’s qualities and faults, as there is an inherent bias and cynicism that comes with all creative work. So that’s why it’s important to seek the opinion of others, who can see your game in the cold light of day for exactly what it is, for better or for worse. I think that during my next projects, I will seek this kind of feedback at more regular intervals, to get this kind of feedback during a time where it can still affect the outcome of my project.

An example of the feedback I got from my survey, on one of the questions

4. “The sound is hard hitting and feels like you are truly impacting damage on the enemies and makes the game that more immersive.” - Anonymous Survey Answerer

This project has been a very good experience for me. It’s my first finished game, it’s the first proper project I had completed in games, and that has come with plenty of lessons about what I can do and what I need to work on. The common theme amongst the issues that arose was time. Undoubtedly if I had more time to develop my game then I would have a more fleshed out experience, but ultimately this comes back around to my planning. When presented with the brief, I knew I had just six weeks in which to create it, yet I gave myself too much work. This has been a learning experience, and now I have more of an idea of what level I can achieve in a given timeframe, knowledge that will help me massively in my future projects.

Bibliography:

1. Mark Overmars - Learning Object Oriented Design by Creating Games file://academic.ncn.ac.uk/students/Home/2015/41264192/Downloads/overmars_04_learning_object_oriented.pdf
2. Matt Grandstaff - The Iterative Level Design Process of Bethesda Game Studios http://fr.bethblog.com/2014/06/16/the-iterative-level-design-process-of-bethesda-game-studios/
3. Jake Benbow - Jake’s Game Design Blog http://jakesdesignstuff.blogspot.co.uk/2016/10/end-of-production-week-one-random.html
4. Anonymous Survey Answerer - Gun Smoke Survey https://www.surveymonkey.com/analyze/jvy2GtIPCTxcszYM3r_2F95d5H1oyXShY_2BmxaEUD2nZ8I_3D