You are here

Making progress by doing nothing

Body: 

I recently took a (unplanned) hiatus from game development. Partly due to my actual, real-world person job and responsibilities eating up a lot of my time, but also due to illness. Over the last couple of days I sat down and had a proper look at the state of the game, and it was really weird that I noticed all of these little things that I hadn't seen before -- glitches, gameplay problems, stuff that needed tightening up etc. I came to the conclusion that you can get quite blinded to these things if you sit and work on something constantly, as I had been doing previous to this. Right now my real work is taking up a lot of my time, so development is pretty much resigned to some evenings and weekends -- back to part-time, really, but I'm hoping that this can actually be beneficial for me, since this might give me time to reflect on stuff a bit more. Having this time off has really given me a new perspective on a lot of stuff to do with the game, and I feel like I can see it more as a whole now rather than a collection of systems I'm obsessively working on. Progress through doing nothing!

One of the big hurdles I've finally gotten over is to implement some proper pathfinding. Previously I was using a component, force-based approach, but the main problem with this is that it doesn't easily allow enemies to path around obstacles (platforms etc.). Something more involved -- either a potential-field based approach or explicit pathfinding -- has been required for quite a while now. My approach to the waves of enemies in the game sort of follows a tier system -- the very bottom tier is populated by a type of enemy I nicknamed the BOD (I'll come up with a backronym for this at some point), that fills the role of the "trash mob". They sort of typically look like this:


You can see them in the GFYs on the Tiny Robot Justice Squad website. They're all slightly different, but the story is more or less always the same -- they'll attack in swarms and damage you if they get close. Each of them are very slightly different in terms of speed, damage, visual effects etc. but they're intended as just cannon fodder. Blowing them up is intended to be good fun. Previously I was using a component based system to just float them towards the player, but one of the things I wanted was for them to be unable to move through platforms, meaning the player could use the environment to their advantage to slow down the swarm. Using the force-based system I was using previously meant that in situations where the BODs were behind platforms or obstacles, they would continue trying to move towards the direction of the player, even if it meant they kept bumping into the object. Ideally I wanted them to be able to move around the obstacle to continue the chase, which required something more complex than just pushing them in the direction of the player as-the-crow-flies.

In the end I've settled on an implementation of the A* algorithm, with a couple of other additions to get the sort of behaviour out that I wanted. Firstly, since there will be quite a few BODs on screen at once, I wanted to try and minimise the amount of path recalculations that they do. Through experimentation I found out that I got fairly smooth behaviour by only calculating a path to the player once every ~20 frames or so. But in addition to this, I also added a clause to ensure that BODs did not recalculate their path if they hadn't moved significantly since their last pathing request. Essentially, since BODs attack in swarms, and can collide with each other, it's possible that they can all wind up pushing against each other in a big clump. A force-based approach pushes them towards their next path node, but since their collision shapes are circular, it means they can wind up appearing like a big, churning mass, since they can slide around each other, which is something I couldn't do with just a rectangular shape. This is my desired behaviour, but it's pointless for them to continue generating paths to the player if they are in this situation, since they do not pathfind around each other, only environmental obstacles. Though it may be interesting if they did pathfind around each other in order to elicit a type of enemy that goes for multiple vectors of attack, I think that might be a bit too complicated a behaviour for an enemy I intend to be cannon fodder.

So I'm quite happy with these updates -- the combination of the pathfinding and the right kind of collision shape really gives me the kind of behaviour I wanted all along.

To break this boring wall of text up here's a work-in-progress preview of a level background I've been working on.




One big problem I'm having right now though is that I need to stop coming up with excuses not to do any real-world playtesting. The first level demo has been essentially finished for a while now -- I even have sound effects and music for it!-- but I suspect it's my own fear of people's reaction and responses that's stopping me, but I also know that this is the only way to make any progress at all from here on in. I know you can work on something creative for an indefinite amount of time, and at some point you just have to stop and give it out, but realising that and actually doing it are two different things entirely. Only two people have seen the game in action so far, and their responses were positive. The other day someone in my office saw me fiddling with pathfinding and playing the first level -- he made the comment that "I guess the goal is to destroy those things then?" pointing at the signal pods dropping into the level. This made me feel pretty good, since the pod mechanic is pretty core to the game, and he figured it out straight away. So hopefully that means I've succeeded in making it readable.

My design document is roughly ~25 pages long now, mostly with notes I've made along the way. One of my goals for this week is to take this and organise it into categorised notes on Trello to hopefully lay everything out in front of me and make sense of everything that remains to be done. I think slotting things into categories like "art", "design" and "programming" will be really helpful. I think polishing up that first level demo really needs to be a priority though, since as I said, I know that playtesting and user feedback is the only way I'm going to be able to progress from here, both in terms of game design, but also in terms of the technical aspects.