Home Game-A-Week 4: My very first isometric tower defense game
Post
Cancel

Game-A-Week 4: My very first isometric tower defense game

Background

From the period of October 30th 2023 to November 5th 2023, I worked on my first isometric tower defense game as a practice exercise. It can be played here This project, much like last week’s game, is a learning exercise. I didn’t spend too much time on the design or aesthetic. According to my tracked time, I had spent only 10 hours of focused work spread out throughout the week. It makes sense, as this is not the only project and commitment I work on during the week.

Maybe one of these weekly game jam projects I should just dedicate an entire day from morning to evening for a burst of 8 hours focused progress at the start of the week. I wonder how that would go.

What Went Well?

Able to apply Week 2’s Isometric Logic in this project

In a previous game to learn the basics of isometric projection with 2D sprites, I had created a simple golf game. In this project, my learning goal was to apply isometric logic again in a different genre, which is tower defense.

The fact I was able to reuse the same functions and logic that I had written in the past and expand on them is good. It shows that the progression of these Game A Week projects is really building up to something greater over time.

This shows even if currently the early games are weak on their own, their value towards my learning long-term is still measurable and productive.

Was able to reuse the physics collision detection and object pooling from Week 1 by decoupling rendering from physics

In another previous game, I had gotten some experience using Phaser’s built in physics object pool and collision detection overlap functions. While that game was from a top-down perspective, I was able to recognize that isometric space still followed an x-y coordinate axis.

By noticing this, I was able to separate the coordinate spaces of physics and rendering in a way that allowed me to use the existing Phaser physics coordinates, as I only had to consider the conversion from isometric space to rendering space when drawing.

Made use of runtime editing inspector panels using TweakPane

TweakPane is a successor to dat.GUI. It serve a good role for what I observed in the previous weeks, which is that I needed ways to modify variable and data at runtime to better design, balance and test the game. I was able to integrate it successfully into this project to tweak variables such as the enemy spawn speed, the reward per enemy kill and so on.

I did finish the concept

It’s a game where enemies spawn in a pattern with some randomization. The player can build towers with money at specific parts of a grid to prevent the enemies from reaching some destination. This gameplay loop repeats. I didn’t set out to make multiple different towers or wave mechanics for my first attempt.

As such, it is safe to say that I had succeeded in creating my very first, beginner attempt at the tower defense gameplay loop at the basic level. This was my main goal I set out to accomplish, and in the end I finished that.

What Could Have Been Better?

Creative Burnout and Stress Management from making games meant for my own learning, that people don’t really want to play

This point is a bit harder to articulate. These game a week projects have been very focused on learning new concepts and tackling genres that I have yet to touch, and these concepts have a heavier emphasis on programming challenges.

While this approach of focusing heavily on learning objectives on the deadline provided a productive and efficient outlet for learning, they have a draining impact on creativity and expression. By the 8 hour mark of learning, progress and writing a ton of setup code (based off tracked time intervals), I found I had become too emotionally exhausted within the same week to experiment with the project on more game design and artistic aspects.

It doesn’t help that learning projects like this don’t tend to attract attention or support, because the game itself isn’t really fun to look at or to play. With these genres, I am not yet at the skill level where these projects reach the state of functionality that allows an increased focus on design and ‘making it fun’ early enough that I haven’t already felt drained and have the time to ‘make it fun.’

I think this is a problem that would resolve itself automatically over time, however, as I gain more experience finishing things quickly and having past projects in similar genres, having solved similar problems. This is a time now for persistence, discipline and focusing on long term growth.

I know a year from now, my technical skill level would be able to make a tower defense game of this quality in less than three hours, which would free up the rest of the deadline to focus on making it fun and appealing to play. I just have to be patient and persistent.

Realistic expectations of improvised game jam quality codebases

Another thing I needed to have realized was that… game jam code is going to be messy and brittle. That is in the nature of these prototypes made with quick iteration in mind. Sometimes this means that adding a new feature involves a lot of jank hardcoding or even passing in global variables or references.

This is fine for a short term project with a short deadline and I need to accept that. A lot of the code would not be very reusable, and have to be rewritten from scratch when revisiting concepts, but that is okay. It does not mean that the prototyping code was ‘useless’ as it still shows a valuable example of how the underlying logic can work.

I am forced into coding way too much, and can’t practice design or art skills, when I pick projects in genres I have less experience in

This makes sense as I have been working with frameworks the past month, in gameplay genres that I have less experience in, with the express goals of learning how to program games for those genres.

Of course I would be spending the bulk of my development time programming, this is only natural, but I do feel that by coding so much I have not a lot of chances to practice other important game development technical skills like design, marketing and art.

I have be self aware of this consequence when scoping and choosing projects like this, that the main skills that improve relate to project management and programming.

What have we learned that we can apply moving forward?

I need to get more comfortable with CSS

Tweakpane uses CSS for styling, including the position and size of the panels. This is a bit different from what I am used to in something like Dear Imgui, which allows the user to drag the panel and resize it freely ‘out of the box’.

Next week’s project idea should be less code heavy

I had originally thought about making a Tactics game for next week as I really wanted to learn how to code gameplay systems for that genre. After consideration of the previous points, however, it would make sense to have that genre attempt be postponed for a different week, to prevent the stress buildup of focusing so much on coding learning games that nobody would play.

I will instead focus on a genre that I know I would not be stuck in the coding for the majority of it, with a different goal of making something that people would be interested in playing due to the aesthetic or hook. I think that can be a good palette cleanser.

This post is licensed under CC BY 4.0 by the author.

Internship Project for Nanyang Technological University

Weekly 10: Finishing a month's work of weekly games and some other updates.

Comments powered by Disqus.