Allright, so my work got a bit delayed due to illness but the level generator is now up and running complete with height differences and special track pieces.
I designed a system where whoever designs the track parts can mark where the track piece connects to the rest of the track and which other tiles it occupies. The system then finds valid locations for all special pieces and randomly assigns pieces that fits into the track.
I made a custom user interface to make it fairly easy for a level designer to mark the tiles which the track piece occupies.
The level generator now also supports several options to customize which features the customized level will have, like how straight the track should strive to be or over how large an area the level should be generated which affects the average track length.
And finally I uploaded a small video showing of the level generator in action and a short run of a level in-game.
As my teammate Peter posted earlier “killing your darlings” is sometimes a necessary evil that needs to be done to progress.
For most of the week I struggled with my procedural level generator implementing height differences in the track. I figured I’d just extend my grid to a third dimension and only allow the pathfinding to go diagonally down or up in its current travel direction. I obviously didn’t think this through enough as it lead to several problems with the pathfinding generating impossible paths for the track and I eventually found myself writing code to counteract every possible weird behaviour that could occur. This was far from optimal and I figured that simple is best so I killed my darlings and tackled the problem with a different approach.
I figured that there was actually no need for a third dimension in my grid. The third dimension only made things more complicated than they needed to be and didn’t really add anything to my system. Instead I decided to generate the track as before on a two dimensional grid and afterwards generate height differences along the path. I did this by randomly adding a slope or a hill on valid points along the track if a suitable position for a counter-slope/hill could be found further along the track and then raising or lowering every cell between these positions. This approach was both easier to implement and was faster codewise as it didn’t require as much special cases as the previous attempt.
So… as it stands now the level generator now supports both height differences and crossing over itself both on different levels and on the same. Unfortunally I am currently in the process of making new trackpieces that will both be more fun and fit better in ImpactO so I won’t be showing the new features until next update where I also hope to have support for special track pieces implemented.
All my time last week was soaked up on implementing the race mode. I had planned on getting some more work done on my Procedural Level Generator but there was way too much other stuff that needed my attention so I had to reschedule it for this week instead.
I integrated the level generator into the main ImpactO project basically without any problems. Network instantiating the track pieces worked like a charm and the generated levels syncs up just fine. As it works now, whoever is hosting the game has the ability to generate levels and the other clients can see the generated levels as they are generated. The host chooses which level to start the race on.
Implementing the race mode went fine for the most part… until I had to decide how to design the checkpoints along the track that defines if a player is going the wrong way and keeping track of the current lap the player is on and the latest checkpoint passed (for respawning purposes). I ended up with a design that used triggers with which I could decide which way a player entered and exited a checkpoint. If a player enters and exits a checkpoint along the track it counts as passed. If the checkpoint is passed in the wrong direction the system keeps track of how many checkpoints the player has passed in the wrong direction and this count only decreases when the player goes in the right direction again. This means that a player can’t progress through checkpoints by going backwards. If the players doesn’t exit a checkpoint trigger the same way they entered it counts neither as passing or backing through a checkpoint. Early on most of the problems arose because it wasn’t safe to assume that the players that entered the checkpoint trigger also exited the same way they entered which would mess up the system completely.
Anyhow, we did a small playtest yesterday on the racemode and it seemed to work fine for the moment which means I can focus on generating levels that are more fun to play
I have been busy getting a working prototype running for proof of concept which will be reviewed this coming Monday. As it’s a proof of concept it currently only supports straights and 90 degree curves but I’m satisfied with the result so far.
Here’s a short video showing what is possible so far.
The red cells represents the cells which the pathfinding system has to pathfind through while generating the circuit. Since I’m a programmer the tiles looks like crap but they only serve as placeholders for my proof of concept.
Next is making more interesting paths and tiles than just straights and curves. I hope to have support for paths crossing over themselves, height difference in the path and pattern recognition used for more advanced track pieces.
I’ve been busy this first half of the week implementing the new Hold the Flag gamemode. The first iteration of the mode is done and it works something like this:
Grabbing and holding the flag will grant your team 1 point every 5 seconds.
The flag has a pool of 15 points which will deplete as you gain points.
A fully depleted flag will be dropped and it will respawn on its standard spawn.
Bringing the flag to the capture zone and keeping it there for 5 seconds will net you and your team all remaining points in its pool plus 5 extra points.
Destroying or knocking out a player which is holding the flag will instead give you the flag.
Killing other players will still give one point.
We’ll have a playtest this Friday to see how it all works out and if anything needs changing. Nothing is set in stone so far and in the end it probably won’t even be a flag the teams are fighting over.
So, for the second half of this week I’ve been working on my procedural level generation system. It is based on an arbitrary grid on which it randomizes a specified number of cells on which the track will pass through. The generator uses a modified A* pathfinding algorithm to find the path between each waypoint cell (marked in red).
It is rather basic at the moment, capable of generating a simple circuit and registering information on each cell that is to be used. I am satisfied with the current result so far and it’s definitely a step in the right direction but there is still a long way to go.
I’m the new guy in the ImpactO team but that hasn’t stopped me from diving straight into the code and generally running around supporting the others wherever I’ve been needed. Spent first half of this week mostly on behind the scenes stuff like player, score, and gamemode management so nothing really exciting visually. I did however whip up a fast scoreboard just to display that everything else worked as intended even over the network.
So far things have been progressing fast and the game is still very early in development but is basically playable after only two days of active coding.
The rest of the week my main focus will be on my own specialization project which is to procedurally generate levels for ImpactOs new racing mode.