tetley1173-igb220-blog

[tetley1173-igb220-blog]

Wasteland Wayland Development

By Shannon Tetley

The Wastelanders team and myself have been busy working on our game. As you can see I was able to put in a cool intro to the game that I hope will get people excited to play and introduce them to the story. Liam's done a great job programming the enemy traffic, modifying Sam's work for their sprites, and adding sound affects to the action.

To top it all off I've added the upgrades store and death screen, and Sam has made an epic boss battle to conclude our game.

I'm pretty happy with the game my teams been able to make. We were able to meet all of your development goals including some of our stretch goals like adding different vehicles for the player to use. Merging the teams work together went very smoothly, I have to shout out to Liam and Sam for doing a great job with commenting their events and designing their work in a way that made copying it into the skeleton game really easy.

Sticking to our strict rule of no magic numbers has worked out well. It definitely sped up the process of merging and balancing the game. Because of this we've had the time to do two or three balance adjustments to the game. Take the example below:

Here you can see that liberal use of variables has occurred. The vehicle_selection variable controls what version of the upgrades shop is loaded for the player. This has tidied up the events so that they can be separated into sections relevant to each car the player can select, they can be identified as the blue, teal and red event groups. Then in the speed upgrades section you can see that all the numbers are pulled from global variables also. This meant that when Sam modified my work to balance the game and make it compatible with his work elsewhere, he was able to do so very quickly.

As the game started getting closer to play testing the teams focus shifted to making it balanced. The reason so much thought had been put into making the game so modifiable was because of the lessons we learnt while reading chapter 10 of Game Design Workshop. In this chapter it mentions how game variables and system dynamics affect whether the game is balanced or not (Fullerton). We weren't sure exactly how we would inevitably mess up the game balance but we had some suspicions. We were correct in understanding that the upgrade shop would have a big impact on balance but one thing that surprised us was how the car would work in comparison to the jeep and tank player vehicles. With this in mind we were able to set up the shop so that it was easy to tweak the impact each upgrade had on vehicles. We were also able to adjust the unexpected disparity of each vehicle by modifying the cost of upgrades, making them cheaper for the car, which tends to kill less enemies for example.

When performing internal playtesting, we noticed that the interaction of game dynamics was causing the car to underperform, and that increasing the speed of player vehicles would just make the game harder, this prompted us to rethink the speed upgrade. We converted the speed upgrade into a manoeuvrability upgrade instead which also allowed us to make the car more viable by making it the most manoeuvrable by default. Making these changes is a good example of applying the theories of T.Fullerton as it shows both the affects of game variables and system dynamics on the balance of the game (Fullerton).

Chapter 10 of Game Design Workshop concludes by mentioning that much of the technique that game developers use to balance a game comes from gut instinct (Fullerton). I'm inclined to believe this statement as my team was making balance decisions about our game long before we read chapter 10. Its my theory that as gamers we realised that things like the upgrade shop would be important to balance based on our experience playing other peoples games. We by far are not done with the balancing process, at present we have gotten the game to a state were it is playable but not necessarily fair in all situations. The next move for this project will be to formally test it with the help of some naïve play testers. In my next post I hope to be able to share some insights gained from testing the game with real players.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Wasteland Wayland

By Shannon Tetley

This post I'll be introducing the game that my team and I will be working on for our final assignment this semester, along with the team whom I'll be working with.

How did I find my team?

In one of our tutorial we dedicated the day to forming teams for assignment 3. Because I was planning to continue building on either my own game described in assignment 2 or one that a team member had I decided to show off my Sell Sheet that I created for that assignment.

Generally my idea had a good reception, in particular with my future team mate Sam. Both of our games were top down racing games with shoot 'em up elements added. Each game had a boss battle at the end with the main difference being that my game included a upgrades shop and a selection of cars for the player to choose from. This coincidence combined with my previous interactions with Sam testing each others games made him an excellent candidate to form a team with. Later our third team mate Liam, asked to join in as he was familiar with us from having also participated in playtesting each others games.

We decided to call ourselves the Wastelanders keeping with the theme of our game. It was decided that Sam would work on the boss and creating assets for player vehicles, the boss, and some basic enemies. He would also work on bringing the boss to life as he already had a working prototype from his game. I would be responsible for organising our playtesting as this was similar to the user experience testing I had done in previous units. I would also be working on menus and the upgrades shop including the discrete structures that would be needed to make it all work. Liam volunteered to make the sound affects for the game and he would work on the generic enemies in the game including some visual assets and their behaviour.

Having discussed what we believed should be the minimum viable product for this game and after making some assets we formalised our design concept by turning it into a One Page document. Following the advice of Tracy Fullerton in chapter 14 of the book, Game Design Workshop, I decided that using my old One Page document wasn't a good idea as it hadn't been made as a team (Fullerton). The version 2 that we would use was an updated version worked on and approved by everyone on the team. This way everyone was familiar with its concept and it was able to grow into something better than what I was able to create on my own. Anything left unchanged on the document was done so after the team considered it and decided it was good enough to keep it as is.

This One Page poster is used by our team to help us work in a unified direction and reminds the team of what our goals are. With our design goals well established we set out to make a basic version of our game. Liam was able to make some cool sound affects for us by recording sounds at a car show that he then converted to 8-bit sounds. Sam made our first set of assets as mentioned, and started adding them to the game.

My first contribution was to make a 'game skeleton' that had all the scenes we planned to create for the game. This way when a team member made something we could just copy over their work into the blank scenes. I also discovered a new way to add UI (user interface) elements to the game. Gdevelope calls these external layouts, these are visual elements that are created separately from a scene and are called in using the game events. This framework has all sorts of useful applications, my first use of this was to create a temporary main menu.

This menu could easily be removed or added back into the game as needed for testing purposes because it is an external layout. To do this you simply comment out the event that calls it into the scene. Later Sam will use an external layout to add a health bar to the race scene. The advantage of this is that he can make changes to this health bar as we balance the game and improve visuals. The health bar can then be reused if we add more level, saving time, and any changes will update across every scene it is used in. This saves a lot of time and functions similar to making a game object into a global object. The main difference is that an external layout consists of several objects and saves their arrangement relative to one another.

Aside from these additions I also added as many objects that I could to the game and added variables to both them and the scenes in the skeleton game. These variable were based on what I anticipated would be needed to make future game mechanics function and would mean that any events made by the team could reference these instead of using magic numbers. This process was followed with the intention of speeding up later development as if changes were needed for the sake of balance, they could be done quickly as all we would need to do was change the values of the variables which would affect all of the events associated with them. This way we would need to change one variable instead of refactoring the entire game.

In my next blog I'll show off what we're able to produce including an example of how thinking ahead with setting up variables has affected development.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Bonkers Bob Post-mortem

By Shannon Tetley

I didn't progress far with this project. I got busy with an assignment about making a One Sheet document promoting the game rather than developing it further. I've planned lots of new features for it as part of the assignment but have not had time to work on it directly. Consequently it ended up being a fairly simple game with some glaring balance issues.

As you can see, the game is more like a casual drive on the high way rather than a high speed race. Aside from being busy with other work, my process was a little different for this game which contributed to its simplicity. Instead of throwing together a more complete game quickly I focused on changing the way the back-end of the game works. It was challenging to get all of the objects working together to create the moving scene you see in the above gif. I had to think about how fast things are moving and how that speed impacts the rest of the game. I had to think about the fact that the left hand traffic would be moving relatively slower compared to the player car, because they are moving in the same direction. The right hand traffic has to move faster for a similar reason because they are approaching the player. Because the level the player moves through isn't actually moving I had to make the trees move, and decide by how much, to give the illusion of movement.

These mechanics create interesting design considerations when objects interact. For example, I wanted it to look like the camera stops when the players car crashes. To do this I had to make the trees and the car explosion stop to maintain the illusion.

To improve on this prototype, I think I need to make the tree positioning and spawn rate more random. As is, it looks like the trees have been neatly planted next to the road. Its also not very interesting to have the cars spawn so infrequently and to not drive aggressively. I think the game could be improved by making them move faster and to swerve from time to time.

The game is pretty boring if I'm honest. Its not just that its too easy either. The controls are nice to use but there isn't really anything interesting to do with them. In chapter 9 of Game Design Workshop, it talks about how a game is interesting if the choices you make have consequences (Fullerton). As is, there is only one choice to make and it is to change what lane the car drives in. However, due to how easy it is to do this without hitting the traffic its not a very impactful choice. Also, there isn't any end goal aside from not crashing.

With this in mind, my team and I will be adding many more options and consequences when we extend this game for assignment 3. If time permits, there will be a choice of vehicles to drive and a variety of upgrades to combine with them. We will also plan to extend the controls to allow changing speed and moving vertically. All of these choices will have big impacts on the game making it easier or harder on the player depending on what they choose. All of these consequences will determine how long it will take them to reach the final boss that we're planning to add, and how well they can fight off its assault.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Racer Development Post

By Shannon Tetley

During development of my racing game Bonkers Bob, I've been trying to add immersion to the game by making it seem like the world is moving around the player. Until now my backgrounds have been static or had no art in it at all. I'm also working on adding better feedback for players.

As you can see I've had some success with this. The feedback is improved, the text that indicates the number of cars passed is bigger than in other games I've made, and its quite obvious what's going on when you crash your car. Screen transitions was fairly simple to facilitate and I've learnt how to add buttons for navigation. This will be important later as I plan to add a shop to the game.

The most challenging part of this process was to implement the movement of objects. I've been thinking ahead with this one, knowing that there will be different player speeds in the game due to different player vehicles and upgrades, I've reduced the use of magic numbers in my events. Instead of making the car move at a flat rate of 300 pixels, I've given the player car a speed variable that the event looks at to determine its speed. I've also used this concept when setting the speed of traffic and scenery. The speed of these objects is determined by some simple math so that their speed is relative to the player vehicle.

Some magic numbers remain but will be changed as I work on the project. Controlling the speed of vehicles this way will make it easy for me to change their speed later when more controls and upgrades are added. Removing the magic numbers used to represent traffic speed will even allow me to change their speed if I want to balance the game or increase the difficulty for later gameplay.

As for the future of the game, I plan to add a store with an upgrade system and boss battles. This has led to me planning how I might program the AI for these types of enemies. I'm unsure for now but I may end up making the boss follow the player then fire its gun randomly. While having these thoughts I happened upon an article an article by PC Gamer interviewing Todd Howard, Director of Starfield, about its ship AI (Randall). In the article he states that the AI of the enemy ships was made to be "dumb" so that the player has the chance to hit the otherwise impossible to hit space ships. This has made me mindful that making the enemies in the game dumb, may be a good idea to keep the game playable and more importantly fun.

References:

Randall, Harvey. Todd Howard says that Starfield's . . . , PC Gamer, 2023.

https://www.pcgamer.com/todd-howard-says-that-starfields-ship-ai-sucks-on-purpose-so-players-can-actually-hit-stuff-you-have-to-make-the-ai-really-stupid/?utm_source=facebook.com&utm_medium=social&utm_campaign=socialflow&fbclid=IwAR1jGq6LuhFwuQpIbv6ANjg5kL5SiD9Kq397PAtAfl-6BTVcRi5odJvbNBY

[tetley1173-igb220-blog]

Bonkers Bob Elevator Pitch

By Shannon Tetley

Bonkers Bob is my take on the classic vertical scrolling racing game. Vertical racing games like Matel's Auto Racer from 1976, feature a car that can be moved between columns in order to avoid other cars. There is usually a penalty for hitting other cars such as slowing down or restarting the game. In the old-school Matel version you are racing a timer and must reach the top of the game area. Hitting a car bumps you back down to the bottom of the play area.

I was able to find an emulator of this old game at https://itizso.itch.io/mattel-auto-race featured in the above screenshot. Its a simple yet fun game concept that I've enjoyed many versions of during my youth.

My version won't be running on a calculator chip though, so it'll look a little better than this one 😂. I'm hoping to put a twist on the game by featuring multiple levels and including shooting and upgrade mechanics. I'm going to give it a silly back story to make it more interesting to. The setting will be post apocalyptic with most of the survivors being children who are just trying to do kid things like eating snacks and having fun. Being a light hearted and comical setting the game will be aimed at children to young adults.

Elevator Pitch

-Bonkers Bob -

It is the year is 2222 and the world has gone bonkers. The war to end the world is over now. At first the apocalypse wasn't so bad, there was plenty of zombies to kill and nobody had to go to school anymore. But the then that got boring, really boring! There's only so many zombies you can kill before it gets old. When Cool Kid Carl returned from Wasteland City with the once thought to be extinct 'Play Box 64' the wasteland gang went wild.

It's now a literal race to snatch up what is likely the worlds last supply of gaming consoles before, zombies, robots, and other kids can stop you!

Mechanics

Bonkers Bob is going to feature vertical scrolling racing mechanics with other vehicles that will impede the players travels. I would like to expand on this with several ideas I've had:

A main menu inviting the player into the game with options to start the game with different cars.

An introduction scene explaining the plot.

Several levels featuring different terrain.

An upgrade system for customising and improving the player vehicle.

Points to be awarded for destroying rival vehicles that can be spent at the store.

The player progresses levels by destroying or passing all rival vehicles.

This is an ambitious design concept which I'm not confident I can implement fully by the end of the semester. If I do end up making this game for my final assignment I'll start with a basic racing game prototype then expand into easy things like presenting the story. Building on this I will add features like different player cars. Finally if I am making good progress I'll start adding things like a shop system. I plan to focus on some things that would have been great to get right in previous games I've made, such as an exciting introduction to the game, better balance, and feedback to help the player understand what's going on. This could be a great game if I can affectively combine all the things I've learnt over the last few weeks.

[tetley1173-igb220-blog]

Meteor Miner Post-mortem

By Shannon Tetley

I'm finished with my asteroids game for now and I think it turned out pretty good. I put it together by following the tutorial I was given which taught me some new concepts and left me with a skeleton to work on. I expanded on it by adding random movement to the asteroids and by adding variables to them that determine there average speed and other traits like how much damage they do to the player. I think the biggest influence the textbook Game Design Workshop had on my design process was that it suggests that interesting choices are what make a good game and that players need to be challenged or those choices are meaningless (Fullerton). I tried to implement this idea by making the asteroids move at a random speed that is faster on average based on the asteroid size. I also added randomness by making the asteroids bounce off of the boundaries of the screen which also makes the game harder by concentrating the location of asteroids around the player.

Another concept that I leaned form T.Fulleton, was that play testing should be core to the design process (Fullerton). Knowing this I have been a lot more formal about how I've done play testing this time. I've used a template that was provided to me by the uni to create a questionnaire that players fill out after trying the game. I added to this template by including questions more relevant to my game that I though would elicit helpful feedback. My readings have taught me that I shouldn't be making games that are fun for me, I should make them fun for the audience. Playtesting is how I measure how fun the game is for my audience and is used to inform future iterations of the project. This testing has been very encouraging for me as players have a tendency to keep playing the game despite dying or achieving the main objective of the game.

Player Feedback

Some interesting insights where discovered through my play testing. I find it intriguing that despite having different issues with the game, the issues had some overlapping themes.

Generally speaking they said that:

The game was challenging and rewarding to defeat.

Some said that the asteroids where too fast.

The ones that could handle the speed didn't like the turning speed of the ship.

I suggested upgrades for the player ship which everyone agreed would be a good idea. Some testers even came up with this idea unprompted.

Some players died before realising they were losing hit points, others didn't notice they were dying till it was too late. Everyone agrees that it needs to be more obvious when your are taking hits.

My conclusions from this are that the game has some balance issues, some issues with the controls and issues getting feedback when events happen. I agree with them about the feedback when you lose hit points, its not obvious and it happens quickly. For the general game balance I think there are many options to fix this. I think simply changing the asteroid speed and frequency would alienate the less confident players. I could also fix the ship turning speed but being slow is a challenge in itself. Instead of addressing these issues individually I think the best option, as the players mentioned themselves, is to add an upgrade system to the game.

How would I change the game?

I would implement an upgrade system to the game by adding a store. I think that allowing the player to have a breather would help them out. Pausing the game to allow them to access a upgrades store would help in many ways. Simply pausing the game would allow them to rest and cope with what is happening. The can then make interesting decisions by buying upgrades that can help them deal with the challenges of the game. Is the ship turning too slow? Upgrade the turning speed. Are the asteroids too fast or numerous? Buy a slow down time machine, or buy a better gun to thin out the horde.

If I continue this project I would also add more feedback in general. Feedback for destroying asteroids to reward their success and feedback to warn them they are taking hits. Also I would add a title screen to invite them to play and improve the death scene I added.

A lot was learnt on this project particularly after playtesting. Now I know the basics of creating new scenes I'm going to start with the title screen for my next project as I think and introduction to a game can be quite important. Providing feedback to the player adds to their experience and ease of use for the game, I'll be sure to concentrate on including this for the next project.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Meteor Miner Development

By Shannon Tetley

Continuing with my development of Meteor Miner, I've been able to add some fidelity to it that I wasn't able to with my platformer project. The game at the beginning of the week included a ship that sits in the middle of the screen that can shoot in the direction of the mouse, and some asteroids that randomly spawn on the screen. My goal is to make the ship able to move around as it shoots and to make the asteroids move around to make them more interesting.

My game looked similar to this at the beginning of the week:

I was able to get a lot more done than in previous weeks, I'm pretty happy that I've been able to add a few things that go beyond what I was asked to do in the uni tutorial. I added movement to the asteroids and made it so they are destroyed when shot. At first the game wasn't very challenging because the asteroids would fly off screen if not interacted with. This would reduce the number of objects on screen making them easy to avoid. Thinking back to my readings I recalled that altering the formal elements of a complex system, like a game, can have a wide reaching impact on that system (Fullerton). Knowing this I came up with the idea of creating a new rule for the game where if an asteroid makes contact with the edge of the screen it will then bounce off the screen in a random direction. I predicted that this would make the game more interesting and challenging as it would not only keep more asteroids on screen, but it would also make them move in interesting ways. This was achieved by adding walls just off the edge of the screen, when the asteroids make contact with them it activates an event that makes them move in a new random direction.

As I suspected this made the play area much more chaotic. Now when the game is run asteroids are moving in random directions and in far greater numbers than if I had simply increased the spawn rate. To make the asteroid movement more interesting I also made them move at a random speed capped based on the size of the asteroids. On average they move slower if they are bigger asteroids. To tie things together and to give the payer a basic goal when playing the game I added a health count at the top left of the screen. I also added points to the top right. More points are added for killing bigger asteroids with the laser but you also lose more health points when being hit by them.

This week I also learned how to create and transition to new scenes. I was able to use this knowledge to be able to create a death screen that pops up if the player runs out of lives. This way the player has a reason to shoot the asteroids as they not only get points for doing so, but they also are less likely to be hit by them ending their game.

The end result looks like this:

The results are much better than with previous games I made. This one is much more like what you would describe as a game, something that has rules, challenge and an objective for the player to work towards.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Meteor Miner

Asteroids Elevator pitch by Shannon Tetley

The pitch:

Meteor Miner is a classic asteroids type game where you must survive an endless horde of killer asteroids and hostile spacecraft to gain the highest score. Resources can be claimed from the destroyed asteroids to allow the player to upgrade and customise their ship. Combinations of upgrades form different loadouts and its up to the player to decide which combination will help them survive.

Aimed at young adults this game is inspired by horde survival games like the Call of Duty zombies game mode and arcade shooters like Asteroids. The game will feature waves that increase in difficulty and award the player with fanfare and access to upgrades when completing waves. Upgrades provide the payer with interesting opportunities to customise their survival strategy. Upgrades could include faster manoeuvring, more powerful weapons or unique abilities. The combination of these abilities are what will make or break the players survival run.

The game would be set in space with a futuristic theme. Taking inspiration from Sci-Fi films and classic arcade games could give the game an exciting feel and build the tension for the upcoming attack waves. These themes could be incorporated into the shopping screen used to buy upgrades by making it look like a hanger bay or the interior of a space station. This shop interface could take many forms, it could be used as a paused, safe space for the player to catch their breath between waves, or it could let the game run in the background, putting the player under pressure to make quick decisions.

A lot of options are on the table for this idea but it would stick to some core mechanics. Survival and decision making are central to Meteor Minor. The player will be rewarded for playing with excitement and a sense of achievement for reaching a higher level, and by finding new and interesting strategies that they find fun.

[tetley1173-igb220-blog]

Platformer Development

What have I been trying to achieve with my platformer game?

I've been trying to learn the basics of Gdevelop including how to create sprites with animations and how to add behaviour to a game world. My goal has been to get the game to a state were it can be tested meaning it has a goal for the player and some interesting choices to make.

What's something I learned during its development?

A lot of work goes into making a basic thing happen in a video game. Moving forward I'm going to start work early so I can keep up with my goals each week and I'm going to focus on the basics. Hopefully as I get better at basic tasks like creating sprites and adding game logic I can do these tasks faster. Then I can hopefully focus more on the gameplay rather than the mechanics of setting up a game.

What has inspired me in my readings?

One of the biggest concepts that stuck with me was Johan Huizinga's concept of the 'Magic Circle' as referenced in Game Design Workshop chapters 2 and 3. The magic circle is the place that people agree to go to when they engage in a game (Fullerton). The part of this concept that was striking to me was the need for an invitation into this circle. Normally when you play a game like a card game the invitation is literal, someone asks you if you'd like to play the game, if you accept, you sit down and play the game according to the rules. In a video game the invitation is more metaphorical, the title screen is often considered to be the 'invitation' to the game. This immediately made sense to me as the title screen has often been make or break for me being sucked into a game.

This screenshot is a great example. Its the title screen of OpenTTD a transport management game were you build trains, ship, trucks and planes to fulfil the transport needs of the various cities in the game. I love title screens like this one, it fills me with inspiration everytime I open the game. I think wow, look at all those train lines and how massive that city has become. It makes me excited to jump in and try to make a massive train network just like it.

How can I apply this to my games?

Now that I'm getting a firm grasp on the basics, I'm going to make it my mission to apply this concept to my games. In the next couple of uni tutorials I'm going to try and figure out how I can add my own title screens to games. I'm going to think about how I can make those screens an interesting and exciting invite to play my games.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Testing My Platformer

So I got my game to a playable state ready for testing. The main idea of developing a video game is to make it fun. For this reason it is important to test early and regularly to ensure that what you're creating is actually the enjoyable experience you think it is (Fullerton, chpt 9).

The main goal of my game is to climb to the top of the world to defeat the giant slime at the top. It is intended that the main challenge of the game is the act of climbing with the slime being an excuse to do so. To test if this would be a fun challenge I asked two of my classmates to try out the game.

"Hitting your head doesn't feel good."

In the picture above, the player must overcome a small hole in the ground by performing a little hop to avoid falling in. I thought that adding this section to the level would create an interesting obstacle as you have to navigate using a different style of jump than usual. One of the playtesters commented that it didn't feel very nice to hit your head on the way through. Turns out I may have been wrong about this and its more of a nuisance to players than a unique challenge. There's a few things I could do to fix this so I'll have to put some thought into which one is the correct solution.

"The floaty-ness of jumping is fun!"

Yes! I had a win with this one. I changed the gravity values applied to the character to allow the player to jump higher and float a little when they jump. The idea was to give a different feel to jumping. I enjoyed this mechanic in platformers I've played in the past and thought it would be fun to add it to my game. I'm glad I was right about this one.

"I liked that there was one path"

One comment that surprised me was that they liked the linier path that the player must follow. I chose this due to the time constraints I was under but it turned out it was good for the player. My theory is that this felt good to the player because having an obvious path freed up the players mind to focus on the challenging jumping that they needed to perform.

Having done some testing on this game I can see a clear path for further improvement. I've been able to shake some misconceptions and gain a better idea for what parts of my game I should focus on. I've been able to understand what the feel of this game is and how I can turn game design theory into something I can implement in my games.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Platformer Develpement

This week I’ve continued to develop my platformer game to get it to a state where it can be play tested. It won’t be anything impressive, but it will teach me how to make a basic game using Gdevelop 5.

What have I been trying to achieve?

I’ve just been trying to understand the basics at this stage like how to animate things, set up events that trigger etc. To achieve this I’ve put together a basic world that the character can jump around in and I’ve been adding and tweaking things simply to learn how they work. For example, I strayed from the tutorial and tweaked the gravity value that controls jumping. I was able to make the character jump higher if the player holds the jump button down. I decided to keep this because I’ve enjoyed the mechanic in games I’ve played before.

What did I learn from this?

I re-learnt from back in the day when I used to mod Skyrim, that game development can be very time consuming. Chapter 10 of Game Design Workshop talks about development phases and how it is important to focus on the feature you are currently working on, get it completed, and don't worry about fixing every bug or problem that you find along the way (Fullerton). This was a mistake that I made as a modder as I never finished a project because I was using too much time making my creations look good instead of finishing the basic functionality that I was working on. Following the advice of the text book I’ve been making a low fidelity game but one that has interesting things to do in it. I've focused on making the game playable instead of fixing every movement bug or fleshing out all the animations. Its much more of a game than the Skyrim mod that looked pretty but didn’t do anything.

I also noted that changing things, like the jumping mechanics, can have wide ranging consequences in a complex system like a video game. I can see what Chapter 5 of Game Workshop meant when they were talking about game systems and how changing them can have cascading consequences (Fullerton). Changing how high my character could jump completely changed the game world as I had to make the platforms higher, so they remained challenging to reach. This resulted in my game world being 3 times higher than it was originally.

My next game should come together faster now I know the basics and what to focus my effort on. In my next post I’ll be talking about what I learnt from testing this game.

References:

Fullerton, Tracy. Game Design Workshop. 3rd ed., A K Peters/CRC Press, 2014.

[tetley1173-igb220-blog]

Platformer Pitch

By Shannon Tetley

The first task I was given in my game design class was to make a platformer game. I learnt a lot about how to use the Gdevelope editor we would be using this semester and I made a very basic platformer game. My next task was to think about what my game would look like if I were to continue developing into a finished game.

This is the pitch I came up with:

Name of the game: Proto Platforms

Genre: Adventure Platformer

Primary Gameplay Mechanics: Jumping is the main mechanic along with the ability to upgrade the graphics of the character and upgrade their abilities like adding a double jump or dash ability.

Setting: Fantasy setting

Audience: Casual gamers

Elevator Pitch

It’s a platformer game about a little man, this man can walk jump and move around like any other platformer character but there’s a catch. Theres no animations when he does these things and what he can do is very limited. When he picks up the mysterious item he finds at the end of the first platformer challenge he all of a sudden gets a cool walking animation when he moves around. Excited, the character decides to go on a quest to discover more magical items that can make him more real. Eventually, the little man will have all sorts of powers that he will use to progress his quest and to defeat the evil enemies that stalk his would.

The game might look a little like this if I were to make it:

[tetley1173-igb220-blog]

What is this blog about?

By Shannon Tetley

I'm creating this blog to document my journey learning game design and it will be submitted as part of my assessment for the class IGB-220 taught at the Queensland University of Technology. It's my aim to create an interesting record of my learning and to share what I learn with others in an informal yet professional manner.

Why am I studying game design?

Well, I'm actually studying for a bachelor in IT believe it or not. My major and passion is in computer science and I'm studying minors in mobile/cloud applications and user experience. I'm learning game design for the purpose of gamifying mobile apps but that's just the academic reasoning. I've loved video games from a young age and have dreamed of making them for a living since I was a teenager. I chose to study computer science for job security and only discovered my passion for it after beginning my studies. Studying game design for my user experience minor was a happy accident but due to my interest I have embraced it enthusiastically.

How did I become obsessed with video games?

I became interested in them by watching other people play them from a young age. I've always had an active imagination and a lust for adventure. I enjoyed playing make believe and video games are a natural extension of that for me. There's nothing more fun to me than to be immersed in a fictional world were you can explore and act out fantasies.

I don't remember the first game that I ever payed but I do remember being frustrated when I had to stop playing other peoples games when I had to go home from a friend or families house. Eight year old me was determined to get hold of my own games, so when my parents gave me the option of pocket money or a PlayStation for Christmas I gave up the pocket money 😂.

Army Men: Air Attack developed by The 3DO Company

My first game was Army Men: Air Attack published by 3DO. I loved this game because I got to play with army men that could actually shoot! I loved the light-hearted and comical story of this game but it was all about the action for me. From that point, I collected games over the years and even swapped consoles with friends, including an N64 which introduced me to the world of Nintendo. In Lecture 1; Fundamentals of Game Design (Conroy), we discussed how culture naturally forms around games and play. This resonated with me, given my own experiences, sharing and playing video games with friends. My friends and I have incidentally formed a unique culture of our own which stemmed from our mutual ownership and playing of games throughout our lives.

What kind of gamer am I?

While studying in my first week of game design I came across a concept I found interesting written by Richard A. Bartle (Bateman, Step 4). Professor Bartle talks about the four main types of player, from the point of view of a game designer.

My interpretation of the four gamer types are:

Achiever - That friend who brags about getting 100% in every game they get their hands on.

Explorer - They love to learn the lore of the world and discover all the cool things in the game world.

Socialiser - Plays the game to hang out with friends or to meet new people. Often found hanging out at the grand exchange in their favourite MMO.

Killer - They're those SOBs that hang out on your ship spawn killing you in Sea of Thieves! Yes I'm still salty about that 😠, they didn't even take my loot 😂.

Metroid Prime developed by Retro Studios

I can safely say that I'm an explorer. The first game I ever got truly obsessed with was Metroid Prime developed by Retro Studios. To me, Metroid was about exploring an abandoned and corrupted alien world. I got hooked on finding all the lore walls to piece together the story about why the world was corrupted and to find out what happened to the mysterious Chozo who left behind such beautiful and intriguing ruins.

What do I hope to get out of game design?

My dream is to write backend code for games and to have the skills to turn boring old phone apps into more enjoyable experiences. Even if that dream doesn’t pan-out, this class will be a valuable opportunity to learn design practices which I wouldn’t normally learn in my more technical computer science degree.

Gaming has always been an integral part of my life. I’ve always been subconsciously aware of the culture my friends and I formed and I internally knew what kind of gamer I was – I just never had the vocabulary to describe it. Just one lecture of Fundamentals of Game Design, has prompted me to critically reflect on why my experiences playing games have been positive ones and making these links has shown me how I can tie academia to my game design.

So far, the theoretical concepts I’ve been introduced to have been very insightful and have inspired me to apply these theories to my own game design. I hope this class will continue to open my eyes to the concepts which make good games so enjoyable.

References:

Conroy, David. “Fundamentals of Game Design Lecture 1.” IGB-220 Fundamentals of Game Design, 25/7/2023, Queensland University of Technology, Online. Lecture.

Bateman, Chris. Beyond Game Design : Nine Steps Towards Creating Better Videogames, Course Technology, 2009. ProQuest Ebook Central, https://ebookcentral.proquest.com/lib/qut/detail.action?docID=3136230.