cjk-uni

[cjk-uni]

Submission & GG

And that's it for IGB220! I really enjoyed giving my design muscles a flex and implementing them in GDevelop. I found the lecture content to be really stimulating and enjoyed the theory of game design as it was presented in the content. Shout out to Chris for all of his help in the Thursday tutorials and cheers for the good unit.

GG!

[cjk-uni]

Assignment 3 Postmortem

Zombie Survivor turned out to be a fairly satisfying little game by the end of it, and I'm pretty happy with how it turned out. I think that we got our game play loop nailed down pretty well and I was happy with how my infinite difficulty turned out. To be honest it was easier to implement the infinite difficulty than the weapons, I had particular trouble implementing the melee weapon and in future I'll probably tie player weapons to the player's animation itself rather than drawing separate objects on top of the player.

I was disappointed that we couldn't implement some of our play testing findings, particularly the usability features that I wanted to finish off the game with but unfortunately I ran out of time. I would have liked to implement hit numbers and a further enemy health system so that we could have more enemy variation such as bosses and the like. I also wish that we made it a little more clear to the player when the weapons spawned (at 1000 points and 2500 points). These usability considerations would have gone a long way to make the game a lot more playable for unskilled or otherwise inexperienced players.

Overall I'm proud of Zombie Survivor and I think that the systems I implemented are pretty great considering the limitations. If I could do it again I probably wouldn't do it in GDevelop and I'd probably be trying to develop something with a much larger scope. I hope in my development career I can work on some substantial video game projects!

You can check out Zombie Survivor here: https://gd.games/woolies/zombie-survivor

[cjk-uni]

Assignment 3 Iteration and Changes

Developing Zombie Survivors presented some challenges in implementing an experience that is "rouge-like-like" in that we cant feasibly implement an actual rogue like in GDevelop but rather we can try to emulate how a rogue like feels in the game. Primarily Zombie Survivor has ended up being a bullet hell game where the bullets are the zombies bouncing around the screen rather than enemies who shoot bullets at the player.

Most of our changes were positive additions and iterations on the previous design choices such as the addition of a timer and iteration on how the scaling difficulty works. Our difficulty is now truly infinite, with the theoretical limit being how many zombies GDevelop can handle rendering on screen (probably a couple hundred). I'm proud of my system for incrementing the rate of zombie spawn - that being increasing numerical scene variables that control the amount of zombies that spawn at once. This variable is increased based on player score rather than time, which was a decision I made with the intention of making the game a bit easier on slower players who are learning the controls.

Other changes were based on our play test feedback such as a back button that sends you back to the start screen, as one of my testers wanted a way to change the controls because they really didn't like the mouse led controls. Frankly, neither do I, but its a leftover from the Asteroids prototype that the game is based on and I thought that I'd rather keep it around as an option than get rid of it outright.

[cjk-uni]

Assignment 3 Playtesting

Very early playtesting revealed fairly obvious issues but yielded some suggestions that were somewhat unexpected. Most of Ethan's playtest results were things like enemy collision, lack of animations and things like player death which were addressed in updates last week. Some other results from that test were things like no how to play instructions and the option for WASD movement aswell as mouse movement. I think that these can be implemented fairly easily with the addition of a main menu screen and the implementation of WASD movement.

notes from our initial playtest

WASD Movement is implemented by having a controls screen that allows the player to choose between WASD and mouse input, and similarly the how to play feature is simply a scene with text that instructs the player on how to play the game.

Control screen (chose WASD movement here)

Some other goals from playtesting include adding functionality for the weapons that we currently have (dynamite and the bat). This is one of my goals for this week, however they need animations in order to be implemented properly which at time of writing I'm waiting on group members to deliver. Other than that we've addressed other small things like fire rate and the player direction not changing already and hopefully we'll address the others before week end.

[cjk-uni]

Assignment 3 Development 1

Development in earnest on the project began pretty soon after part A was submitted in week 10. My first order of business was bringing the Zombie Survivor prototype up to a playable standard. First we needed enemy collision to be implemented (weapons colliding with enemies and enemies colliding with player) and for the player to die when their health reached zero. Both of these were added rapidly, as my experience in class carried over really well here.

basic hit detection and player death

Next up was getting enemy behavior working a bit better, laying the foundation for scaling difficulty and adding score. One of our features is endless difficulty, the game getting harder as the player goes along. To implement an early form of this I made it so that the zombies spawn in steps based on player score. Different zombies score differently, and I'd like gameplay to reflect this by making the bigger zombies take more hits to destroy. Before implementing that however I implemented the scaling spawns, scoring and changed the enemy behavior so that they move toward where the player is at the time that they spawn (which should be enough "AI" for our purposes).

scoring, spawning toward the player and spawning enemies in steps (big zombie spawns at 1000 points)

[cjk-uni]

Assignment 3 Group Formation & Discussion

Because of circumstances out of my control, I wasn't able to attend class when we were forming groups and had to form my group over discord. This worked out fairly well, as I ended up in a team with three other gamedev students which is pretty perfect as I'm much more a programmer than an artist. We discussed which Assignment 2 design we'd carry forward to Assignment 3, and we decided on a design called 'Zombie Survivors'. Zombie survivors is based on Asteroids with a more significant style lift from the original prototype than my Assignment 2 design.

Zombie survivors has heaps of new and original assets with really good looking zombies. I found that my strength so far in this unit is the development/implementation side of game design rather than the artistic elements, so using a prototype with heaps of new assets for it is perfect for me. We discussed roles and our playtesting plan and landed on a plan where we iterate based on a few playtesting sessions that take place during the life cycle of the project.

[cjk-uni]

Assignment 2 Final Design

I ended up naming my Assignment 2 design 'Stellarnova' which I thought was kind of cool. I tried to find something unique and as far as I know this name hasn't been used by anything fully published. I quite enjoyed ideating some game play ideas for the one sheet, maybe after my semester is done I'll come back and finish the prototype up and publish it on GDevelop. Its looking currently like we wont be using it for Assignment 3 but I'm pretty happy about the prototype that we're going to be using instead.

one page

sell sheet

[cjk-uni]

Racing Postmortem

In weeks 6 and 7 of IGB220, we worked on a racing game prototype that focused on teaching us about object groups and scene variables. The prototype further expanded on the concepts of balancing and rules in games, by having us tune the car's handling and have the cars coming down the road work in such a way that kept the game fun but also incorporated some real difficulty. I found the process of finding car handling values that work in a way the the player expects and also feels "good" or "satisfying" to be a really valuable experience.

I did some play testing at uni with the car prototype, and had a friend of mine try a couple different handling values for the player car and we came to the conclusion that the player car feeling "weighty" was the best rather than it being really fast and maneuverable. The more "weighty" feeling car made hitting really tight moves around obstacles really satisfying when you pull it off.

I think I learnt some really valuable technical skills in GDevelop these last few weeks, I really wish I knew about object groups sooner as it'd make the code I made for assignment 2 significantly simpler. I'm feeling really good about assignment 3 after these learnings, I think I can implement just about anything in GDevelop with my new knowledge and previous experience coding.

I do wish that the prototype from these weeks ended up being a little more complete feeling, as I find the Asteroids prototype significantly more compelling than this one. I do think that if I took some time out to extend this prototype's gameplay to fit my elevator pitch it could be a fair bit more interesting, but the way it is currently is pretty barren in terms of gameplay depth. It was a good way to learn the skills from these weeks though.

[cjk-uni]

Assignment 2 Progress

My Design for Assignment 2 was essentially an extension on the game mechanics we developed in asteroids. I experimented with Asteroids and attempted to extend its game play to add enemy ships to fight and gave the player a special ability.

some art from assignment 2

I set out mainly to see if I could make Asteroids more interesting and difficult, and experimented with different ways to make the prototype more difficult. I implemented one enemy into the prototype, the little red UFO on the right in the picture above. It shoots bullets all around it in a circle turning making the normal game play of Asteroids significantly more chaotic.

I intend to implement the other two enemies into the prototype if I have time after making the one page and one sheet, but this will be unlikely if I end up choosing a different design with my group. I thought a little about player expectations in my design and thought that adding space pirates into the game that takes place in an Asteroid field shouldn't be too far outside of existing player expectations.

[cjk-uni]

Racing Prototype - Development 1

In week 6, we began work on a racing game prototype in GDevelop. The development of this prototype began with implementing the movement behaviors of the player car. I tweaked the angle changes of the car to values that I felt were better and slightly more "realistic" or perhaps, behaving in a way that is more expected. The camera was also centered on the highway.

After this I implemented vehicle and tree spawning, I learnt about object groups and worked more closely with scene variables to implement this functionality. By the end of the workshop I had a fairly compelling little prototype where the player could dodge and weave through infinite traffic. I quite liked how the prototype created the illusion of movement when the player wasn't actually moving necessarily.

Once this was all implemented all that was left was collision and scoring. Implementing collision was fairly straightforward after my learning from the Asteroids prototype. This time however, the collision into other objects is based on groups of objects rather than having a collision rule for each type of object individually.

With functional collision, all that was left was developing a scoring system that increments as the player passes cars. There are probably a couple ways of doing this, but I implemented it in the way that the workshop specified by having the score increment as cars leave the play space.

With both of these implemented I had a pretty good little infinite racing prototype. I learnt a lot about object groups and scene variables when developing this prototype, which is knowledge im keen to carry forward to my final assessment for this unit.

[cjk-uni]

Racing Prototype Elevator Pitch - 'Fury Drivers'

'Fury Drivers' is a top down action racing game that has the player avoid obstacles and other racers to reach the finish line. 'Fury Drivers' not only challenges the player to find the perfect line and make those perfect corners, but to also avoid challenging obstacles and fierce competition.

'Fury Drivers' boasts a action oriented design that grips the player with its fast pace and chaotic tone. With bright poppy graphics and awesome music, 'Fury Drivers' demographically appeals to a broad audience from kids to teens to adults. 'Fury Drivers' can is played via a variety of control schemes from controllers to mouse and keyboard, with support for racing wheels included.

Set in an apocalyptic future, the player must navigate an endless desert of dangerous outlaws and dangerous obstacles left behind by the old world.

[cjk-uni]

Asteroids Postmortem

In weeks 4 and 5 of IGB220, we worked on a prototype of the classic game Asteroids in GDevelop. We covered many aspects of development in GDevelop and created a functional Asteroids prototype. The readings in these weeks covered functionality, completeness and balance which were incorporated into the prototype in a couple key areas. As I mentioned in the second development post, balance was a big theme in this prototype as there were many variables that could be changed to radically alter the difficulty of the game.

I thought alot about design intention for Asteroids, as its meant to be a ubiquitous title; accessible to everybody, but also carries the retro game identity associated with high difficulty. I tried a couple variations on game balance, like a super hard mode where heaps of asteroids spawned and they all moved really fast. This had implications for player health and speed, and the increased number of asteroids necessitated a faster fire rate so that the player could move through the field at all.

I also considered functionality and completeness during development, I found that the functionality of the game was greatly affected by whether bullets were deleted when they hit something. If they weren't deleted, they'd simply delete all of the spawned asteroids that they pass through and only leave asteroids that spawn precisely out of the path of the bullet. This compromised the key functionality of the game's asteroid spawning mechanic and had to be changed so that bullets disappear when they hit an entity.

I think overall Asteroids is a significantly more complete prototype as opposed to the platformer, as its entirely playable in its current state repeatedly. I think it has significantly more replay value over the platformer as each retry is different gameplay wise from the last. Its worth noting that this is largely a function of the simplicity of Asteroids over the platformer, as the platformer would require more hours of development for more levels and such to be more complete.

[cjk-uni]

Asteroids - Development 2

In week 5, I continued on from where I left off with Asteroids and finished the prototype. The first thing to do was to implement health and damage into my Asteroids prototype. This was implemented in a very similar capacity to the platformer's score counter, although perhaps done in reverse.

After this, I deviated from the worksheet slightly and implemented destroyed asteroids spawning more smaller asteroids. I did this at first by adding to the above event so that it would spawn more smaller asteroids when the ship collides with a larger asteroid. For example; Medium asteroids spawn three smaller asteroids

Next, I implemented the same spawning mechanic for the when a bullet hits an asteroid. I also worked out how to do simple for loops in GDevelop by using the Repeat event, which made my events easier to follow. I now had an Asteroids game that for the most part behaved in a fashion that most would expect, only missing lives and a game over screen.

The last thing to implement was the game over screen and score counter. To implement the score counter, I just re-implemented the same score counter from the platformer prototype. Next, I needed to implement a game over screen. To do this I followed the week 4 content and implemented a second scene that was my game over screen. I changed how getting back to the game screen works slightly by having it so that the player presses any key to get back to the game.

At this stage of the prototype, I thought alot about balancing. How many Asteroids should the large Asteroid split into? How fast should the player ship be? How fast should the ship fire bullets? All of these were fiddled with to an extent to see what the correct game balance of Asteroids should be. I think that the prototype behaves in the way most people would expect Asteroids to behave, and I think its pretty fun too.

[cjk-uni]

Asteroids - Development 1

In week 4 we began development on Asteroids, the classic video game where the player is charged with navigating a ship through an asteroid field. Preliminarily, I was able to rapidly have the ship move while following the cursor by having it follow the cursor's X and Y coordinates with a move and rotate action.

Next we added bullets the shoot out from the ship. This turned out to be a fairly complex task as we needed the bullets to shoot from the correct point on the Ship sprite and we also needed them to shoot at a reasonable fire rate.

We achieved a correctly shooting space ship by introducing scene timers, which help us control the pace at which events happen in the GDevelop engine. Using timers we were also able to randomly spawn asteroids using random integers around the map. This task also involved some level of complexity as the spawning behavior had to be changed so that the asteroids don't spawn on top of the player.

When reading chapter 3 of the readings, I considered the idea of what Asteroids invites the player to do. It seems completely intuitive from the very first time you ever see the titular Asteroids that you need to shoot them and not run into them. This basic premise is likely what makes Asteroids so ubiquitous, as it's premise is so simple that the design can be understood fully by literally anybody regardless of age, experience or language.

[cjk-uni]

Asteroids - Elevator Pitch

'Asteroids' is a classic top down space shooter, where you must shoot an ever increasing amount of asteroids. There are many historical and contemporary examples of Asteroids, but all of them follow this fundamental principle. The game is set in a section of empty space populated only by the player and a field of Asteroids. When an Asteroid is destroyed, it often splits into smaller Asteroids, but there is some variation here across different versions of the game.

The audience and demographic for Asteroids is incredibly broad. Asteroids was designed at such a time in the development of video games where broad appeal was paramount to any form of success in the burgeoning arcade market, where any form of video game cabinet would impress the average person who may have never encountered any type of video graphics before. All of this is to say that Asteroid's intended appeal was to literally everybody, and as such its visual style is incredibly minimal even to this day.

[cjk-uni]

Platformer Prototype - Postmortem

In the first couple weeks of IGB220, the readings helped me conceptualise the design intention of our first prototype and who it was trying to cater for. It seemed like the assets we were provided were created in a way that would appeal to children, suggesting that we were designing a simple, easy and highly user friendly platformer prototype. Although I was designing in step with the tutorial content, I realised that a platformer with this intended player - that being a little kid or someone new to games, would require a digital prototype that was principally user friendly and not especially challenging. Something more along the lines of 'Super Mario' rather than 'Super Meat Boy' or 'Cuphead', for example.

If I could go back and develop the same prototype again with the knowledge of GDevelop and game design generally, i'd probably retool the assets to change who i'm catering the experience for. I've always thought that creating games solely for small children, while theres certainly a place for it, is limiting in terms of mechanical depth. I've always felt like I wanted more out of the average Mario title, i've run and jumped a million times and want deeper systems out of any platformer that I happen to play. Specifically, I'd change the intended audience for the platformer to be more broad, such as how the intended audience for something like 'Cuphead' is significantly broader than other examples as its artstyle appeals to both young and old, and boasts a very challenging level of difficulty.

If I could make some fundamental changes to the prototype, I would like to make it faster and more responsive to input. I'd like to add sound and visual effects that make the game feel more alive and help deepen player engagement. I've always found that platformers that have a convincing sense of speed and audio/visual feedback to player action are the most compelling. I'm inspired by chapter 8's mentioning of kinesthetics or how a game "feels". I'd focus on creating a deeper kinesthetic engagement with the player via the use of visual effects and compelling sound/music.

[cjk-uni]

Platformer Prototype - Development 2

In week 3, we completed our platformer prototype by adding some of the expected game elements that most platformers have such as collectibles and a score counter. These were fairly straightforward to implement in GDevelop and I learnt specifically how to use scene variables in the engine to implement the score counter

In playtesting with Chaz (a student in my class), we noted how the jumpthrough platforms (the platforms that the player can jump through from the ground) behaved unexpectedly in that when the player stands on those specific platforms they fall through them. Fixing this issue seemed to involve some level of complexity outside of scope for this prototype, so the platforms had their asset changed to logs to try and differentiate them from the ground assets which behave differently.

I arranged the coins in such a way which directed the player on where to go. I wanted to really engage the player with the experience by directing them to jump up onto the logs so that they could get all of the coins. I considered how I could get a player to move toward a specified goal in order to engage them with the little tools I had, and came to this conclusion.