logankocon1

[logankocon1]

Racer Development Post

Let’s talk about the development of Bad Tires. Like all my other games, I started by following the tutorial slides as a basis for my racer game. Following the tutorials got me some basic player car movement (that I would later completely overhaul), spawning cars, collision, moving trees, and a myriad of useful assets. This served as a great basis for the start of my development. 

Basic version of the game at this point.

The first thing I wanted to do was develop the movement of my car to match the movement described in the elevator pitch. The basic idea was to not allow the player to directly move left or right, but to only allow the player to rotate. However, the player can change the axis point by which the car rotates, either from the top or the bottom. Switching between these axes will actually allow the player to move the car. 

This was surprisingly difficult to implement. I originally thought it would be as simple as adding different “points” on the car sprite and changing which point the car rotates around depending on user input. However, I quickly learned that GDevelop doesn’t support this; in fact, you can only rotate around the centre point. Fortunately, you can change the centre point, but only through the engine (this can’t be changed during runtime as an action). My solution to this was to create a separate car object with a different centre point and simply switch the objects whenever the player wants to switch their axis of rotation. Again, not so simple. Spawning this new car at the same position with the same angle didn't put it in the same spot.

Offset positioning of the cars

This is because, since the new object had a different axis of rotation, when I would rotate it to match the angle of the original car, it would rotate around a different point, thus changing its position relative to the other car. This was incredibly annoying. I tried using math to adjust the new car’s position to line up with the old car, but couldn’t get it right since the amount of offset would change based on the angle. Finally, through sheer will, I figured out that using the “put around” action and matching a “spawn” point on the original car with the origin point of the new car would line them up perfectly when I set the angle of the new car. 

Actions to swap cars

Once I got the switching between cars logic working, all I had to do was set the rotation for each car, and the movement was complete. I allow the player to rotate a full 90 degrees, giving more freedom of movement. The result of all of this was a really dumb and hard game. It reminds me of QWOP, with its wacky and frustrating controls. But, like QWOP, I find it quite fun. Getting used to the movement and finding ways to make the car easier to control is part of the fun. But I still thought it was too hard, so I lowered the spawn rate of the cars (made them spawn every 4-6 seconds) and implemented a lives system. If a player touches a car but still has remaining lives, the player loses a life, and the car they hit is destroyed with a smaller version of the explosion animation spawned.

Collision with car

Due to the difficulty in implementing the movement, I didn’t have time to create different textures for the car based on the number of lives like I wanted, so I just displayed it in the corner next to the score. 

Because the car has such precise movements, it should be able to get really close to the other cars without touching them. The default collision mask, however, was too wide for this, resulting in the player often losing a life from a car they didn’t even touch. Because of this, I went through all the car sprites and added a custom collision mask to make it fairer for the player.

Example of updated collision mesh

At this point, I was almost done. I put the two player cars into a new “CarGroup” so I don’t have to take into account both cars, I can just use the car group for things like detecting collision with traffic. Finally, I implemented a simple game over screen that lasts 3 seconds before restarting, and made the background green to give the trees some grass to grow on. 

I like how this game turned out. It’s frustratingly weird, but it’s fun playing around with it and trying to learn and get better at its mechanics. I could definitely use some more playtesting to really fine-tune it, but for now, I think it’s really fun!

[logankocon1]

Racer Elevator Pitch

Gameplay

For my third and final tutorial game, I will be creating Bad Tires. In Bad Tires, the player must navigate through multiple lanes of traffic, avoiding cars in the ongoing and incoming traffic lanes. For each car the player successfully avoids, they will receive a single point. However, as the title may suggest, driving the player’s car isn’t as simple as one may assume. Rather than simply moving left and right, the car can only be driven by either turning the back tires or front tires while braking the opposite set of tires. As a result, movement is done by rotating the car around the front or back as the axis. This creates a dynamic and unique movement system with, what I imagine, will be a tough learning curve. As a result, I plan to make the positioning of the cars more random, but less forgiving than the in-class demo version of the game. I will also create a lives system denoted by visual damage to the car. 

Why It’s Compelling

This game, like the others, features an arcade-like gameplay loop, meaning the player's objective is to survive as long as possible, thereby earning the highest score possible. The unique movement system offers players a racing game that is dissimilar from anything they’ve played before, and ideally, the desire to conquer this unique system will be a good motivator to play. I also think that because driving is so unique, most players will be very bad at controlling it at first, making their progress much more rewarding. I think striking a balance between difficult and frustrating with the driving mechanic will be essential while building the prototype. 

Setting

In Bad Tires, you play as Brad Tylers, a businessman late for an important meeting. You drive your poorly-maintained car as fast as possible down the highway of an Australian city and through ongoing traffic to make it to your meeting. Too bad it’s so far away.

Target Audience

Anyone looking for a challenge in a game.

Elevator Pitch For Bad Tires

In Bad Tires, you play as Brad Tylers, a businessman running late for an important meeting. While Brad does have a good understanding of driving safely, he unfortunately must drive exceedingly over the speed limit into oncoming traffic in his… less than ideal vehicle. He’s late for work–what is he supposed to do? Players must control Brad, steering his vehicle, making wide turns, and spinning through traffic, in an attempt to avoid colliding with the other cars on the road. The longer you can keep Brad alive, the higher your score. He never seems to actually make it to work, though.

[logankocon1]

Asteroids Game Postmortem

One thing I really wanted to incorporate from the readings in the design of my Asteroids game was the concept of multiple systems working together to create a cohesive experience. The platformer I designed mostly revolved around a single system, the movement of the player. Sure, there were platforms and enemies to avoid, but these objects were fairly static and didn’t provide much other than a tool for the player's movement. However, an Asteroids game can be much more complex, allowing for systems to be designed to work well with other systems. For example, when a larger asteroid is destroyed, it spawns multiple smaller asteroids, making asteroids often “bunch up.” This is why I implemented the mine, since it would allow the player to quickly destroy a lot of asteroids when they are grouped together. However, the player would have to time it properly, due to the mine’s time to detonate, adding more strategy and depth to the system. This is a good example of multiple complex systems working well together in my game. 

One thing the book talks about is prototyping different new and unique systems and mechanics. A good example mentioned in the book is Katamari Damacy, a game made up of a completely unique mechanic (rolling a ball around, picking stuff up), that started as one developer playing around with a prototype. I think this is something I should aim to do with my prototypes, and something I didn’t really do with Asteroid Miner. Sure, I played around with different systems and how they interact with each other, but I didn’t make those systems unique. Dash, mine, and laser beam abilities are easy to develop and don’t provide the player with a unique experience. For my next game, I want to try to be more creative, making multiple interesting and unfamiliar systems that also blend together well. I want to, essentially, combine what I believe I did well in my platformer game with what I did well in my asteroids game. We will see how that goes.

[logankocon1]

Reflecting on Chapter 5 of the Textbook

Let’s take a quick break from discussing GDevelop and the games I’m creating, and go on a small tangent. Chapter 5 of the class textbook dives into game systems, their elements, and how they interact with each other, which I found quite interesting, so I’ll talk about it here real quick.

The entire textbook, but this chapter in particular, seems to attempt to quantify and deconstruct game systems and how a game functions. I’ve always found those sorts of things interesting, since game design is something we instinctively understand through our experiences playing games. We understand that games have different objects and systems that interact with each other. We understand, in an abstract manner, how these elements come together to make a game. And, most importantly, we understand when a game is or isn’t fun. 

What I find interesting here is how the chapter quantifies these things. It explains that, yes, a game has objects that have specific properties and follow specific rules, and have certain abilities, and must be controlled by the player in a certain way. The chapter explains why games may be considered unfun. For example, if a game is unbalanced, meaning certain players have unfair advantages, it hurts the fun factor of the experience. Players would feel that when playing an unbalanced game, but be unsure why. 

 Being able to deconstruct games and understand elements like objects, properties, controls, feedback, etc in more than just the abstract way you would understand them by only playing games, allows game designers to be quicker in their design process, understand the game their designing entirely, be able to know what individual parts need tweaking based on playtesting and feedback, and communicate their design and vision easier. This makes the content of chapter 5 and the entire textbook invaluable to a game designer. 

[logankocon1]

Asteroids Game Showcase Video #2

Showcase of the game over screen.

[logankocon1]

Asteroids Game Showcase Video #1

Showcase of the mine and explosion ability. Yes, my explosion texture is really bad.

[logankocon1]

Asteroids Development Post

Looking back on my original elevator pitch for this Asteroids game, I didn’t realise how much would be required to develop the simple Asteroids-style mechanics and the extra abilities for the player. This post will detail the process I went through and the final outcome for my rendition of Asteroids.

Similar to the platformer, my basis for developing this game was to follow the tutorial slides, creating a simple but functional game. After the tutorial, I had functioning ship movement (following the mouse cursor), a working gun that fires bullets in a set interval, a system for spawning large asteroids with a random texture (from a set of 3), and a simple game over screen.

The first thing I developed on my own was the firing engines mechanic (dash). This was trivial, as all I needed to do was add a large force for about a second when the “shift” key was pressed, then set the motion of the object to zero, resetting movement after the dash. However, I wanted the number of possible dashes to be limited, so I added a new “Charge” variable that incremented for every asteroid destroyed and was spent to use special abilities. At first, I set the cost to 5 ���charge” but decided 10 was more balanced after some testing. I also decided I wanted a visible fire coming out of the back of the ship while it was dashing, and the given triangular ship texture was too simple. I created a new ship texture and a variant with fire coming out of the ship. 

Player ship texture

Next, I wanted to add more variety to the asteroids, similar to the original game. I made it so that when an asteroid is destroyed, two smaller asteroids spawn, flying in random directions. To do this, I added a medium asteroid and a small asteroid object, and spawned them with a force towards a random angle when a larger asteroid was destroyed. No asteroids are spawned when a small asteroid is destroyed. They also spawn with a random texture, giving more variety. 

To add the beam weapon ability, I created a custom beam texture that would temporarily spawn in front of the player when “1” was pressed on the keyboard. After the beam sprite is spawned, I also stop the player, making it so that the position of the beam is fixed and giving a moment of vulnerability to the player every time it is fired (this is a design choice). I also have to rotate the beam to match the angle the ship is facing. To create the mine ability, I created two more custom textures: a mine texture and a (really bad) explosion texture. When the player presses the “2” key, it spawns a mine object at that position that will, after a few seconds, spawn an explosion object, which is much bigger and destroys anything it collides with (player included). Finally, I set a required charge cost for both abilities and subtracted that amount from the charge when they are used.

Mine texture

Beam texture

For balancing the ability costs, I found that the dash costing 10 charge felt like a good balance, and I knew I wanted the other abilities to cost more than the dash. At first, I tried having the beam cost 20 and the explosion cost 30, which felt like a good cost for the beam ability only. Because of the delay between dropping the mine and the explosion, and the fact that it can also kill the player, the mine was much less effective than I imagined it would be. To fix this, I brought the mine’s price down to 20, same as the beam. This made the game feel more balanced and had the extra bonus of the player having to know fewer numbers. 

One final thing I did, mostly because I just couldn’t get the idea out of my head, was to update the game over screen, making it a view of space with destroyed ship pieces floating about. I created three new textures made from different parts of the ship texture, and added them as three new objects in the game over screen. I added an event that, at the start of the game over scene, created these three new objects and gave them a light force drifting away from each other. Finally, I moved the “game over” text and displayed the score.

Now, I never actually added any shop or roguelike mechanics that I outlined in the elevator pitch. I should probably stop saying I’m going to do that. Truthfully, I didn’t actually think I would have the time to implement any of this, but it sounded like a really cool idea for a game, and if I did have time, I would’ve, so I included it in the elevator pitch. I’m not sure this is the right approach, but it’s what I did. For the next game, now that I’m equipped with much more knowledge of game development and GDevelop, I will create an elevator pitch based on what I think is fun AND what I can implement in a relatively short amount of time.

Basic gameplay video

More gameplay videos can be found in the posts above.

[logankocon1]

Asteroids Game Elevator Pitch

Gameplay

Asteroid Miner features gameplay very similar to Asteroids. Rather than trying to reinvent the gameplay of Asteroids entirely, I decided to keep the core gameplay mechanics and build off of them. The player can move their ship around from a top-down view and fire a weapon while avoiding Asteroids. However, they also have other abilities, such as firing their engine (essentially a dash move), firing a laser beam that destroys all asteroids in a line in front of the player, and a mine that will destroy all asteroids in a certain radius after dropping. The player can only use these abilities after building up a “charge” by destroying asteroids. Unlikely my previous game, I think Asteroid Miner may be better suited to a rogue-like gameplay style, where the player can purchase upgrades and further abilities. However, once again, developing this feature may prove difficult with the limited time allocated to this project.

Why It Is Compelling

I think this idea is compelling because, at its core, it has the same gameplay as Asteroids but with a twist. Adding new features and abilities for the player to use gives them more options for gameplay and more unique tactics they can use to win. Using their abilities effectively will reward the player with more charges to use their abilities again sooner, meaning a skilled player can quickly destroy multiple asteroids with a completely different strategy to regular Asteroids, while still having that simple Asteroids gameplay at its core.  

Setting

You are the captain of a spaceship that works for some company to destroy asteroids for their natural resources. Your goal is to fly through an asteroid belt, destroying as many asteroids as you can to earn as much money as you can. This concept also serves well to that rogue-like idea.

Target Audience

Anyone interested in arcade-like Asteroids-style games.

Elevator Pitch for Asteroid Miner

In Asteroid Miner, you control a small ship flying through an asteroid belt, looking to destroy as many asteroids as possible, collecting their resources for money. However, the job is dangerous, as your ship has seen better days, and a collision with an intact asteroid could completely destroy it! To succeed, the player must navigate the asteroid belt, destroying as many asteroids as possible with their main gun while also avoiding coming into contact with one. Destroying asteroids can also build up your ship’s “charge”, allowing it to fire its engines and use more powerful weapons. In between rounds, the player can use their earnings from destroying asteroids to purchase different upgrades and more powerful abilities to fight through more dangerous asteroid belts!

Controls Diagram

[logankocon1]

Platformer Postmortem

The main part of the readings that inspired my design was the earliest introduced and probably most important aspect of the book, the player-centric approach. This was reflected in my early concept for a rogue-like platforming game. While I still think this was an interesting idea and would have been fun to develop, with the time I have for this particular project, I don’t think I could have made it fun. And that is the most important thing. The idea of iterating your game to make it as fun as possible from the textbook is an idea I used throughout every step of this project. Throughout the initial design and development of the base features, I tried to make everything as fun as possible, and continuously iterated, especially at the end, making big and small changes.

While I do like how the prototype turned out, I would’ve liked to flesh it out more. This would include adding a more advanced scoring system, expanding the level, adding more levels, and adding more enemies. Fleshing out different systems and giving the player clearer goals will reinforce the gameplay loop and give the player more motivation to play the game. I would’ve also liked to make the movement feel more responsive. I could accomplish this by adding more animations, continuing to tweak the movement to make it feel better, and adding effects based on the player’s actions. This would make for better kinesthetics and a more fun experience.

[logankocon1]

Platformer Playtesting and Insights

Once I had a fun and playable version of my game, I knew I needed to playtest it. The textbook emphasises the importance of playtesting your game at every step of the way, and this phase is one of the most important. Fine-tuning completed systems to make them as fun as possible for the player is essential for making a great game, especially with a wide range of playtesters to get the most comprehensive feedback possible.

Since this is a relatively small game, I just playtested it with myself and my partner, trying to pinpoint any issues that would get in the way of the player experience. We both concluded the game had two major issues: it felt too slow, and it wasn’t very challenging. One of the main things I’ve learned this semester is that a good game needs to be consistently challenging in order to keep the player’s attention. 

Solving the issue of slowness was as simple as changing the movement variables to create a better feeling when controlling the character. This included increasing the jump speed, gravity, and the “launch downward” speed. The real breakthrough, however, was allowing the player to move left and right faster. This not only moved the player quicker but gave them more control, allowing them to move toward different platforms, increasing the overall speed of gameplay. We both agreed that these changes made the game feel faster and more responsive. 

Now that the movement was very fun, and it was decided that the main conflict was to avoid getting hit by the monsters, making the game more challenging just required adding more monsters. I scattered some extra monsters around the map and changed the sizes of some of the platforms. My partner also had the idea to remove the bottom platform, making it possible to fall out of the map. This idea adds an extra dynamic to gameplay and navigating the map but would need more time than I currently have to implement fully, requiring detection for the player being in the void and a means for the player to know there is no platform under them since vision is limited.

Here is a quick snippet of what the gameplay looks like in its final state.

[logankocon1]

GDevelop Platformer Development

For Moon Jumper, the technical basis is the simple platformer game that was outlined in IGB120’s week 2 workshop. This game gave me a really good starting point to building my game, giving it a controllable player character, simple platforming moving mechanics, collisionable platforms, functioning enemies, and art assets. A lot of this is useful for the game I want to create, outlined in my Elevator Pitch post. 

The first thing I did was update some of the assets to create a visual style more in-line with my vision. Some of the assets, especially the astronaut player character from the tutorial assets, were fitting enough. I created a black background image with white dots scattered about it as the backdrop of space and found a cartoonish moon texture that I could use as the tiling platform texture. 

Once I had a quick, clean visual upgrade, I began working on creating the movement mechanics. Since I knew I wouldn’t have much time for this particular game, rather than adding a bunch of different features and completely fleshing the game out, I opted to treat it as a gameplay prototype for the movement mechanics. I used some of the information from chapter 8 of the textbook, which details digital prototyping, as a basis for this. I knew my control scheme wouldn’t change, and the game wouldn’t need major technical prototyping, so I focused mainly on gameplay mechanics and kinesthetics. 

The first thing I did was add a simple “bouncing” mechanic, making it so whenever the player came into collision with a platform, it would simulate the jump button being pressed. By also lowering the gravity of the player character in the behaviors tab, I accomplished the bouncing and floatiness feeling I was looking for. I could even control the player slightly by moving left and right. 

Finally, I made it so that when the player hits “space”, a strong force is applied downward, shooting the player towards the ground, giving them more control over the movement. This was the basis for my movement, but I knew it would require a lot of iteration. To playtest this simple movement, I built a small level, placing platforms and monsters down. This allowed me to change my mechanics, mostly by changing values like the amount of gravity, jump speed and time, and the force applied when pressing “space.” By playing the game and making changes accordingly, I was able to get the movement to a place that I think is pretty fun. However, I believe the game requires more playtesting to figure out what features to change and add and how to fully fine-tune my movement.

Final movement result. As you can see, the current mechanics allow the player to bounce off the side of platforms, which, in my playtesting, was quite fun.

[logankocon1]

Moon Jumper Elevator Pitch

While I have been admittedly behind on posting to this blog, I have been keeping up with the unit lectures and reading over the previous few weeks. For my game concept, I have attempted to apply the player-centric approach that the book outlines, focusing on making the base structure of gameplay as fun and rewarding as possible. My initial idea was to create a rogue-like type platforming game where the player can purchase upgrades with coins that make the levels easier. However, I wasn’t convinced this game would be fun, nor would I have time to implement such a complex system. Instead, I opted to focus on creating a fun and unique movement system and building the level based on that.

Gameplay

My ideas eventually evolved into Moon Jumper, a platformer with a very simple movement system, requiring few controls. Essentially, the player bounces around the level with low gravity and controls the player character by pointing in a direction, left or right, and hitting “space” to launch downward in the direction they’re pointing. This gives the player control over the movement, but makes precise pathing extremely difficult, giving the game a skill progression.

Why It Is Compelling

I believe this idea is compelling because it utilises the player-centric approach, with a simple gameplay structure designed to be fun and easy for the player to learn. I also believe the weightiness of the low-gravity gameplay will give the game a unique feel and make it difficult to master. Dropping any complicated systems to focus on movement definitely seems like the right choice because movement is the most important part of a platformer, and having a unique, fun and engaging movement system is the best way to maximise player enjoyment, which should be the main priority.

Setting

As the name and graphical representation suggest, the game will take place on the moon, having a dark pallet with bright stars in the sky.

Target Audience

The target audience is anyone who enjoys arcade-type games and is looking for a unique platforming gameplay experience.

Elevator Pitch for Moon Jumper

In Moon Jumper, the player plays as an astronaut trapped on the moon, forced to use the moon’s low gravity and their jetpack to maneuver the level, avoiding the flying “moon monsters,” In this game, the player will move with a unorthodox, weightless feeling, while still retaining control by being able to move left or right, as well as using the jetpack to launch the astronaut toward the ground. The game doesn’t have multiple levels, playing like a platforming arcade game, where the player’s score is represented by how long they were able to survive the moon’s unforgiving environment. 

A graphical representation of the gameplay and a game controls diagram can be found below.

I am working on just a simple platformer to build off of that I will detail in my next post, and once I have a working prototype for Moon Jumper, I will post about that too.

[logankocon1]

Introductory Post

Hello! My name is Logan Kocon. I am a third-year IT student majoring in Computer Science, and I'm taking both IGB120 and IGB180 this semester as electives for my penultimate semester at QUT.

I have been into games since I was very little when one of my dad's friends let us borrow his PS3 while he was on vacation. We played it every day, and when it was finally time to return it, we drove straight to the store to buy one of our own. These days, I mostly play PC games, but my favourite games are still those PS3-era ones. Games like Oblivion, Fallout: New Vegas, and Uncharted 2.

In this class, I hope to learn more about games, how they're made, and how I can make my own one day. It's always something that's interested me, but something that seems extremely hard, considering how many bad games come out. While I don't plan on getting a job in the game industry right out of school, I hope to use the skills I gain in this class to work on side projects and, maybe one day in the future, create my own indie game.

Anyway, that's a little bit about me. I look forward to continuing my work in this class and documenting it here as I go! :D