Viridian Games

Our friend Marko Turunen has just completed a Java port of Inaria, and it’s quite good! The performance is great, he’s cleaned up some of my graphical nastiness and added new effects, and of course it’s cross-platform!

When I mentioned that I was amazed at how many people wanted to port Inaria to different platforms, he replied that it’s a nice game and it’s also small enough to be a pretty easy port. Those are very kind words. Thanks, Marko!

I love getting emails like this.

“Hello,

You don’t know me, but I have just completed a ‘port’ of Inaria into C#, and
figured I should let you know.”

This port of Inaria was done by new friend Ernest Pazera. He warns that the performance isn’t that great because his replacement of the SDL was a bit quick and dirty, but also says that he intends to eventually port it to XNA, which should improve performance.

Inaria C#

Inaria C# Source

Ernest’s website is PlayDeez.com, and he’s got several other interesting games there.

SteelGolem played Inaria over the weekend. He and I were both in the #gamedevelopers channel on StarChat and he continually commented on the game while he played it, which was fun.

Then he went and posted a speedrun!

Any regular reader of this site knows that I love speedruns. Seeing one done of my game (even one that exploits the fact that I didn’t have time to fix it so that walls stop bow shots) is a real pleasure. Thanks, SteelGolem!

Now I’ve really arrived - Tom found an exploit in Inaria. If you attack an enemy with the bow and keep right-clicking very quickly, you’ll be awarded the enemy’s XP several times until the enemy is finally removed from the world. This is because I never really made the game turn-based; I just made it so that enemies couldn’t move until the player took a turn. The game still updates on a per-frame basis; it should update on a per-turn basis.

Around the end of October 2005, I decided to try to write a complete computer role-playing game in forty hours. I was inspired by this article by Jay Barnson on GameDev.net, Jeff Vogel’s excellent work, and by my own love of RPGs. I am a professional game developer, but I’d never written an RPG engine and considered that a “hole” in my experience.

I picked a time limit because I’ve also been fascinated by people being forced to do the best they can with their skills under such limits; this was one reason why I wrote my Iron Gamedev article (the other reason was that I was feeling really goofy that day). And of course competions like the Ludum Dare also inspired me.

The project is now complete. You can download the game here, and the source files for both the game and the editor here. Here’s a screenshot:

Now, the point of this project was to learn, not necessarily to make a complete and fun game. That said, I did want to make the game as good as it could be in the time I had. Here’s an excerpt from my original design doc with my goals:

We need four things to be able to call the project a success.

We need to create the map structure and populate it with an initial terrain layout.
We need to allow the player to walk around the map and be blocked by passability data.
We need to create monsters and have them move toward the player and attack him when they get in range.
We need to allow the player to attack back, and to have the player somehow gain in abilities when he succeeds in killing monsters.

That’s it. If we get that, we can publish it without fear of too much ridicule.

But that’s not enough. What I want is:

A map structure where every map cell is a list of critters placed on that cell. When the cell is drawn, all objects in that cell are drawn, from bottom to top. Since the terrain object will be pushed on the map on load, it will always be drawn first, on the bottom.

A map structure that contains data for map links.

An inventory and a current equipment screen.

If we get all this implemented, I will consider the experiment a resounding success.

Finally, what I’d really like is:

An overworld, three towns, two castles, and eight dungeon maps.

An overall plot, no matter how thin.

Quests and quest objects.

If we get all this implemented, I’ll be damn suprised.

Well, I didn’t get quite everything on my list done, but I’m still very surprised at how much I accomplished. I got the map structure I wanted, an inventory, buying and selling, NPCs with different AI behaviors, levelling up, one town, two castles and eight dungeons. And a very, very thin plot, but not quests or quest items.

I kept rigorous track of my time, but since I have a full-time job and a family, I wasn’t able to spend my hours over the course of a weekend or even a week or two. It took me about three months to finish the project, and I actually feel I did well completing it in that time. I am actually alloting myself four months to complete my next forty-hour project.

I would break down my time spent as follows: about five hours was spent fiddling with graphics, about thirty hours was spent writing code, and about five hours was spent creating the NPC data files and game levels.

What Went Right

Kicking it Old-School

Emulating an old Ultima-style RPG was the right tack to take. If I’d tried to write a 3D RPG, I simply would have gotten overwhelmed and probably quit. The feature set I wanted fell into the “tough but doable” range and made for a perfect forty-hour challenge.

Using the SDL

I wouldn’t have completed what I did if I had not used the SDL and instead just used DirectDraw. End of story. I cannot imagine why someone would not want to use it for a project like this, it was so easy to use and saved me so much time.

Grabbing Graphics off the Web

All the items, monsters and NPCs in the game came from this page of free RPG tiles. This was a lifesaver - if I’d had to create the graphics myself, not only would they have looked like crap, I would have burned so much time on them that I would not have had any chance of completing my goal. As it was, I could not find any decent terrain tiles that I liked, so I ended up grabbing a lot of the ones I used out of Ultima VI. This cost me at least two hours, unfortunately.

Making an Editor

I spent about five hours making an editor for the engine - you can see a screenshot of it here and it’s included with the source package linked above. I think this may have been my smartest move. I ended up spending far too much time on the code and far too little on the maps (see What Went Wrong, below), but if I hadn’t had the editor I probably wouldn’t have gotten more than one or two maps into the game.

Using my PDA to Sync Projects

I have an Asus A620 PocketPC-based PDA. I love it, and one of the things I use it for is to keep projects synched between work and home. This way I was able to work on my project at work, sync my PDA, take it home, sync it at home, and pick right up where I left off. Now that I’ve got some webspace, though, I’ll probably set up a Subversion server to make it even easier, and give me real source control features like versioning.

Blogging the Process

This was vital. The fact that I knew people were watching kept me going when I got really tired of the project I’d like to thank my friends Ryan Clark and Tom Mauer from work who tracked the progress of the project with interest, as well as Andrew Wooldridge and Gianfranco Berardi who linked to me, and to Sol who piped up with helpful suggestions when I mentioned I was using his tutorials.

What Went Wrong

Hoo boy, where to start?

Well, first, here’s a screenshot of the most visually interesting bug I encountered during development:

Multiple Mistakes with the Editor

I made two huge mistakes with the editor. First off, I made it too early in the project. I made the editor when I felt I needed map data to work on, but once I had the map I then added lots of features to the map structure…which the editor then didn’t support. I had to add the map level number, map name and map links all by hand. The editor still saved me time, but it could have been even better if I’d just made a temp map by hand to work on, finalized my map data structure, and then made the editor.

My second mistake was a doozy. I split the editor off into its own project, instead of simply creating a new editor source file in the base project. By splitting the editor off, I ensured that all maps would have to be moved from the editor folder to the actual game folder before they could be tested - and then moved back if additional work was needed. Maps quickly got out of date and filenames got confused. I finally fixed this by putting a hardcoded path into the editor source so that it saved and loaded from the game folder, a terribly hacky solution.

Secondly, I ensured that all the changes to the source files I made while writing the editor had to be merged back over to the game project, and then changes made there had to be merged back into the editor…it was just bad. Still much better than no editor at all, but these mistakes caused me to eat up time that could have been spent making the maps better. Which leads me to…

Too Much Time on Infrastructure, Not Enough on Content

Now…this is a thing that went wrong, but in the end, this was a learning exercise, not an attempt to make a publishable game. I wanted the game to be as good as it could be, but in the end the quality of the game is not that important.

That said, the game could have been twice as good with just one or two more hours spent on the content - and I’d have had those hours if I’d both planned better and not made those boneheaded mistakes with the editor. There are features in the engine that the player will never see…because I didn’t have time to write content that uses them. Yay!

Schizophrenic Source Code

I almost didn’t want to post the source…in just about every case, I started doing things the “right” OOP-ish way, and then reverted to procedural programming when time got tight.

For instance, there is an NPC class. Great! Do I subclass from that for all my NPC types so that I can program in individual unique NPC actions? Nope, I simply use that one class and have the Update() function determine the NPC’s type and perform actions based on a classically bad switch/case statement. The input code is atrocious; I’m doing tons of stuff there that have nothing to do with input. I felt like crying when I put the code to draw the hit marker and projectile marker inside the input function with their own frame pumps…but it was either do that or cut them completely. I guess I can console myself with at least knowing that it was bad.

Conclusion

Despite all of that, I do consider the project a success. I learned a lot and created a fair amount of code that can and will be reused for other projects. And I’m planning on doing three more of these forty-hour learning exercises over the course of the next year.

It’s finished!

You can download a version to play here. A full postmortem is forthcoming…after I recuperate a bit

Here’s the readme file:

Inaria Readme File

This is a role-playing game I wrote from scratch in forty hours over the course of three months. To read more about the game’s development, please visit my weblog at http://www.viridiangames.com/blog !

BASIC CONTROLS

Inaria can be played with the keyboard and the mouse, or the mouse alone (sorry, there is no way to play it just with the keyboard).

You can move your character by pressing the arrow keys, using the WASD cluster, or left-clicking on the map where you want your character to go.

You can pick up items in the world by left-clicking on them. They will appear in your inventory. Left-clicking chests opens them, revealing their contents.

You can use items in your inventory by left-clicking on them. Left-clicking arms and armor equips them and gives you stat bonuses. Left-clicking potions drinks them.

The GUI pane in the bottom-right, right above the text area, is your main interface with the game. The four buttons on the left allow you to talk to, look at, pick up or attack anything or anyone in the game. The four buttons to the right of those are your spell buttons (although initially you don’t have any spells). The three buttons on the far right allow you to load, save and quit the game. All of these buttons work by left-clicking.

This game also uses smart right-clicking. Right-clicking an enemy automatically attempts to attack that enemy. Right-clicking a friendly NPC talks to that NPC.

OPTIONS

You can change the game to run fullscreen by opening the engine.cfg file and changing the line

full_screen = 0

to

full_screen = 1

I wouldn’t recommend playing around with any of the other options…they could very easily lead to crashes.

GAME TIPS

You start off with a little money, just outside a town. Run inside and visit the merchant. Buy a dagger and some leather armor; this will make you a bit more effective in combat.

When you find a dungeon entrance and go inside, look at the text displayed in the text area. This will tell you the name of the dungeon and its level. If the dungeon is significantly higher than your level, it’s probably a good idea to leave it and come back to it later.

Try talking to monsters!

The Clever Merchant in town is the only place where you can buy potions. If you’re having trouble finding them, sell all the weapons and armor you’re not using and use that money to buy more.

When you level up, clicking the muscle symbol increases your attack power, making you more likely to hit. Do NOT level up your speed, that statistic isn’t used in the game (sigh).

The game honestly is not well-balanced. I just didn’t have the time. As a result, it’s not that hard a game. If you play smart, you should beat it pretty quickly.

I think I’m ready to call myself finished with the engine. There are known bugs in it, but they aren’t severe, and I could easily blow all my remaining time on fixing them. In which case you’d get to play an RPG with one map with no enemies on it.

Here’s what I’ve gotten done:

• Buying
• Loading
• Dying (death is now fatal)
• The Smite spell
• Getting objects (you must now be next to an object)
• Moving with the mouse (left click in the direction you wish to move
• Smart right-clicking (right-clicking an object picks it up; right-clicking a friendly talks to it, and right-clicking a monster attacks it)
• Hit marker
• Missile marker (buggy, but I don’t have time to fix it)

What’s left:

• Make the two remaining town maps
• Make the eight dungeon maps
• Make the final boss castle map
• Tweak the monsters

I’ll probably start with the overworld, then do the final castle. Then I’ll do as many dungeons as I can. If I get all the dungeons done, I’ll do the other towns (you really only need one town, as Diablo proved). I believe that the project is still on track.

Another update that doesn’t involve prettier screenshots. Sorry.

Of the Big List of Stuff To Do, I’ve managed to bang out the following:

• Saving
• Map links
• Combat
• Inventory
• Equipping of weapons and armor
• Using items
• Selling items
• Spells (except Smite)
• Levelling up

So, lots of difficult stuff sorted now. Here’s what’s left:

• Buying
• Loading
• Dying (death is currently non-fatal)
• Implement a fullscreen/windowed button (very low priority)
• Fix the Smite spell
• Fix getting objects (currently you can get anything anywhere on the screen)
• Put a “hit” marker on the player or NPCs when they get hit
• Use a “missile” marker to show bow or Smite attacks
• Make the two remaining town maps
• Make the eight dungeon maps
• Make the final boss castle map

And that should be it. I’m budgeting four hours to finish the infrastructure stuff - hopefully it will take less. And then the final five or so hours will be to create the actual maps of the game.

It’s getting really tight, but I already know that I’m going to ship something playable. It may not be fun or complete, but it’ll be playable, and that’s all that is required for me to consider this project a success.

We are pushing toward the finish line, now:

You’ll noticed I reformatted the right pane yet again; I’m pretty sure this is the final version. The inventory is now implemented - you can get any item in the world and it disappears from the world and pops into your inventory. Two exceptions: gold just goes right to your gold pile and chests actually open and reveal their contents (currently one item per chest). You use objects in your inventory by clicking on them. Clicking on spell scrolls will teach you that spell, and the icon for it will light up in the GUI pane. Clicking on armor or weapons equips them, and they show up in your two equipment slots at the right. Clicking on potions uses them.

I had hoped to be done with the engine by the thirty-hour mark so I could spend the last ten hours on the content, but it doesn’t look like that is going to happen. So now it looks like the project will end up being thirty hours of engine coding and ten hours of content creation, when I wanted something closer to a 25/15. Ah, well.

Needless to say, I’m very pleased with the way the project is turning out. I didn’t think I’d be able to get this much infrastructure implemented.

I am on a roll today.

Again, much done in a short time. You’ll notice I changed the layout of the screen. The text area was just too small; all of this game’s personality is going to come through the text, so I need to be able to get as much of it on the screen as possible. I got unstupid about my button arrangement - I don’t know why I thought I needed three lines for that; two not only gives me more space but I think the buttons look much better in their logical groups. I also finally took the white flash off the rest of the icons, also making them look better.

But then I had a problem - I need enough space for my inventory. I need a 128×128 block to represent the sixteen items the player can have in his backpack. (Yeah, it’s like World of Warcraft…it’s also like Ultima VI!) Moving the GUI buttons up infringed on that space, so I found a way to compress the character data at the top of the screen using icons I found on the web. One side effect of this is that my tile sheet is now bigger than 256×256. I’m willing to give up that limitation; I need those icons, and I’m going to need more icons in the future.

What else? Oh, yeah, combat! You can now take swipes at NPCs, and NPCs can take swipes at you (if they are hostile to you). An NPC’s attitude toward you is separate from their movement AI, so I can have NPCs that just wander around, hitting you if they happen to get near you, or NPCs that seek you out to put the beat down on you. I can even have NPCs that just stand there and can only hit you if you come into range (the Carnivorous Mushroom is one of these).

Next I need inventory, picking up items, buying and selling. Which means I need to figure out exactly what the merchants in town are going to sell.