Icefall Character Creation, Nov 30 2009

Note: the “portrait” is currently a giant, upscaled version of the tiles used for the characters ingame. I would love to have larger character portraits, but my artistic skill just isn’t there…. hopefully I will find or convince someone at some point to help out

Class Selection

In Icefall, Class is a much more important choice than Race: Race has a few minor effects on stats, starting location, etc, but Class affects how you will approach the game: how you will defeat monsters and complete quests.

I strongly considered a “class-free” model, where the player starts with a generic character and shapes it over time just by their choices of equipment and ’specialisations’ (Titan Quest is a good example of this approach), but it made things too complicated, and you don’t gain too much in the approach anyway: in Titan Quest, if you don’t specialise correctly, you’ll end up a sort of “jack-of-all trades” type character who is not good enough at any one thing to get very far. So you may as well make the choice up-front, so that you and the game can work together to give you the type of experience you want. Choose a Ranger? Great, I’m going to give you some ranger-related quests.

Original Design

This screenshot is actually from the realtime Icefall prototype. I needed a quick way to change screen resolutions for testing, so this is it. Some interesting features: The green background would slowly sway while the dialog was open, and there was a shimmering gold border around whichever element had keyboard focus.

Revision

Fast forward to the turn-based rewrite of Icefall, and this is the original Video Options dialog. Some big changes: the background texture is more subdued, there is a panel on the left to select what type of options to view, and the gold-edge focus indicator has gone (now, the focused element is just highlighted a little more). Buttons and checkboxes have also had a minor makeover, e.g. the buttons are now rounded.

Revision 2

What changed here? The window frame! Gone is the ‘rusted steel’ frame from the top and bottom of the window, replaced with an ice-blue frame that encloses all four sides. I wanted to get more “ice theme” into the UI for the game, and at the same time I needed a UI frame that covered the left and right too, because not all UI elements use the slate background (the spellbook, for example, uses a ‘book’ background, and it looked a little strange with no enclosing frame). I also think this looks better than the previous one.

Current Design

Good, the rate-of-change of the dialog is slowing down, which means we’re getting closer to completion! The only change here is to the background of the listbox. The ‘green waves’ looked ok in the original version, but as the look and feel of the rest of the dialog evolved, it began to look more and more out of place. When the dialog frames turned ice-blue, it was a good opportunity to build on that existing colourspace and again lend more of an ‘icey’ theme to things by using a dark, ice-blue texture. This is what this dialog looks like in current builds. Hopefully, you agree with me that it’s the best looking of them all?

With Icefall, I’ve already taken the decision to target Direct3D9 – I get a lot of extra capabilities compared to DirectX8, and it still works with Windows XP unlike 10 or 11… a pretty simple decision.

But what about in terms of video memory? And system RAM? What’s a realistic minimum these days? Icefall is a freeware, turn-based RPG, so by rights it shouldn’t require a leading edge PC, but I need a specific target to prevent limiting myself unnescessarily.

Howzabout 32mb video, and 512mb RAM? I think that fits most every PC you could buy in the last few years… and should be enough for some reasonable effects. Anyone got any thoughts on this?

Initially, I looked at real-time. This is the only choice for multiplayer (turn-based multiplayer just doesn’t flow) and all of the ‘modern’ games follow this formula. So I developed a playable prototype along these lines. While still using a tile-based world, this would allow freeform movement (characters were not tied to specific ’tile’ locations), and could have supported multiplayer quite naturally. Using placeholder graphics borrowed from games, I developed a prototype game that ran in real-time:

Prototype of Icefall in real-time

The prototype accomplished it’s goal, which was to determine whether real-time was feasible, and what the challenges would be. After getting the prototype running with some simple monsters, I had figured out the challenges I would be facing:

* Pathfinding dozens of monsters around a complex environment, in real time, is very hard.

* Real-time locks you into a specific travel speed, and can make ‘huge worlds’ time consuming to explore.

* It was very hard to find the right ‘game speed’. Too slow and players get frustrated and bored. Too fast and the monsters can kill the player too quickly. I wanted players to dictate the pace: in Angband, you can play it very quickly or very slowly. I couldn’t find how to do that with real-time (a “game-speed” slider would not accomplish this).

* It just didn’t feel like the game I wanted to make. (I have played too much Angband).

* It didn’t quite ‘fit’ with other concepts I had already thought about, as well. e.g. I already knew that I would be implementing a ‘monster memory’, which tracked monster kills for players and stored any weaknesses/vulnerabilities/etc the player observed. With a real-time game, I couldn’t figure out how the player would access the monster memory without pausing the game (which would be ugly for multiplayer) or just looking it up academically after the battle was already over (not very useful).

Making the decision to go turn-based was a big ‘constraint’ in itself, but with the decision made, it makes many many other features much easier, and seems to make the player’s overall experience more relaxing.

This final key decision having been made, I was ready to start some actual coding. Next time, I think I’ll mix it up a bit by looking at an actual code sample…

Decision: Role Playing Game

Many of the very first games I got hooked on were RPGs: Moria, Ultima 5, Death Knights of Krynn) but each of them always had things I thought “if only it did…”, so creating my own game would be my opportunity to put that into practice. I’ve started to create many RPGs over the years, but I’ve never finished one or even got it largely playable. This was due to various different causes, either I’d hit a wall somewhere (pathfinding, AI, memory, and graphical speed have all defeated me over the years) or a new game (Halo, World of Warcraft) would come along and I’d abandon my development for long enough that I forgot the intricate workings of the code, and rather than dive back in I abandoned it.

So I’ve still never made a role playing game. Time to fix this!

Another good reason is that it’s within my ability. Making something like a first-person shooter (at least, a good one!) just wouldn’t be possible for me because having decent graphics is too large a part, and my graphical ability… well, let’s just call it “Programmer Art” and move on.

Decision: Free Pascal

Having decided on the type of game I’m making, the next step is to choose the programming language. These days there are more languages than ever, and some of the new ones are really good. C# + XNA would be my ‘high level’ choice, it makes it ridiculously easy to get graphics on the screen and a game up and running…

But…

I’m not just programming to make a game, I’m also doing this because I want to be challenged. I want to take fundamental, low-level control over everything my code does in every situation. Using a low-level language (C++, Pascal…) means there’s a lot more up-front effort involved (getting graphics on the screen isn’t one line of code anymore, it’s a couple of hundred) but, to me, also much more satisfaction when it works!

When I want to add a function, I can’t just copy a C# code snippet from the internet, I’ve had to go away and install the DirectX SDK, read the documentation for each instruction, look at the example code, re-interpret it to suit what I’m trying to do, and play with it until I get it to compile. The reward (and the knowledge that is acquired as a consequence of having to research every call) is worth it. (This is the same reason I’m not using an existing ‘game engine’, I’m creating my own with LX7).

Having decided to use a low-level language, my choices are C++ and Pascal (I don’t want to learn another language at the same time as creating a complex game, the game at the end would suffer too much as a result of my learning-while-doing). I chose Pascal because, I’m not really sure why, I just “like it”.It has all the language constructs I’m going to need (primarily Classes), and I like that it’s not quite as low-level as C++, which gives me a little bit more room to spend on game logic but without having to sacrifice anything.

Finally, choosing between my Pascal options, FreePascal and Delphi… I think FreePascal is superior! It definately compiles faster and makes smaller executables. It doesn’t support Windows GUI very well, but Icefall like 99% of games will have custom UI anyway. It’s also free. Finally, the platform is far less common than C++, and there aren’t many games in development using it (especially on Windows), so when the game is done and LX7 (the graphics/game engine I’m creating to support Icefall at the same time) is finished, I might have something to give back to the FreePascal community. So it’s settled!

Next time, I will talk about the third key decision for Icefall: whether to make it real-time, or turn-based?