EEI Build Review 1 – Running (Like Garbage) on Everyone’s Machine

The upcoming game doesn’t actually have a name yet. For now I’m going with Escape from Epstein Island, or EEI. That is obviously subject to change. 

What’s not subject to change is the weekly build releases, where I zip up a build of the game and hand it out to the telegram group for everyone to play. I would encourage everyone reading this to join said group. We have thirteen members, as of time of writing, although only two of them actually downloaded the build and left commentary. 

This week I just wanted to make sure that the game worked on at least one other person’s machine. While both of the playtesters are on Windows, they reported that the program was functioning for them. Which is good, because just one hour before the release, the build had stopped working even on my computer. The project worked in the editor, and previous builds had run just fine, but this one was broken. 

Like this, but worse.

Before I get into what needed to be done to fix this, I should explain what I mean by “running in the editor.” Below we see a screencap of the Unity editor. There are two monitors side by side. The left monitor and half of the right monitor are showing the Unity editor, while the right half of the right monitor is showing visual studio code, a program editor. 

When I first started using Unity, a simple project compiled in less than half a second. Nowadays that has ballooned up to a few seconds, for no particular reason. The current project has compile times of over five seconds, and takes about fifteen seconds to build, despite having very few assets, such as small 2D images, some music and sound effect files, and the scenes themselves which are trivial.

However, no one re-builds their project every time they make some change to the code. If you were making your own engine you would have to do this, but Unity has a nice feature where they let you run the game inside of the editor, meaning that you only need to wait for the scripts to recompile and you can theoretically adjust a few values on the fly, pause the game, etcetera. In the long run this isn’t as useful as you might think, something I’ll cover in the upcoming Unity (((fiasco))) piece, but in the short run it’s definitely a nice time saver.

Before the first release I decided to implement a feature where the game gave you a high score. Nothing particularly complicated, and the current version just multiplies the time you stay alive for by one thousand. It’s possible that the game ends up as an arcade style 2D shooter with an announcer, but that’s not why I implemented this feature. I just wanted a quick little feature to add to an early prototype where I could see roughly how long the playtesters survived.

The game gives you a score each time that you play, displays it when you die, and saves it to a high scores file. If you get a new high score, the game shows a little blurb about that. 

Since each score is just one four byte integer, we can save them all together in a tiny binary file. When you start the game up we load this file, sort the scores, and then display your ten highest scores in the top left of the main menu. It’s also smart enough to create this file if it’s missing. 

… and so on.

Easy, simple, and works just fine when running the game in the Unity Editor. What could possibly go wrong?

An hour before the build was due I created it and played it. I immediately noticed something odd on the main menu.

No, it wasn’t that it looked like garbage, that is to be expected from a product that has no artists working on it yet. The problem was that, even if the user has no scores, the system is supposed to write: “no score yet”.

What it should look like.

Worse, when I clicked the Play button I was greeted with a frozen game that oddly still had music playing in the background. I was also able to quit back to the menu by hitting a keyboard shortcut I had programmed in there, but I couldn’t actually play the game.

Nothing moves and the controls don’t work.

Even odder, the intro blurb screen that serves as a hack tutorial was missing. It’s supposed to look like what you see below. Also, there is a small amount of level building that goes on, mainly for pathfinding, that is represented on the minimap. The work has completed in the below screenshot, taken from a functioning build, but not the screenshot above, from the faulty build.

What it’s supposed to look like.

It’s one thing for a new feature to break, but in this case it was taking the rest of the game down with it. Luckily, it was pretty obvious that the culprit had something to do with the recently implemented scoring system, and the file loading specifically. To help track down this bug, I created a little bit of text that plays on the screen and shows the path the program is using to load files.

file path used when running in the editor.

In the editor, the build path is what we expect. In the build, we get… nothing. 

“Debugging:” is the default text.

I ended up spending a good forty minutes debugging this, but to make a very long story short, there were two major issues. First, Unity uses different code for getting to the root folder depending on whether you are running from the editor, or the build. After trying a few different ways of getting to the root folder, I figured out that I was supposed to use Application.streamingAssetsPath, instead of Application.dataPath. The latter doesn’t exist in the build. This is extremely annoying, but there may be good reasons for it to be this way.

To run in the build, and see if various paths are functional.

The second, related problem is a quirk of Unity’s build process. Your project can and will have many more files and folders than the build that you send out to the general public. Unity doesn’t necessarily include each of these folders, and if you reference them later on you’ll get some weird behaviour in your program. In and of itself, this would be fine. 

I created a folder called StreamingAssets, which is a special folder name that Unity knows to include into your build. In that folder I created a subfolder called “Scores,” and put HighScore.bin in there. 

Here’s the aggravating part. The new version was working in the build, but it meant that everyone started off with my high scores. I wanted everyone to start off fresh, so I simply deleted the high scores file, and built the project again. 

I had written and tested code that built this file if it didn’t exist, and, once again, it worked in the editor version. Then I played the build, and we were back to square one. 

Turns out Unity decided that, since the folder was now empty,  it didn’t need to include it in the project.

When the program checked to see if there was a high score file in the right folder, it got an error because the folder didn’t exist, hence the broken behaviour. If you want to have this folder exist, you have to create some stupid throwaway file like “dontDeleteThisFolder.txt” so that Unity actually creates the folder that your build needs to function properly.

Before tracking down this bug I probably built the game over a dozen times. As if all the above isn’t bad enough, one time I panicked, getting this weird error when building the project. 

I wondered if I had done something and accidentally borked part of the project, but then I just clicked the build button again and it worked flawlessly. It just randomly broke that one time and has been fine before and since.

I’m writing about the recent Unity (((fiasco))), which is a more political story than you might have initially thought, and I don’t want to write the same things twice. However, I will say that there is a good reason why I’m using Unity only for prototyping, before building my own engine, and I hope issues like this help explain why.

Anyway, the game itself worked as intended, and I was curious to see what sort of scores the playtesters would get. One of them topped out around twenty thousand, with another at almost forty thousand. The first score was roughly what I expected. The second was about twice as high as my highest score.

I wondered how they had scored so highly, before remembering that the pathfinding in the game is essentially broken, and the player character can go in places that are supposed to be out of bounds. I hadn’t played the game that way because I was testing other things, but it’s funny how you give a game to playtesters and they break it even by accident. 

You’re not supposed to be in the grey area…

Take the above screenshot. You’re not supposed to be able to walk on the grey areas. I know that the art doesn’t make this clear, but it’s not supposed to at this point. Nevertheless, the PC can simply walk up there whenever they feel like it, where they are close to immune to the enemies. Or at least some of the enemies. Some of them obey these rules, others don’t. Still others go onto the grey area, then break in some weird way. 

While it’s not a crucial issue, the minimap at the bottom right is a mess. I decided to differentiate between enemies by using larger or smaller circles, not wanting to waste time making art for each enemy type. Eventually they’ll be represented by stylized circles that display a sort of logo showing what kind of enemy they are. Even before then, something drastic needs to be done to make it more clear what is where, since large numbers of enemies blot out the map.

Speaking of those large numbers of enemies, the game starts chugging to a halt when somewhere near 100 enemies are on screen. That’s almost certainly due to the pathfinding, which is half-broken, and very unoptimized. If I was going to fix that problem, I’d profile the game, but we’re nowhere near that point right now of course. 

It’s also notable that the UI is so unclear that one of the playtesters thought there was a bug where the audio for the gun stopped working, before eventually starting up randomly again. What actually happened is that the gun has an overheating mechanic, and if you fire it too much you need to wait until it’s at half heating before you can fire it again. The game was just so unclear about this, and with so many other things on the screen, that they thought that the gun was still working, but the audio wasn’t.

This is what games in development look like. They don’t work until they do, and they look terrible until they don’t.

The first week accomplished what I wanted, and for the next week I’ll be grinding away getting the actual combat much more functional. There are so many things to improve that listing them here seems like a waste of time. 

Once that starts taking form, to the point where new players can intuitively figure out the game and play it mostly properly, I’ll start working with the volunteer artists to get some good and functional artwork in the game. That’s a process that could start as early as next week, but is probably a few weeks out.

Just as the Friday builds will be a recurring weekly feature on the site, so to will the Sunday writeup pieces.