Game jam is done. I had a blast.
I managed to improve the actor-versus-actor collisions slightly, as well as make a start on the sound manager. I was able to play a single sound at a time – the mixer was not yet working properly. Seeing as I was frantically writing that code with 25 minutes to go until the jam, I’m pretty happy with even that result.
We received two runners up/honorable mentions, although I can’t recall what they were right now. I’ll edit them in when Jamalaide update their blog.
I sadly did not get to meet any of the major sponsors – I was coding frantically while they were coming around to our floor, and when I’d finished, I’d ducked out for a bathroom break. When I came back, Dr Mike was sitting down to try the game, but there was a crowd of fans all around him and I couldn’t get close to explain that it was a C++ engine, not Unity (like all the other games). I couldn’t get through without being rude about it. Thankfully, the rest of the team where there so it wasn’t a total blind game, but I was kicking myself for drinking so much water earlier. Oh well.
In terms of actual learning, it was my first experience working with another person with the engine. The artists were trained for making excellent models at AIE, the kind that would look great in a AAA game. Infinite State Automaton is not a AAA game, or even a AAA engine, so when I first tried to import them, the engine crashed.
After some hair pulling, I found out that the math library I was using (glm) crashes if you try to normalize a vector with a length of zero. Must be a divide by zero bug in there somewhere. I was able to make a guard for it.
Next, when I was able to load the models, the game chugged big time, with around one frame per second. Physics was checking an actor against every face of the model; and the models had thousands upon thousands of vertexes.
I was able to work around this by only resolving checks against a handful of faces instead of all of them. The ‘real’ way to do this would be to build an invisible hit box inside of the model that the actor would check against. I didn’t have time to implement this.
The game still chugged when too many models were present. I wrote some quick and dirty code to only render scenes that were within a certain distance of the camera, and tried to hide this by having a skybox to cover the transition. I didn’t get it quite right and you can still see scenes erratically appearing at the horizon.
Finally, with an hour to go, we basically had a working game, but no assets aside from roads in it. I managed to get the signs in, but for some reason the game was once again back to 1 frame per second with more than one actor in it. I eventually turned them in to props, which fixed the problem, but meant physics between the car and the signs wouldn’t work anymore. Then lastly, we hammered in ten maps to play the game on, and then it was time up.
Overall the experience was positive. The engine went pretty much as I expected. I would liked to have done more with it, but I spent most of my time trying to import the models – maybe 3/4 of my total coding time was spent debugging and repairing models – with only around 1/4 of my time actually spent building game code.
This was a good example of ‘knock up a game prototype, learn from it, chuck it in the bin and move forwards’. Many other people in the group want to continue working on the game – it seems that in AIE there is some kind of ‘group project’ event and they would like this to be their group project. And it’s true, this game could be given a lot more polish to make it better. A lot. I may yet do so; in particular I want to work out what went wrong with the road models and the car model.
In regards to my personal journey, I’m mainly interested in what next to do with the engine.
I’ll have to get the sound mixer working so that I can import music and sounds. After that, I want to enable the different camera models I have in mind. And then I’ll look at importing textures on my Blender models.
I’ll also incorporate the improvements I learned from making Backseat Driver. Then I suppose it’s time for the next game jam…
Thursday afternoon. I spent the first part of the week recovering from game jam and getting on with the things that had fallen behind while I was focused elsewhere. The main thing was applying for a whole bunch of jobs. Many of them were quality software engineer jobs so I’m confident I should be able to find something to keep me in Adelaide.
Today I got back to programming. I spent some time playing in Unity – I’ve received some good feedback from an industry member that this is well worth learning, so I’m going to try to use this downtime between jobs to upskill.
I also looked at the problems Backseat Driver had. As I suspected, the rush job in the last thirty minutes prevented us from looking closer at the problems. My wife and I were able to resolve them with a few rotated models over a cup of coffee; I’ll owe Gee an apology since I was blaming him for broken normals. There were some issues with the models but this one was not his fault! We then tidied up some minor things such as sign placement, and some incorrect tiles, and then I shelved it for now.
Then I went back to looking at sound. SDL2_Mixer isn’t working properly; it can only play one channel at a time except for when I’m running in execution mode. I’m also getting repeated errors about missing something called Timidity. I then went and looking for Timidity on the internet and turns out it is ANCIENT. It almost predates the Internet. Needless to say, I couldn’t get a good resolution on this; so then I tried OpenAL (Open Audio Library). I was able to set it up but couldn’t find how to actually open a file, so I canned it and am now trying to get FMOD working.
FMOD is a AAA sound engine. I had avoided it originally because it’s, well, AAA. I couldn’t afford the license fee. However, today when I visited the site it is apparently free for Indie Developers, which is me! If I ever earn $100,000 with my software, I’ll have to buy a license. If I ever earn $100,000, though, I’ll be quite happy to pay a license fee.
So for now I’m working on sound. Please wait warmly~
Friday 1 am. One advantage of being unemployed is that I can code allllllll night. That’s a bad habit to get into, though, so I’ll call it quits here.
I’ve managed to get Fmod working with mixed sounds. That’s essentially what I was aiming for in this pass. I’ll see what I can do with it tomorrow morning.
Today was cut pretty short due to various adventures around town, but I still managed to get music going. I was delightfully surprised to find that the same command to open a .wav also opened a .mp3. Ah, the power of a triple A library. Perhaps I should look into that physics engine after all.
I then sat down and blew through a few Unity tutorials. This weekend is quite busy so I hope I can make a start on Unity properly next week.
The next event I’m aiming for is the ARGGGH, a meet up of Indie game developers in September. It’s a monthly event and a great chance to find people who are looking for teams or individuals, or just to see what kinds of things other people are up to. I’d like to have an Idiot Robot prototype going by then, it’s about three weeks away, so why not.
I spent some time working on the Unity tutorials and finished the first third of tutorial 1.
I’ve also been thinking about my game physics.
At the moment, I’ve been treating every room as a scene, and movable objects within the scene as either an actor, or a prop. An actor is an object that responds to physics, a prop does not. This was a hackjob solution to a problem encountered at the Game Jam; that when I have multiple actors in a very large scene, the game bogs down.
What’s required will be an overhaul of how I handle this.
Probably I’ll have some more ‘containers’. The more I can break a level down into smaller chunks that can be kept separate from each other, the less checks the game needs to make.
So probably something like:
(Highest level container)
Level – All the required game assets for one level of the game, including…
Zone – A zone is an area of related space. EG in a residential area, a street block might be one zone. Objects in one zone would not normally interact with objects in another zone – allowing me to put actors in an ‘inactive’ zone to sleep and skip checks made against them.
Sector – A sector is a subsection of a zone. EG in a residential area, a house might be a sector. Objects in one sector would not normally interact with objects in another sector, but they may be impacted by things happening in nearby sectors (e.g. a player might hear the movement of a vehicle in a nearby sector).
Room – A room is a subsection of a zone where all actors may interact with each other. Rooms will therefore be the most intense in terms of processing, however, I should be able to skip over rooms that don’t have any actors in them, or no ‘active’ actors.
I can predict issues when actors need to transition between sectors and zones so this may not be the best approach. I’ll need to do some more research and planning before proceeding with this implementation.
In the mean time, with sound out of the way, the next step is to complete my camera modes. At the game jam, I was able to get first person shooter view working, but there was a problem when I tried to wrap a car model around the camera. I need to work out what went wrong and fix it.
I’ll also take the time to implement the additional camera modes so I have ‘everything covered’. So I want:
First person view (basically done).
Side scroller view (think a standard platform game, like the original Mario)
Top down view (Any game where you’re looking down on the top of the player, such as 1942 or Pitstop)
Isometric 3D view (The modern real-time-strategy or MOBA type view)
Chase camera (Often known as ‘third person view’, popular in 3D puzzle action games like the Zelda series)
There are of course subsets of these camera views that different games make use of, but for now I’m only interested in the general camera view, and I will further specialise the camera when I require that view. EG a flight simulator is technically a first person view, but these days people expect to be able to use a mouse to look around in a different direction than where the vehicle is headed. So that is an example of a specialisation of the first person view.