Game Development with Jake @ QUT

A QUT Student studying Games and Science documenting his game design experience

[jakeharkins-gamedesign]

Why wont you add this to your website? Ill contact your prof abt this.

good luck

[jakeharkins-gamedesign]

do u agree?

yes cookiehau i agree

[jakeharkins-gamedesign]

i hate u so bad thats it thats my ask i just hate u sosososoooo much

i hate you too

[jakeharkins-gamedesign]

hey jake harkins game designs big fan here

yes :)

[jakeharkins-gamedesign]

Submission and Final Thoughts

As of today, A3 will finally be submitted and development on Cyber Flight will be finished. The development of this game has taught me a lot; it has shown me how much balance affects a game and has highlighted some issues in the way I implement balance. In future I would like to make balance changes much more often and try focus more time on implementing features.

Despite this I still am happy with the development of Cyber Flight, but it lacks some features that I would like to implement in future. Given more time and an engine with the ability to write in another language such as C# (GDevelop has some JavaScript implementation, but learning it throughout this semester wouldn't have changed the outcome I don't think) I think the final prototype would have been more fleshed out and resembled more of a complete game.

[jakeharkins-gamedesign]

Cyber Flight Postmortem

Overall the development of Cyber Flight was successful, playtesting feedback was generally positive and showed improvement over time. A focus on game balance and bug fixing led to an overall balanced game with only occasional bugs, but the game is still lacking in some areas.

Playtesting highlighted that the ability system is severely lacking, many players felt limited by only having one movement ability and most players did not use the bomb ability made available to them. This put most players at a significant disadvantage as they could not deal with large groups of enemies which leads to an uninteresting gameplay loop. Players were also dissapointed by the lack of pickups available to them as well, they did not feel rewarded for killing enemies as they could not see immediate feedback from each kill. Despite this, players still would like to play the game once these features are implemented.

If development was continued it would likely be moved to an engine such as Unity or Unreal, and based on feedback from playtesting would include the addition of new enemies, abilities and general balance tweaks. New enemies would use improved AI to give more varied attacks and provide different challenges for players. Bosses would also be added and also use improved AI to create unique challenges and abilities. The ability system would be extended to give players new movement options and ways to deal with large groups of enemies. The UI for Cyber Flight would also be reworked to ensure players are aware of the abilities made available to them, and would include changes for bosses, waves and new enemies.

[jakeharkins-gamedesign]

Week 14 General

Welcome to Week 14, the last week of development and the final push for A3. This week focusses on wrapping up development of Cyber Flight with a postmortem and some further content from Fullerton (2018), specifically Chapter 16. This chapter focusses on 'Selling Yourself and Your Ideas to the Game Industry'. Fullerton mentions that there is not one single way to get into the game industry; although, there are some common 'best' ways to get your foot in the door.

The first is to work as a developer or designer at an established games company. Working at an established company is the most practical way to enter the industry; working at these companies builds knowledge, skill and shows the kinds of talent that the industry needs. Networking and a well structured portfolio go a long way in trying to secure positions at these companies, the more you can show off and highlight your skills the better. This portfolio could include anything from level designs to game prototypes (assuming you've created some); these level designs could be for something new or a mod/addon for an older game. The second is pitching original game ideas to a publisher; keeping in mind the concepts covered in Chapter 13, where a well thought out plan and idea are a necessity to get publishers to even consider interviewing you. If you do land the interview there are a number of materials to bring, a sell-sheet is a great way to show publishers your game at a glance. A playable game demo is also beneficial, it can show publishers that the game is somewhat viable. After the interview it is best practice to ask when the publisher will be in contact to set the expectation that you continue to follow through with the pitch. The last option is to create and publish games as an independent. This has become more and more popular over the years, and can be a risk for designers as they often lack the necessary funding or man-power to see a project to completion. This doesn't mean that indie development/publishing hasn't been succesful and won't continue to be successful.

[jakeharkins-gamedesign]

Week 13 Development

This week's development is focussed on extending the abilities in the game and performing some final polish. This week will mark some of the last playtests and thus feedback will be limited on these changes.

Development this week is a mixed bag, changes were made prior, during and after the playtest. These changes give an interesting range of feedback, and good topics to talk about.

Pre-Playtest

Prior to playtesting enemy scaling was added, it's effect is minor and decreases the enemy spawn timer by 0.2 seconds per 15 enemies killed. This should give the feeling of being more difficult while being a simple addition. The feedback on this change from playtesters was minimal, all playtests conducted with this change were naive so players did not have a reference for difficulty.

During Playtest

During playtesting it was found that the game window size could be increased. Previously the game was played in a 800 x 600 window, which was changed to a 1920 x 1080 window. Interestingly, the size change significantly impacted the balance of the game. Enemies which previously shot from too far away now don't have enough range, and enemies now seem slower than before.

Both the spawning of enemies had to be adjusted to accomodate the new screen size, but mostly remains unchanged. Generally the feedback from the size change was positive; players enjoyed the larger size as it allowed them to see more of the environment and gave them more time to react to enemies and asteroids.

During playtesting another UI element was added to show the boost; currently it uses the particle effect system but this may not be clear to players and is pending more feedback.

Post Playtest

Based on feedback from playtesting it was clear that the game needed rebalancing due to the screen size change.

Enemies were the first element to re-balance. Prior to the screen size change enemies had a range of 160 pixels, this felt balanced as enemies had to be in view to fire. Now that the playable area has increased, players feel as if enemes are too close when they start shooting. To combat this the range was increased from 160 to 360 pixels, this should make enemies pose a threat at range and prevents them from swarming the player at short ranges.

During the playtest some players were uninterested in the gameplay loop and found an immunity bug. The bug was caused by two things, the brief immunity players gain once damaging and the way the game checks how damage should be dealt. The first part of the bug was caused by the melee enemy type, they could not deal damage to the player, but they could reset the immunity timer; this meant the ranged enemies now could not also deal damage because the player was constantly immune. The second issue was how the game checked whether to deal damage to the player's shield or health. When a melee enemy attacked the player they always attempted to attack their shield, meaning the melee enemy units never actually dealt damage to health, but were still resetting the player's immunity cooldown. The health checks have now been changed to see if the player's shield is equal to zero, if it is zero then deal damage to health.

Based on observations from playtesting some UI elements were added and adjusted. The first was to add a full controls menu due to players still being confused about the controls despite adding the new UI elements. The controls menu will appear when players start the game and dissappears once they click to start the game.

This is the new start menu going forward, there may not be another time to playtest before the development cycle so feedback will be limited, but hopefully this helps players understand the control scheme in future.

[jakeharkins-gamedesign]

Week 13 General

Welcome to Week 13! We are quickly approaching the end of semester and thus end of development of Cyber Flight. This week is the final week of major additions and the final proper playtesting session before submission. This week's content is focussed on Chapter 14 and 15 from Fullerton (2018). These chapter cover the idea of Communicating Designs and Understanding the Games Industry.

Chapter 14 focusses on the fact that game development is a collaborative environment, and thus communication is extremely important. Part of good communication is properly conveying the vision for the game, and this is normally best done using some kind of documentation. The first type of documentation is visualisation, information can be very effectively communicated using visuals or graphics; they show enough information while being easily interpreted by the reader. One-sheets and one-pages are a great application for this, they can show the essential parts of a game overall or specifics like UI design or boss designs.

Flowcharts are also a great way to show possible routes a player may take once they arrive at a decision. They may also show progression through a game; units in an RTS game for example may have multiple upgrade paths that lead to highly varied gameplay. Continuing the example of RTS player units, tables and spreadsheets are also useful communication tools. Spreadsheets allow for testing and changing of values very quickly; if a unit is too powerful it can quickly be altered in a spreadsheet and the whole team is made aware of the change with minimal communication effort.

No matter the strategy of communication used, the format is extremely custom for each development team. There is not an outlined method to organise a document like Architects have for house plans, or software developers with UML diagrams. No matter how the document is laid out, it is generally agreed that the design document should contain everything required to create the game, but this will obviously change between games.

Chapter 15 looks at the new games industry as a whole. While many designers do not care for the business side of game development, those who do generally have a better understanding of the process and are more successful. In recent years (prior to 2018, at the time Fullerton discussed these points) there is an upwards trend in revenue and digital sales; there has been explosive growth as games become more accessible. Accessibility has been significantly improved by the growth of games on mobile platforms, including handheld consoles and mobile phones. Another way of looking at the games industry is through the growth or changes in genres. Different genres are best experienced on certain platforms, and this may influence decisions in game; the genre of game also dictates what kinds of players will purchase the game. There is a large variety of games developers in the industry, some will do contract work, others work solely with a publisher and gain funding from them. No matter what their background is these teams love game development in there own way and there is always talent to be found.

Fullerton concludes that understanding the games industry is a powerful tool that better prepares designers to deal with the ups and downs of getting a game published. Understanding the goals of all parties involved in the development and publishing of a game helps you make better choices in your career and in turn helps become a better designer.

[jakeharkins-gamedesign]

Week 12 Development + Playtesting

This week only two playtests were performed, another naive playtest and a deep playtest with a returning player. The primary feedback from this week saw major improvements in balancing both enemies and asteroids. The general overview of feedback is as follows:

Players are not sure what each UI element means, confused on the shield bar and what it represents.

Players still feel they do not have an effective way to kill enemies behind them without risking taking damage.

Players would like to be able to be to rotate while stationary to shoot at enemies.

Players enjoy the boost and its visual effects, but feel as if the boost could last slightly longer.

Development this week is focussed on adding new abilities and making additional changes based on this week's feedback.

Balancing/Changes

Based off this week's feedback players felt like the boost was slightly too short and they couldn't escape certain enemy attacks or asteroids. To counteract this the consumption rate was decreased from 1.5 -> 1.25, which gives the player a slightly longer boost overall.

Based off player feedback some UI changes were needed to better represent what certain elements show to the player. Players mentioned that they are not sure what each UI element (health, shield, boost) actually shows. To better show what each element represents icons were taken from in game and attached to the UI:

This should improve player clarity and feedback will be collected next week on these changes. Additionally, another element will be added to represent a boost in future.

Additions

This week was also focussed on adding new abilities, feedback from previous weeks has indicated that players feel they cannot properly deal with enemies that are behind them due to the control scheme. To help combat this we're giving the players a new secondary fire: a bomb. The bomb will be on a 10 second cooldown (pending further feedback), when fired it will launch behind the player and explode after 3 seconds, destroying any enemies in the explosion radius.

This should give players an effective way to deal with enemies behind them and allows them to clear groups of enemies. Currently the bomb is an ability on a cooldown, but it may be changed to have ammo instead. Because the player will always have ammo (after the 10 second cooldown) both laser and bomb UI elements were added to make ammo clear to the player.

A death/end screen was also added to the game as players were getting confused when they died (and thus when they can keep playing), and were very unsure what their final score was.

Currently this screen is just a placeholder, in future interactable buttons to exit and restart will be included.

[jakeharkins-gamedesign]

Week 12 General

Welcome to Week 12! This week we will be conducting playtests and further developing Cyber Flight.

Playtesting this week will focus on gaining feedback based on development changes made in Week 11. Development this week will be a combination of implementing new features and changing aspects of the base game depending on this week's playtesting. All development changes will be covered in this week's respective post.

The next few weeks will cover further content from Fullerton (2018), specifically Chapters 13 through 16. This week will cover Chapter 13 which focusses on the Stages and Methods of Development. First, Fullerton covers the stages of development which include concept, preproduction, production, QA and maintenance.

The concept phase includes the creation of a team, a project plan and an actual game idea. The publisher will want to see an experienced team to ensure the project can be completed, arguably this is the most important aspect. The project plan will outline the budget and schedule for production. The game idea will include some market data to pitch the idea to publishers. During preproduction a small team will focus on testing the feasability of the game, they will create a small slice of the game such as a single level or feature. The team at this point will be small, publishers do not want to take a risk with a project that may not be successful.

The production phase is the longest and most expensive, and is where the bulk of the work is completed; programmers will work to create the game features, artists will build the assets required and writers will create the story. In Agile development programmers and artists may be grouped together to work on specific feature sets.

The next phase is QA, which involves taking the build created during production and transforming it into the final build that players will experience. Any bugs present in the game will be ironed out by their respective teams; these fixes will be the difference between a completely polished game that players will enjoy and a buggy game experience. During this phase bug tracking services will be used to ensure polish, and once the highest priority bugs are solved the game goes from alpha to beta. The last phase is maintenance, this is mostly for 'live-service' games, where bugs may still be present (or arise) or there may be extra content to add in the form of DLCs or monthly events.

[jakeharkins-gamedesign]

Week 11 Development

Since the last development post some playtesting has taken place and we have a list of issues that are the focus of this week. The first playtesting session revealed a lot of balancing work has to be done before development can continue on extending features.

The first issue to balance is the enemies. Some of the players mentioned that they feel like the enemies swarm them too often, and that it is hard to distinguish between enemy types. This problem can be reduced by doing two things (I want to make a note that it is actually fixed by doing three things; but I have already covered the third option in the spawning section of this post.

The first solution to this is changing the physical apperance of enemies. This will first be done by recolouring the enemies, so they will go from their original black colour to a teal/blue. In future the physical size of enemies may also be changed.

The second is changing the speed of enemies. Currently all enemies move only slightly slower than the player, meaning they catch up very quickly. This is the main contributor to the swarming problem.

The GIF on the left is the original speed (75 pixels/s) for the ranged enemies, and the right is the new (50 pixels/s). This should now allow players to react better to enemies, but this will be tested during the next playtesting session. Note that the melee enemy class has only had a speed decrease from 75 pixels/s -> 60 pixels/s as they still need to be able to swarm the player to an extent.

Spawning

The second issue was spawning of enemies and asteroids; players generally feel that they do not have time to react to both spawning because they can spawn within the screen bounds. This issue can be fixed by changing how the spawning positions work for both enemies and asteroids.

The new spawning system will use two objects that are out of the player's view; SpawnFlag1 and SpawnFlag2, both of which contain variables 'spawnX' and 'spawnY'. Whenever the game tries to spawn an asteroid/enemy it will choose one of the spawning flags, an axis and a random value equal to the screen. The setup for the system looks like this:

The purple/black squares represent the spawn flags. The bottom left flag is #2, if the system chooses this flag, an object can either spawn in the negative Y direction (towards 0, 0) or positive X direction (towards 600, 800). For the asteroids spawning now looks like this:

Now asteroids always spawn outside the player's view and gives them time to react.

Boosting

The third issue to solve is two fold; players are generally unaware that they have a boost available to them and this boost is infinite.

To fix the first issue a simple boost UI element can be made above the health and shields. The colour of these elements can be changed at any time, but red is used for now as it can easily differentiate the boost from health and shields.

While implementing the UI element the infinite boosting may also be fixed. In order to have the boosting meter function correctly a decay rate for the boost must first be implemented. The decay rate will determine how fast the boost is used and is currently set to 1.5%; the recovery rate is half at 0.75%.

These fixes will be tested in the next playtesting sessions, from there the main focus of development will be adding extra features and further improving the game.

[jakeharkins-gamedesign]

Week 11 General & Playtesting

Week 11 marks the continuation of development in Assessment 3. Last week the first playable build of Cyber Flight was made and a playtesting session was conducted (discussed later in this post). We had 3 players in this session, all naive playtesters, who played the game with no previous knowledge of the game.

The playtests conducted this week show a variety of issues, including enemies, balancing and visuals. The main issues with each are as follows:

Enemies

Enemies are hard to tell apart, becuase of their spawning they form a 'sea' and it is difficult to visually tell enemy types apart.

Enemy movement speed is very unbalanced. All enemies move only slightly slower than the player, so players are easily swarmed, with little time to react.

Visual/Spawning

When enemies and players shoot the bullet does not spawn in the correct position.

Asteroids and enemies can spawn in the middle of the screen, which gives players little to no time to react.

Abilities

Players generally do not realise they have a boost ability available to them.

Player's have an unlimited boost available to them.

The above mentioned issues will all be solved in this week's development post, which will be posted later this week.

There is also more reading from Fullerton (2018) to cover this week, this time focussing on Chapter 12, Team Structures. In this chapter Fullerton discusses the increasing size and complexity of games, and how this had lead to game production occuring in massive teams.

Fullerton broadly splits studios into 2 teams, a development team and a publishing team. The development team will be focussed on the creation of the game, they are made up of designers, producers, programmers, artists and QA. The publishing team will focus on almost everything else; they will ensure the game is marketed well and arrives on shelves. They are made up of a marketing team and company executives. No matter what team an individual is a part of they will contribute to the game in some way using their skillset.

Additionally, Fullerton covers team building and communication. Team building is an essential part in ensuring production goes smoothly; a company could hire the most talented group of programmers possible, but they are all useless if they cannot work together or communicate. Communication is also essential in these environments. Team structures where requests and ideas are funneled towards one person for approval and communication between other teams; if any individual person could make this decisions it would likely cause problems between teams.

[jakeharkins-gamedesign]

Week 10 General & Group Formation/Discussion

Week 10 marks the beginning of Assessment 3, including formation of a group and a discussion on the game to develop.

For Assessment 3 I have formed a group with Alex C and Yuki S, who have both been great at communicating and discussing ideas.

As a team we had a decision between my game, Cyber Flight, Alex's game Dive To Survive, and Yuki's game Run Forth Adventurer. As a team we discussed what game would be the easiest to iterate upon and the separation of roles. We originally were leaning towards either Alex's or Yuki's game, but ultimately decided on mine as we felt like I had the most features already planned that we could implement. Having a list of features to implement gives us a list of goals to work towards alongside the issues that arise from playtesting.

Part of this decision was also due to the workload; GDevelop is difficult to work with in a team as modifying one part of the game means the whole file changes (GDevelop stores projects in a single file). So, if one person makes a change, it is difficult to merge multiple people's 'builds' together. By having a sole developer we eliminate this issue. This does mean the workload will be split differently, but as a team we have decided this is the best way to proceed.

Besides general updates and discussion, there is also more content to cover from Fullerton (2018), specifically Chapter 11 where she discusses fun and accessibility. When first designing a game the primary focus is figuring out if the game is fun, specifically is it a good idea? Fun is a hard aspect of games to determine, like many things different people (or players in our case) can enjoy many different things.

There are ways to determine if the game is fun, the first is asking playtesters. Unfortunately, not all playtesters will be able to articulate why they find the game fun. So, as designers it is part of the job to determine what tools you can use to measure fun.

The first tool is looking at dramatic elements of your game that keep players invested, these are challenge, play and story. All different types of challenge and play may invest different players; one player may be more interested in a multiplayer game where players compete against each other than an open-ended game where someone may play out a different life. Additionally, some players may have no interest in competing and are only involved in the storytelling and world building of a game.

Fullerton also explores the process of refining player choices. A choice in any game may have a significant or little to no impact; generally the most interesting choices have a balance between risk and reward. Any choice a player is offered must have some impact, if a player is offered two weapons with identical stats their decision has no actual impact on the game; their weapon will be equally capable of killing enemies. A good (and therefore interesting) decision should make players think about what will happen in future, and how even a seemingly small decision may influence that.

[jakeharkins-gamedesign]

Assessment 3 Development Progress

Week 10 marks the start of development for Assessment 3; the game being developed is an extension of Cyber Flight. The continued development of this game will focus on expanding upon the features seen in the A2 posters.

This week, the focus of development is to complete the game, by adding in a scoring system, ensuring enemy AI works correctly, adding weapons and ensuring asteroids can be destroyed.

The first focus of development this week is to allow players to destroy asteroids. In order to be able to destroy asteroids they will be assigned a health value; large asteroids have a health pool of 30, and small have a health pool of 10. Players will deal 10 damage per shot, so 3 shots to destroy a big asteroid, 1 to destroy a small.

When large asteroids are destroyed they will break into 3 small asteroids, and will apply a random force in a random direction.

The second feature to implement was the scoring system. Players gain score from killing enemies and collecting certain pickups. Whenever a player earns score it will be added to a variable attached to the player; this is then displayed on the HUD in game.

The third feature to add was additional enemy classes. To test features this week only the basic types need to be added. The short range/melee class has already been added previously, so only the ranged enemies need to be implemented for now. The ranged class will move towards the player and shoot at them while they are looking within 20° of the player. Currently these enemies have no range limitation; which likely needs to be changed in future.

The addition of these features allows our group to test the game as a whole during the first playtesting session. We will be able to test if the enemy types are clear, and the basic premise of the game is fun.

[jakeharkins-gamedesign]

Racing Game Postmortem

The development of the racing game was overall unsuccesful in my opinion; many functions of the game are incomplete and the main objective of the game is unclear, leading to a sense of incompleteness.

Many of the game features feel incomplete due to slow development time; many features were added towards the end of each week, severely restricting what could be completed. This lead to abilities and parts of the game that feel lackluster or do not fit with the theme established in the elevator pitch.

The main objective of the game is unclear due to a combination of slow development, lackluster features and missing art. Throughout the protoype the only 'art' for the car is the original directional arrow shown in the first development post. This makes it extremely unclear to players what kind of game they are playing as there is no indication they are playing a racing/derby game. This shows that the prototype is largely incomplete, as Fullerton (2018) discusses in Chapter 9, where she discusses the idea that a prototype is only complete once players can play with minimal input from a developer.

In future I would begin development of this game from scratch. The features currently in the game would still be included, including the movement, power ups and basic 'AI' implementation. The shield and power boost powerups would be changed, partly because they do not fit as well into the games theme, and may create imbalances. The current AI implementation would stay the same becuase the layout of maps would remain the same.

[jakeharkins-gamedesign]

Assessment 2 Posters

A brief update from last week, the posters are now complete and ready to be submitted! As stated last week, there was minimal work required on the posters.

The one-page had some font changes to try convey a more futuristic look to better fit with the game theme, the font sizes were also altered, now all the body and header text are the same. The font changes also make it easier to read the poster, and helps fill some void space left previously.

The one-sheet had minimal changes from last week, there were some additional asteroids added to better fill some void space but the poster has remained mostly the same.

Overall I'm extremely happy with both of these posters, although they may be a little generic they convey what is necessary very clearly.