In terms of things related to behind the scenes stuff, I’ve mostly been ripping out old code from Sim Mine and redoing some of the GUI system so it’s a bit more flexible. There’s still a lot left to work on in both of those elements, so it’ll be an ongoing project until I’m done. I’ve also been working on code to allow for a flexible room plugin system. Mostly likely, plugins will require an XML file and graphic file for the actual room graphics. I want the game to be flexible, and be able to load different room sets based on a settings file, most likely something similar to how OpenTTD works. It’s in the early stages right now, though.

I’ve been thinking about how the interface itself will function, as well. I will likely use category buttons along the top which will contain drop down menus with the actual build buttons in them, similar to Sim City 3000 and Sim City 4’s construction menu, combined with Rollarcoaster Tycoon’s icon menu along the top. I’m hoping this will be effective, but the only way to find out is to try it. I might look into making the interface configurable, but that will likely come at a later date than initial releases. The biggest stumbling block though is getting an interface for elevators. In the original, it was easy to expand (and shrink) the elevator shaft up or down a floor or three. Yes, you had to choose a specific tool to do it, but it was still pretty simple. With an isometric view, there’s a problem, since you can’t really see what’s happening with an elevator, nor can you easily raise an elevator up a floor when you have to view the building in slices, instead of the whole thing from the side. If anyone has ideas or comments for how to implement the elevator interface, I’d love to hear them.

So, why isometric instead of straight up 3d or a straight 2d remake? Well, the original 2d lacked a lot of depth, in that you couldn’t really lay out the building with more designs beyond the basic large base, smaller top, or even the less exciting sold rectangular block. Yoot Tower improved things a bit with the ability to build multiple bases, and have sky bridges that spanned the gaps, but you were still limited to two dimensions. Actual towers are usually a bit wider than a few meters. Thus, the decision to include a third dimension. However, full 3d requires additional complexity with the code and graphics, and good 3d graphics take longer to do than good 2d graphics. Plus, I had an isometric engine that could do multiple levels already made, so why not?

So, what’s next? Currently, I don’t have much more done than most of the remake projects, and nothing that’s worthy of showing off. Any screenshots right now would consist of terrible graphics made within 5 minutes in Paint.net, downloadable version isn’t too exciting when there’s nothing to do outside of build some blank flooring. My next goal is to get some of the basic game elements in, such as offices, a lobby, and elevators, and possibly more. I hope to get there in a month. At that point, it will probably be worthy of a demo. For now, terrible graphics screenshots.

Skybridges are possible.

Cutaway view of the skybridge.

Additionally, the coding turned into a horrible mess and it got to the point where adding any more features would be too painful. The project was scrapped with plans to revisit it at a later date. I spent some time with Ludum Dare projects to get better at coding overall, and get a better grasp on what was needed to complete a game. Post Mortems of those games are on this blog.

Almost two years later, I returned to the project of Sim Mine, starting it in October 2009. This time, using a isometric tile engine, I was able to make graphics that were larger, and thus, generally more recognizable, plus the code was vastly improved overall from 2 years of learning. Adding features to the game was a lot easier, since the code was more modular and things weren’t tied together as much. The overall game was designed to be much like a combination of the Caesar series of games and Dungeon Keeper, plus some additional variety to keep things interesting.

Above the ground, and below the ground, in Sim Mine 2007

Above the ground, and below the ground, in Sim Mine 2009

First, the game itself was just a clone of the much funnier, and better made Kingdom of Loathing. It was also made for an obscure online community, with a pretty low population average. These two facts were probably the biggest problem, and the reason everything failed after six months. I was also brand new to SQL, and generally new to PHP, and the code I wrote would make me shudder with the amount of security holes and other problems. Amount other things, the inventory list was a single character delimited string consisting of an item’s ID, and a “how many they have” number. This nightmare of a system was further worsened by the fact that I had little to no error checking, and it was possible to put in a random alphabetical character in most of the boxes dealing with item management. This would result in a corrupted inventory string, and would cause a problem for that player. I eventually coded a page to allow me to edit the raw string, making fixes possible, but not always easy.

I also learned how important it was to have content for an online game ready to go to launch. Now, this seems obvious, but at the same time, players will go through all your carefully crafted quests fairly fast (or if you don’t have any actual quests, they’ll just fight monsters all day). There’s ways to limit how much content a player can go through, but often times, players will attempt to find a way around that, or simply get annoyed by everything, and give up.

The last thing I learned is you need to have an economy that works. This is mostly true for RPGs, or similar game types, since it’s dealing with item usage, and crafting. A good economy is incredibly hard to achieve, but a few general rules consist of having items that are consumed, making sure there’s a reason to trade between players, and keeping excessively powerful items from existing, or limiting their use by level.

While most of what I’ve mentioned is common sense, it’s important to realize to anyone wanting to make an online game. The failure of Game X has prevented me from finishing other online projects due to a worry of another repeat of a failed game.

What Went Wrong

Art: The biggest thing that went wrong was the art. While what was there worked, and really wasn’t terrible, there wasn’t much there. This is mostly due to my lack of art skills, and the length of time it took to make what I did have. Making the graphics that are in the game as it stands took a few hours, and while I wanted to make more monster graphics, and possibly battle animations, I simply didn’t have the time required. I probably should not have chosen a game type that required the level of graphics I wanted, or I should have done the graphics in more of an old school outline style that would have been easier to create. In the end, the lack of actual graphic variety proved the biggest downfall, in combination with the other major problem, balance.

Balance: The other major issue. Near the end of the competition, I tried to solve the problem by creating a spreadsheet with some attack/defense formulas, and while in theory what I had should have worked, the game started out hard, but quickly became incredibly easy. This could have been solved with enough time, but as it were, I was working against the clock, and didn’t want to rush to get something uploaded and ready at the last second. As it stands, while the art was a major flaw, due to not providing much feedback to the player, the lack of game balance made things boring, and not nearly as fun as it should have been.

Other: There were other minor issues, as well. The interface was confusing, and mostly meaningless to anyone who wasn’t familiar with the games I was copying, and things like the magic system got complaints for not working, which was true if you didn’t know you could power up your magic (something which wasn’t explained anywhere). There was a distinct lack of an actual game over screen, instead just returning you to the title screen. This confused a few more people, since there wasn’t really a true goal, either. All this goes to show why testing your game on others is a good idea.

What Went Right

SDL: Again, SDL being so easy to set everything up made it easier to get into making the actual game. It also makes porting a game a snap. There’s not much else to say here, though.

Sticking to a schedule (mostly): I knew where I wanted to go with the game, and I knew how long I had, so I did my best to get things done on time. I still went with an idea that was a bit too big, but at the same time, I was able to keep things pretty simple, at least enough to finish something resembling a game.

Final Results

While I didn’t get high ranks, I did finish a playable, if slightly boring, game in 48 hours. It also made me realize that just because something seems natural or self explanatory to you, it might be confusing to other people who’re trying to play your game. It’s a good lesson for any software designer, since most things can easily get bogged down with features that hardly anyone can use the bloody thing.

I managed to finish most of the basics Saturday, getting text to display, and allowing the player to fight the monsters, but at this point, the game amounted to a collection of text on a blue screen. I stopped early Saturday night to figure out where to take the game next, and eventually sleep.

Sunday, I woke up with about 12 hours left to the competition. Vowing to complete something by the end of it, I worked on making some major changes to how the text output was generated, as the current method, which worked, didn’t allow for a good way to make the “floating” text that I wanted to create. After spending way too much time on getting text to work, I decided to work on some basic graphics, so there’d be something to look at besides just numbers. My plan at that point was to have a collection of monster graphics, and the game would simply pull from a selection of monsters, more powerful ones showing up as you gained levels. However, I am not much of an artist, and after spending about 30 minutes on the two existing monsters and the background, I gave up on the art, and went back to the code. At this point, the game worked, and looked reasonably good, but the battles were too easy, and never got harder. I spent a few hours trying some numbers in OpenOffice Calc, hoping to come up with numbers and formulas that produced a challenging game. I wasn’t entirely successful, since the game starts out hard, and becomes incredibly easy within a few levels, but I decided to finish up and make sure the game worked. I posted the final version early, but I wanted to avoid a rushed post, and I couldn’t chance that I wouldn’t ruin the game within the next two hours.

Overall, even though the game didn’t turn out amazing, it’s coded better than my previous challenge game, and it’s more or less a finished product that doesn’t crash every few seconds. Voting is still going on, and I hope to write up a full postmortem once the game is given ratings. I already know that balance is a major issue, and the lack of any visible progression didn’t help much. In the meantime, I’m gearing up for my next project, and hopefully I can finish it in a reasonable period of time.

It was originally supposed to be at least somewhat complex, having to direct rabbits to food, and build the burrow correctly so it wouldn’t collapse. It ended up being a game where you direct one rabbit to dig holes in the ground, and it had a 90% chance of crashing without an error once more rabbits appeared. The actual burrow digging and building, originally designed to be similar to Dungeon Keeper, turned out workable, but building the burrow rooms was simply a matter of plunking down single tiles where you feel like it.

What Went Right

Admittedly, not much went right, mainly due to my lack of experience with the tools I was using (I was learning SDL, and refreshing my memory of C++ during the competition). However, there were a few things I did right.

Using SDL

I had done a few small programs to get used to SDL, and SDL helped me hit the ground running, as it were. I had a basic chunk of code to use for the early stages of the competition, and SDL made it easy to add functionality for a variety of other things. If I hadn’t used SDL for the competition, I would have never gotten off the ground.

Getting an artist

This was both good and bad. Mostly good, however, since my own art abilities would not have produced much in the way of graphics in the time allowed. The downside of this is discussed later.

Finishing the Game

Even though the end result was plagued by bugs, and a pretty boring minute or two that it takes to beat the game, there is, in fact, a game there. The goal is get 50 rabbits, and it’s possible to achieve this goal. It’s hard to lose, though, outside of the game crashing prior to getting up to 50 rabbits. However, there is a game there, and that’s enough to be proud of.

What Went Wrong

Plenty of things went wrong, from not really knowing what I was doing, to figuring out how to make the game an actual game about a week before the end of the competition. The end result was a buggy, un-fun mess, even though I learned a lot from what I did, and didn’t do.

Learning While Programming

This was my biggest problem, even though it was the main thing I gained from the competition. I spent much of the time learning how to do this or that, and I ran out of time for any sort of actual game design. I was relearning bits of C++ such as standard library data structures, and learning new things like SDL, and pathfinding. The combination of all of the above lead to me really getting in over my head as far as some things were concerned, and I eventually ran out of time. This lead to the bugs in the game, as well as code that is terrible, to say the least.

Getting an outside artist

Admittedly, this is also a good thing, given that the ‘art’ I had made previously was about as good as standard Atari graphics. The only downside was a lack of communication, on my part as far as what formats I needed the graphics to be, and exactly how much I needed. I ended up with graphics that I couldn’t use in the time left, given that I hadn’t programmed the engine (as it were) to accept graphics in that format.

End Result

The biggest element gained from everything is that I know that, given a deadline and a reasonable desire to finish, I can pull through and finish a project. I also learned a lot about what goes into putting together a game, and have taken that knowledge into future projects. From this, I hope to pull off something for this years’ Ludum Dare, and finish a project that, if nothing else, is more stable than Rabbit Tycoon. Barring that, I hope to get enough experience and drive to finish off another of the projects that I’ve left on the wayside.