Alright, it’s time for my last devlog for the year of 2021. I think I’m ending this on a high note, as I’m actually really happy with how this project turned out. After finishing Week 14 I was away on holiday for a while, so I had some time to think about what game I wanted to make for Week 15. I had the idea of a top down brawler where you can punch both the left and right fists separately, I also wanted the fists to be actual GameObjects that are procedurally animated rather than in a sprite sheet.

One new thing I wanted to try out with this game was to allow myself to use third party assets a bit more for prototyping. One mistake I’ve made in all of my previous games was not relying on existing solutions to problems, and essentially reinventing the wheel. I used my own A* algorithm for a few games before replacing it with the A* Pathfinding Project. On one hand it’s good to write stuff from scratch for the purposes of learning, but right now I’m focusing on game design and high-level game programming. Writing a pathfinding algorithm from scratch is definitely something useful for me to be able to do, but it’s taking away from the final product as my time could really be used better elsewhere.

So anyway, for the game itself I started off by focusing purely on how it feels to punch an enemy. I ignored juice for a lot of my recent games, since I thought I wanted to focus more on making gameplay that can stand up on its own without any SFX or VFX. I think that was a major mistake, and I got the notion from a Reddit post a few years ago where someone mentioned that a game’s mechanics should be fun by itself with no juice. I don’t know if that’s a common opinion in the game industry, but personally I don’t like prototyping games without at least placeholder graphics or effects. So I downloaded the Feel Asset, the Cartoon FX Remaster Asset and the Universal Sound FX Asset. This way I had some generic effects and a nice framework to setup juice and micro-interactions without much code, speeding up my prototype time. Finally after a little bit of time in Unity after playing around with Feel, I had a simple punch implemented.

I really focused on the juice and feel here, not worrying about any other part of the game. I figured that if it’s not fun to punch an enemy in a fighting game, then nothing else is going to hold that up. I decided to focus solely on audio, and after a bit more tweaking I had a version implemented. I was very surprised just how much better the game feels with audio feedback. My biggest lesson here was not to underestimate how powerful audio is.

The next 2 days involved me implementing a simple Health, Stamina and Shield System. I also started to implement the VFX juice while tweaking the punch timings. I also made it so that when you KO an enemy, your last punch sends them flying a bit farther, just to emphasize the character’s victory. I used some of the placeholder VFX then for a ‘death’ animation. While I don’t think the effects really ‘fit’ with the game’s graphics style, it still is much better than having nothing at all. A player should be able to play this and get the gist of the game in the prototype. If it was to go into full production, I would change out the VFX and SFX to something more appropriate.

I kept on tweaking the feel of the punch while I worked on the other parts of the game. I wanted the enemy to have some form of intelligent AI, so they don’t just rush the player constantly. While simple, there are a few rules with how the engage the player in combat. For example, if the player punches an enemy and they have enough stamina, they will engage their shields and back away to protect themselves. They are very simple rules and it does make the AI seem like they have some intelligence. If I’m being completely honest though, it needs a lot more work to make them feel more ‘alive’. They’re still kind of dumb.

Unfortunately the game is quite difficult, but the stamina and block system at least gives the player the time to receive a number of hits. I intentionally gave the player more HP and Stamina, so that the enemies will tire themselves out from walloping the player. I also made it so that the player regains some HP after each round. I’m not too happy with this solution as it doesn’t feel like it changes the game for the better. There isn’t much strategy other than blocking an enemy when they hit you to drain their stamina. Then when they run out of stamina, you can quickly dispatch them by punching them multiple times in quick succession. On the bright side, I do think it feels satisfying.

I also spent all of Monday trying to fix a performance bug where the browser would slowly compile the shaders when a player is spawned. Sadly I couldn’t figure it out. It’s not noticeable on a native Window version, so if anyone reading this knows why shader compilation is so slow on Chromium browsers, please send me a message!

What went well

• Made a game that is actually fun to play for a few minutes
• Learned the importance of good VFX, SFX and Juice
• Implemented Hitbox/Hurtbox collision detection and response in a simple and clean way

What could have gone better

• I *technically* didn’t finish this game in the week, since I was working on a performance fix on Monday. Thanks, Chromium. It shouldn’t take 5 seconds to compile 10 shaders…
• I would have liked to add in actual graphics and an environment, but I really already went over time so I didn’t spend time polishing it.

What I learned

• I don’t like prototyping games without VFX or SFX. I enjoy working on the prototypes more when it feels more like a “real” game. I just need to be careful not to only work on polish and ignore fun gameplay like my sheep herding game from Week 5.
• It’s okay to use third party assets for things that I’m not skilled in. I can’t make VFX or SFX (yet), so there’s no point in doing it badly for a prototype when there’s already good resources out there that I can use.
• The problem with a lot of my earlier games is lack of feedback. I think even the mining game I made would feel way more interesting to play if the miners actually had a digging animation with a pickaxe SFX.

Summary

After making a few terrible projects in a row, I’m glad to have finally made something that I’m happy with. I learned a lot of important things making this project that makes me look back and see where I went wrong on my earlier games. Getting the core interaction polished and fun is something that isn’t new to me, I’ve read about it many many times but even then I feel like I ignored that advice for too long.

From now on I’m going to get the game feeling good immediately with some placeholder SFX and VFX. That will allow me to set the game’s mood and get closer to how I want to player to feel when they’re playing the game.

As always, if you want to try out the prototype, the link is right here:

1GAW – Week 15

Fast-paced round-based Beat ’em Up Prototype

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

So this game was released on the 3rd of December, and like the last devlog I’m posting this on the 21st of December. I’m still catching up.

The theme for this game was “Fire”, and is my last game based on the 4 elements. None of them ended up that good, so I think I’ll go pretty light on sticking to a theme from now on.

The idea was very simple, I wanted to learn how to use Behavior Trees to drive AI, and I also wanted to create a simple fire propagation system. I thought it would be cool to have the AI walk around a level, avoiding obstacles dynamically. They would also try to avoid areas with fire. If an agent was set on fire, it would panic and run around the level, making things even worse. I think I originally wanted to make something kind of like Infectonator, where you have a game where everything is calm, but you kick off a domino effect and everything ends up spiraling out of control. Sadly I didn’t get to implement success/failure mechanics or more complex AI, but that’s what I was moving towards.

What went well

• Learned the basics of Behavior Trees and the Behavior Designer Asset
• Setting the place on fire and seeing the AI freak out is fun. Kind of like how it’s fun to kill off Sims.

What could have gone better

• Like last week, the game is extremely simple and barely counts as a “game”
• Even though the AI is doing a lot in the background, there is very little feedback to the player for them to infer the AI state.

What I learned

• Feedback is essential to making a game enjoyable, or even playable. Especially for inferring AI state. Watching the agent run around and freaking out is fun, but having them shout expletives would have been even better.

Summary

Another bad project. At least I learned about Behavior Trees this week.

As always, if you want to try out the prototype, the link is right here:

1GAW – Week 14

Simple fire propagation prototype

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

Wow, so this devlog is a few weeks late. I actually finished my Week 13 game on the 28th of November and now it’s the 21st of December. I’ve also already released Week 14 and Week 15. Better late than never? I’m going to keep this short.

The theme for this week is “Earth”, and so I planned on making a game where you need to build an underground mine network to extract rare minerals. I really wanted to try out something interesting around AI, such as swarm mechanics. In a classic move, this turned out to be too large of a scope.

I ended up making a very barebones prototype where you can move your character around with the right mouse button and queue up “dig” tasks with the left mouse button. There is some interesting pathfinding going on in the background, where the miners will try to dig around certain blocks if they’re too hard. Unfortunately the build is buggy and it’s common for miners to get stuck in a mining action. Oops.

While this “game” turned out to be a pretty dreadful experience, I do think I like the idea behind having a group of worker units walking around with your character’s avatar. I think the fog of war adds a certain level of mystery, and I wonder if I could create a much more polished system like this for a horror game. I love the idea of making a game about escaping a research lab with your small squad, and having to order them to maybe hack certain systems or use machinery to unlock new areas and abilities. But if you have a group to small in certain areas, they can get picked off by the monsters. So there’s a balance between keeping your own self safe and the rest of your crew. If I ever make this game, at least I got the idea from making this prototype.

What went well

• Gained more experience with the Unity Tilemap
• Got an idea for a future game prototype

What could have gone better

• The game is extremely simple and barely counts as a “game”
• No graphics, audio or juice. Everything is just blocks.

What I learned

• Complexity != Fun, I should focus on tighter gameplay loops first rather than the larger progression loops.
• More complex strategy games would need multiple people working on a prototype, or I need to build up my skills to get to that point.

Summary

While this project turned out terrible, at least I finished and learned from my mistakes. Either way, this was still worth my time.

As always, if you want to try out the prototype, the link is right here:

1GAW – Week 13

Prototype for a strategy game control scheme

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

So this week I made an interactive fiction game in Twine! It was quite a different experience to making games in Unity (or even Godot), but it was an enjoyable one at least. Well, it was enjoyable when I was actually working on the game and I wasn’t procrastinating.

I was actually supposed to publish Week 13, but I ended up missing a week due to serious indecision as to what I wanted to make, and quite a lot of overthinking. This happens most weeks, but usually the deadline will force me to make something very simple and kind of uninspired. I then promise myself that I’ll make something really cool instead next week, but I overthink and procrastinate and the exact same thing happens again. If I’m being honest with myself, this is what’s causing me to make games that I’m not actually pleased with.

Even though there’s a lot of great advice and tools and methodologies to design games, I find myself stuck at the very beginning when I need to just decide what I’m making. It’s only when I get close to the deadline that I start working on it, and then I end up making something extremely pared down and far from the great ideas I had at the start but I was too afraid to work on in case they’re too lofty and I’m not able to make them.

One way I try to work around this is to place limitations on myself with a theme. This kind of worked for Week 11, where the theme was simply “Water”. However, I still ended up playing around with different ideas until I settled on a very simple game that I’m honestly not proud of at all and I wouldn’t have published if it wasn’t for the fact that I’m trying to be transparent about my game making process.

The theme for this week was “Air”. Next week will be “Earth”, and then after that will be “Fire”. I had ideas for games where you’re trying to build a city in the clouds, a game where you play as a feather, and some other high concept ideas. I ended up procrastinating so much and putting so much pressure on myself that I ended up basically doing nothing last week. So this week, I decided to just get something done.

I’ve wanted to make an interactive fiction game for a while, and since I couldn’t pick a game mechanic I decided to just pick up Twine and try to make something. My initial experience with Twine was very positive, I like how easy it is to approach for someone with no coding experience, but since I’m already familiar with JavaScript/HTML/CSS I found it really powerful. I once again began to overthink the game, wanting to make an RPG combat system where you’re flying an airship around. I instead had to pare it down again, cutting most of my ideas until I got to my final version.

I think a lot of my issues with game development comes down to fear of failure and feeling that I might not be good enough. I actually used those feelings as themes when writing the story for my game this week. The story I wrote ended up kind of personal even though it’s set in a sort of fantasy world. I don’t know if other people will enjoy it, but I actually found value in making this game for myself as it let me explore some of my own feelings. To be honest, I also think that the best creative works are made when people put a bit of themselves into it, so I’m trying to do that here. I would be lying if I said it isn’t scary to put a piece of myself out there.

What went well

• I wrote a story that let me explore some of my own feelings
• I learned how to make a basic project using Twine

What could have gone better

• I procrastinated a lot.
• I ended up missing my first deadline, so I missed a week of 1 Game a Week.
• I could have decided on my game scope earlier, giving myself a framework to work on.

What I learned

• Decision paralysis and procrastination is a project killer for me. When I have a clear task I have no problem getting the work done, but without a clear scope and vision I won’t get to work.
• I can’t rely on the deadline to motivate me to make good projects. Most of the time I’ll get “something” done, but it won’t be a good project and I’ll feel demotivated and will lose faith in my own ability to make games.
• I could try restricting my scope even more. Next project’s theme is “Earth”, but maybe I can also force myself to make a game in a specific genre. I also need to find a strategy to deal with my procrastination, otherwise I’ll just continue making projects that aren’t that good.

Summary

Overall I wouldn’t consider this project a failure. It gave me the opportunity to reflect on my own work habits and to really figure out what’s blocking me from making the kind of projects I’m proud of. I don’t think it’s just self-doubt, I honestly don’t have experience in every discipline required to make a game, but maybe I can use that as a way to decide on what games I want to make? Maybe each project I can come up with new techniques I want to try and use that to guide my game design instead of getting too theoretical with the project, where I start to overthink everything. I guess I’ll see how things turn out next week.

As always, if you want to try out the game, the link is right here:

Leaving Levaer

Short interactive fiction about big life choices

_{Available now to play on your browser}

View

I don’t have a GitHub for the project this time around, but I do have the proof copy in case you’re interested:

Alright, so I’m back after my break last week, and I’ve made another prototype! Thankfully I’m publishing the game on Friday, so I’ll be able to relax on the weekend and get into the habit of pacing myself. Unfortunately, this prototype turned out badly. I think whenever I decide to make a 3D game with physics, that should be my cue to pick literally any other idea. I don’t really enjoy playing around with the Unity physics engine, it’s hard to make a game look good in 3D (at least it is for me), and I didn’t put much thought into the game’s design. I basically recognised all these problems during Ludum Dare a few weeks ago, and now I’ve ran into them again. So no more 3D Physics-Based games, I’ll leave them for other game devs and studios to make.

The biggest problem with making this game is I wasn’t particularly sold on the game concept itself. Instead of approaching this week with the idea of “Let’s make this cool idea and see what happens!”, I kinda just picked an idea and went with the mindset of “I just need to get a game shipped by the end of the week.” – I’m essentially making shovelware and it’s preventing me from engaging in my own work. I need to be excited about the game prototype I’m making, and to do that I need to be learning something new and to be sold on the idea. The game I made was essentially “Missile Command except you’re defending a port and you’re instead planting mines in front of boats.” – Very not cool.

The game went through a bunch of different ideas throughout the whole week and didn’t have a specific vision. It started as a boat racing game, then I pivoted to a trading game, then I pivoted again to this terrible Missile Command esque game. The game isn’t really “about” anything, there’s no reason for this game to exist other than as a lesson in “How to make a bad game”. So in that sense, I at least got value out of making it.

What went well

• Finished on Friday!

What could have gone better

• Lost motivation on the project very quickly as I didn’t have a game idea I was excited about.
• Game wasn’t in a shippable state by the end of Wednesday. This is a crucial milestone that I recognised on my last game.
• Didn’t have a game design that I could make to a decent standard this week without crunching. (I didn’t crunch! Yay!)

What I learned

• I need to focus on games from an “experience first” approach instead of a “mechanics first” approach. What do I want the player to experience, and then how do I make that happen? All the player will experience will this game is boredom, frustration, and perhaps schadenfreude.
• I need to decide on my vision for the game early. Decision paralysis doomed this prototype, as I couldn’t figure out if I wanted to make a racing game or a trading game or a defense game.

Summary

This week’s prototype was another failure, but at least I’m learning from these failures. I already know what theme I want to base my game off of next week, and I’m going to try a new approach of experience first design instead of mechanics first design. I’m going to use the “Core” design exercise by Rami Ismail to try and validate my design early in the process, so I can cut anything that doesn’t contribute to the experience early.

As always, if you want to try out the game (It’s not worth it!), the link is right here:

1GAW – Week 11

Game Prototype. Defend your port against an enemy assault.

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

This week started off very promising, I had an idea I was excited about on Monday, and I felt like I could get the gameplay in by Wednesday evening. Polish and bugfixing could be done by Friday evening. I made a critical mistake however by working late on Wednesday, which caused me to be completely exhausted on Thursday. And on Friday, I realised I wouldn’t be able to finish my vision of the game by the end of the day, so my motivation was at rock bottom. Basically, this is another unfinished prototype, kind of like last week…

I wanted to make a top-down tilebased combat system, but with the twist that your character can mind-control enemies for the purposes of being able to use their weapons and abilities. Instead of a normal RPG where you have your own inventory, each enemy type was going to have their own specific melee and ranged attack. Mind-controlling an enemy would let you use these attacks, and interact with objects in special ways. For example, mind-controlling the scientist would let you interact with lab machinery, while mind-controlling the security guard would allow you to open security doors.

In retrospect, this was huge scope for a game to be made in 3-5 days, so I should have been more realistic about this at the time. I really should have picked one mechanic (the mind-control) and thought of a way to make an interesting game around JUST that concept. Instead, I built the mind-control mechanic in a way that depended on the combat system working. When I tried adding in turns and combat on Thursday, I actually felt pretty overwhelmed once I realised how much work it would be to integrate it with this mechanic. I didn’t think I’d be able to get everything done on time, and so I felt defeated. If I didn’t feel so defeated I could have been able to figure out a way to rework it, but I think I’m hitting a point with 1 Game a Week where I need to just take a break and rethink my process for making these games.

What went well

• I got the mind-control implemented in a simple way. I do still think this is a fun game idea, I just need a better prototype to confirm that.

What could have gone better

• Massive overscope
• Lost motivation after Wednesday and didn’t finish the prototype
• I didn’t follow my advice from last week, to get the gameplay loop working straight away early in the week

What I learned

• My energy on Thursday and Friday dips quite a lot compared to earlier in the week. I need to have the game shippable with programmer graphics by the end of Wednesday, otherwise I’ll start to stress and get overwhelmed on Thursday, which will just run into Friday.

Summary

I’m going to take next week off completely just to recharge and rethink my strategy. I’ve been disappointed with the last few games and it feels like I’ve been on a bit of a failure streak. In a way that’s fine, since these as are all prototypes. I would like to actually get a few wins though.

As always, if you want to try out the game (It’s not worth it!), the link is right here:

1GAW – Week 10

Unfinished roguelike prototype

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

I’m going to make this a short post-mortem, since there isn’t really a lot I have to say about the game itself. I also want to immediately get started on my next game, so let’s get right into it.

I started the week wanting to make a platformer again. I haven’t tried to make a platformer since Week 1, and all I really managed to get done was a basic collision system and floaty controls. I wanted to do better this time around, with a player character that feels weighty and a simpler implementation.

I struggled with the collision code again for a few days, but I managed to get a simple tilemap collision algorithm implemented that worked for my purposes. I then spent a day tweaking the player character controller parameters, adding in acceleration and deceleration values, jump gravity and coyote time. At this point in the project, it was possible to do very basic platforming. However, I wasn’t quite sure what I wanted to make now that I had a simple platformer system implemented. This was on Thursday.

The next 3 days was a blur of trying out random ideas and just trying to get something working. I thought it would be cool to have to fight a dragon enemy, something I’ve wanted to implement in a game for a few years (I even made a prototype few years ago). I added the enemy on a fixed track, and made it shoot projectiles at the player if the player is in line of sight. The player can then hit the projectiles back at the dragon to hurt it. Once the dragon is dead, the path to the dragon’s lair opens up and the player wins the game. Fairly simple premise.

Honestly, I ran out of time and energy on Sunday, and the second to second gameplay wasn’t fun. So early in the day, I decided to just stop working on this project. I think that was the right decision, there was very little to gain to push myself much harder.

What went well

• I was able to use knowledge I’d learned in previous prototypes to make this game. Specifically Week 1’s collision system was simplified and updated for this game. Week 7’s bezier train system was also adapted for the dragon path.
• I learned how to implement a lot of smaller features, such as having the Camera pan to the room that the player is in. Line of sight raycasting on a tilemap. A wipe effect for reloading the game scene. Hurtboxes and Hitboxes. Very common features in games that will let me prototype faster in the future!
• The player character is fun to control. Even though mechanically it’s the most basic platformer controls possible, I think adding the squash and stretch, plus tweaking the physics values showed me how important ‘feel’ is to make a game enjoyable.

What could have gone better

• The game structure ended up being a total mess. The combat wasn’t fun, and I didn’t have the time to redo it.
• I made a mistake with the dragon implementation. Every segment is on the bezier track, and follows a set distance behind the next segment. It would have been better to have a “target” on the bezier curve, and have the dragon physically follow the target, with each segment following the next segment. This would have allowed me to dynamically remove and add segments like a linked list, so that the dragon’s total length gets smaller the more the segments are destroyed by the player.
• I spent too much time on polishing certain features instead of getting the game to a very simple beatable state, and then polishing from there. For example, I spent a few hours polishing the death animation when really I should have been getting the core gameplay to a workable state.

What I learned

• Getting the core gameplay working early is essential. It’s something I’ve messed up on with every game I’ve made so far. I think I spend too much time early in the week trying to figure out what I’m going to build, then I make a quick decision mid-week and rush to get something done over the weekend. It’s an unsustainable way of making these prototypes and I’m going to now force myself to have the game beatable by Wednesday, so I can polish and tweak it over Thursday and Friday. No more weekends.
• I find it very difficult to implement something when I don’t have a clear design or goal in my head. When I knew I wanted to make the death animation, it was very easy for me to focus and get that working. I had a lot of fun with it too. But if I’m not entirely sure what the design is, I tend to procrastinate and get stressed. I think I need to spend less time doing up-front design on the larger systems, and just let myself build things as I code the prototype. The code will end up a mess, but that’s ok, since the code base for these games will only be worked on for a week anyway.

Summary

The game I made this week was just plain bad and unfinished. But I learned a lot of lessons from it. I’m going to change my approach to making games from now on, with a focus on getting the core gameplay loop working early in the week, and polish, tweaking and art on Thursday and Friday.

It wasn’t until I watched Mark Brown’s video on his own game development journey that I realised I haven’t been focused on making sure the game’s design is actually sound before trying to polish it. For my next game, that’s exactly what I’m going to do. I hope it turns out better than this one.

As always, if you want to try out the game (I’m sorry in advance), the link is right here:

1GAW – Week 9

Unfinished platformer boss prototype

_{Available now to play on your browser}

View

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!

After my satisfaction with last week’s game, I was feeling ambitious. I had a whole week to work on a game, and I was well rested from the weekend. Sitting down on Sunday, I made a rough outline of the game I wanted to make, and the tasks I’d need to do each day to make it. I even aimed to have the game complete on Thursday, giving myself Friday as an “overflow” day for any outstanding tasks. Despite all this, the game I made this week was a disappointment.

My original vision of the game had the player taking the role of a train driver delivering assorted goods to different stations in a small game world. The player would need to navigate the world by using landmarks that they would come across, with directions from the people at each train station, and with a basic paper map. I also wanted to have some humor and character interactions in the game, where the player would talk to the people loading and unloading the train at each station. The game structure would have been a bit like Cloudpunk, where the main enjoyment in the game comes from the dialogue and becoming familiar with traversing the world.

While this is definitely a large scope for 1 Game a Week, I thought it would be manageable. I’ve written dialogue before that people seemed to like in one of my first games for Ludum Dare: “This is NOT a Scam!“. Implementing the story would have been very basic. There wasn’t going to be branching paths or anything too complicated. The hard part of all this was going to be implementing the train movement mechanics. For a long time, I’ve wanted to make a “train game”, primarily because the implementation seemed like a fun programming challenge, and it’s quite different from standard grid-based or Rigidbody movement.

So with my justification for the scope out of the way, I decided to start the implementation by using Bezier Curves to define the train tracks. I’ll happily admit that Maths isn’t my strong suit, so this video by Freya Holmér helped me out a great deal with understanding how they work. I was surprised to find out that the logic behind them is quite simple, especially when using De Casteljau’s Algorithm.

After writing a very basic Bezier Curve implementation and a very crude editor script, I was able to setup a chain of train tracks. Things were running smoothly until I had to start implementing track junctions and tracks that cause the train to either reverse or run the opposite direction on the track.

So in my implementation, I’m able to get the t-value of each track segment, which is the interpolated distance between the beginning and end of the underlying bezier curve. A t-value of 0 will get the Vector2 position at the beginning of the curve, and a t-value of 1 will get the Vector2 position at the end of the curve. You can iterate over the curve, getting a Vector2 from each t-value and then using those positions to draw the curve, which is what I do here. So far, I think everything is simple enough..

If I’m writing a game where I need to move the player along the ground, I can add a value to the x position to move right, and subtract from x to move left. Unlike a simple 2D game where the x value can go off to infinity, each track segment has its t-values clamped between 0 and 1. I need to check for when I go above 1 or below 0 on the t-value, store the remainder, and then set my “current track segment” to either the next or previous segment. Immediately the movement logic is more complicated, and this doesn’t account for cases where you loop around the track and end up moving forward in the opposite direction, or even reversing the train.

I don’t want to get into the entire implementation in this post-mortem, but I just wanted to demonstrate my point that the implementation wasn’t as simple as I first thought it would be. This doesn’t even take into account trying to add junctions, which also needs to take into account the “direction” of the track.

I struggled with this for a few days, and if I’m totally honest my motivation really dropped off on Wednesday/Thursday, when I was hoping to have movement implemented and I could start working on the world design of the game. It wasn’t until the weekend when I was able to get movement working, and that didn’t account for the train’s momentum, or taking turns too quickly, or any of the “fun” movement mechanics. I basically had a way to move around the track and change junctions. Although I did also add in some code to create the train track graphics, which was quite enjoyable.

The junctions took a while to finish too. This was more of a game design issue, I didn’t know the best way to show the player the current junction setting and which junction would be changed when they hit the A Button / Space Bar. I originally wanted to have the track itself change, but that would have been tricky to implement, and I don’t think it would have been easy for the player to make a judgement on the junction setting when the train is moving at speed. The best thing I could come up with was a literal sign that shows the junction setting.

At this point I had a basic prototype built and it was almost the end of the week. I knew I wouldn’t have the time or energy to create my original vision. The idea of salvaging the project and turning it into a slot car racing game crossed my mind, but at that point I wanted to just abandon this game. I put it up on Sunday, and now here I am writing the post-mortem on Monday.

What went well

• Not a lot, I essentially made a small prototype, similar to my first week. At least I finished?

What could have gone better

• I could have cut scope earlier which would have made me less likely to procrastinate.
• My implementations were quite buggy.

What I learned

• I learned a lot about bezier curves and their uses. I think this will let me implement a lot of different and interesting game mechanics in the future.
• I have some ideas on how to improve my implementation, which will be useful the next time I have to write a track system.

Summary

In the end, I don’t think this prototype ended up in a good state. In saying that, it was a good learning experience. I still like the original idea I had for the game, and this is something I’d like to pick up again for 1 Game a Month. Knowing some of the pitfalls I can run into with this game mechanic, I think a 1 Game a Month project would have a better chance of success now that I know what issues to look out for.

As always, if you want to try out the game, the link is right here:

1 Game a Week – Week 7

Prototype for a train game

_{Available now to play on your browser}

Play Now

If you wanna play around with the code, I also have a link to the GitHub repo if you click here!