2010
03.10

People who know me on Facebook may be aware that I recently took a break from Icefall to focus on networking code.

I plan for networking to form an important part of Icefall’s gameplay: the game itself is not realtime multiplayer, however I plan for an ‘Auction House’, scoreboards/leaderboards/server-firsts, player-to-player mail, and other online community-type features.

BUT I have never worked with any networking code of any complexity before, and I determined that trying to ‘learn while I go’ during the Icefall development process would not be the best idea. Hence, Citadel!

Citadel is a ‘tower-defense’ game. For those unfamiliar with the concept, essentially an endless wave of bad guys (in this case, tanks, jets, armoured cars, and trikes) try to get to and destroy your tower. Your job is to build a system of defensive towers to prevent them from doing that. The towers themselves automatically aim and fire, the strategy lies in placing the right towers and walls in the right places to do as much damage to the invaders as possible.

Each wave of invaders is tougher than the last, and eventually they will overwhelm your defenses. However, each invader you kill will give you some credits to spend on additional defense, and you receive more credits for tougher invaders. So the object is to last as long as possible, try to save money for the strongest towers (the Tesla Coil), and ultimately get a big score.

As far as tower-defense games go, Citadel currently isn’t that sophisticated (it’s a beta version, after all!) and doesn’t have upgradable towers or multiple game types or anything like that, but it does have a unique feature that I couldn’t find in any other Tower Defense games anywhere: it can do multiplayer. Get a friend on a LAN, or over the internet (hook up a voice-chat program like MSN or Ventrilo!) and you can join forces to get the highest scores. It’s competitive co-operative: you share the same base and it’s game over when an invader reaches it, but who does the most damage to the creates gets the most credits for the kill, and the most score at the end.

NOTE: The invaders MUST ALWAYS HAVE *some way* to get through. Even if they have to go ridiculously long ways around crazily long mazes and queue up single file, it is against the rules of tower defense games to block them off completely. If you do that, it’s immediately game over!

Try the demo! If you don’t like it, that’s fine – but if it works (especially the networking part), or if it doesn’t work and you tell me about it and I work with you to make it work, then you’re helping me to make sure Icefall’s online components are awesome when they come out!

The Citadel Main Menu

The Citadel Main Menu

Early into a Citadel game

Early into a Citadel game

Download the beta demo here and let me know in the comments what you think, if it works, or (more importantly!) if it doesn’t work, or (MOST importantly!) what your high score is ūüôā

2010
03.07

As a general rule, I like to write all of the code used by my games/programs myself. Not because I think I am the best programmer in the world, but because – for me – one of the main reasons I program is to learn more about how software functions on the very lowest levels, and if I used extensive 3rd party code (like Unreal Engine for my game, for example) a lot of that stuff that I *want* to learn about would be abstracted away, or worse: still present but obscured and intermingled with the 3rd party code itself.

Coincidentally, this is the same reason I don’t use managed languages like C#. I quite like knowing about things that managed code wants to hide! The increase in development time is not that important to me, I have no external deadlines to meet.

However, there are points beyond which it’s not practical for me to write the code myself, because it’s either A) incredibly complex, B) boring, C) proprietary, or D) so ubiquitous that it really doesn’t need reinventing. e.g.: writing code to decode an MP3 file into raw audio. I could *potentially* do this, but as it belongs to all four categories, I’m really comfortable with not doing it myself!

Currently in my Freepascal development I am using three 3rd Party Code libraries every day. And they are all excellent, both in terms of features and being easy enough that I can ‘plug them in’ to my own lx7 game engine with very little work. Here they are:

DirectX – by Clootie

No, not DirectX itself (that deserves a whole separate subject!), but a port of all the headers/structures/glue code necessary to use DirectX in Freepascal. This gives me low level access to every function and interface used by DirectX itself, and the port is so perfect I was able to build my own graphics engine on top of Direct3D just by studying the (C++) DirectX SDK. Nothing is missing! Everything works! You probably won’t appreciate how rare this is if you normally use C++.
http://www.clootie.ru/

BASSfpc

BASS is an Audio Library that makes it *dead easy* to play sound and music files of many different types. BASSfpc is the FPC port of this. BASS handles MP3s, WAVs, OGGs, and about a million other sound types, and it does it efficiently and with the bare minimum of code needed (literally about 4 lines of code to init the library and start playing an MP3!).
http://www.un4seen.com/

LNet

The newest addition to my Libs folder. LNet provides a set of classes to implement networking, at the very lowest level, without adding any additional features or complexity. That’s exactly what I needed, because I want to add my own features and complexity! There are many many network libraries out there, but (for Freepascal at least) LNet definately gets my vote, for being simple, class-based, and extremely elegant.
http://lnet.wordpress.com/

2010
01.10

Long time, no update. My holiday from my real job is almost at an end, but the good news is that I have spent a lot of time with Icefall and it’s actually starting to come together!

I had developed a lot of separate pieces of game infrastructure (random map generation, character creation, character death… etc), and over the last couple of days I have successfully integrated them all into the main Icefall build. This means that what I have now, for the first time, is a *fully* playable game! You start out creating a character, you can explore, find items, kill monsters, and be killed in turn.

There’s still thousands of features missing (I had thought I was pretty well progressed on the UI side of things, but now the framework is in place, I can see there are quite a few gaps I need to fill in) but now I have something that feels like a game, I can start iterating on it and trying it out.

The game has killed me several times already – I have added a few ‘tough’ monsters for the deep dungeon, but I haven’t really added any high-level equipment yet. So it’s possible for my character to be wearing all the best items in the game and still get owned by the monsters. This will be fixed as I add in more content ūüėÄ

I didn’t meet my goal of having it completed over Christmas, but at least I have made significant progress. Overall, I’m pretty happy with how far along it is.

Finally, anyone who has played a roguelike will be very familiar with the death screen. Here’s Icefall’s current version (more information about how/when/why you died will be added in future):

The Icefall death screen quickly becomes familiar.

The Icefall death screen quickly becomes familiar.

2009
12.26

Happy Holidays

Sorry, no posts for a while! I’m on holiday for Christmas, although I will be spending some time working on finishing up Icefall, I probably won’t be posting that much.
See you in the new year!

2009
12.15

This is the second entry in my set of “10 Game Development Golden Rules”. Hopefully, this one is less contentious than the first!

The rule is:

Provide gamma and volume controls, and separate music from sound.

Pretty simple. But essential! The good news is, the AAA titles pretty much universally support this now. And it’s a good thing, as I use these settings all the time.

I have an Xbox 360 but, unlike most Xbox 360s, mine isn’t connected to a TV – it plugs into a second DVI port on one of my 22” widescreen PC monitors. This is awesome because I can run it at 1680×1050 and games look beautiful! (handy bonus: I can web-surf on my other screen while waiting for Matchmaking in Halo 3)

BUT my monitor has a very different colour profile than your average TV, and games with a lot of contrasting light/dark elements can look really bad by default. Gamma controls in your game are pretty essential for me to see the graphics the way the designer intended. I’m sure there are other people in similar situations or even wildly different situations who also need gamma settings. Your game needs to support them too!! And since there’s nothing on the “con” side of the ledger that could make it a bad idea, you have no excuse!

Providing separate controls for sound/music: Music is awesome but people like to be able to hear the game sounds sometimes! Particularly in a ‘competitive’ environment, or simply when your game is providing an audio narrative (GTA4 is an excellent example – the “in-car radio” music is huge and contributes to the GTA atmosphere, but you need to turn the music volume down to be able to hear what mission you’re being given via the cellphone). If I’m playing an FPS single-player, I might turn the music up, but in multiplayer I want to use every audio cue the game gives me for competitive advantage, so I need to kill the music or at least turn it down.

Just like with the gamma controls, the good news is this is pretty universal now. But there are still Flash games that don’t separate them (and, even worse: there are plenty that have no Volume settings at all – sound is either On or Off). Sound might *add* to the game experience, but I’d like to set it so that it doesn’t completely drown out my background music, thanks! Vista and Windows 7 allow you to set the volume controls at the “application” level, which solves the problem for me specifically, but it doesn’t help anyone using XP (or anyone who doesn’t know about that feature). Support them too!

2009
12.06

OK, this trick is probably universally known, but I’ve only just discovered it (by the classic programmer method of reinventing it), so on the chance there are others who are unfamiliar with this technique, it’s worth describing.

Any sufficiently complex game is going to have “assets”: data external to the main program that the game depends on to function. This includes “art assets” (textures, images, music, etc) as well as more application-specific “data assets” which contain data in a format unique to your application (e.g. Icefall has¬†“item types” of all the different equipment players can find/buy/receive).

Handling art assets is relatively easy: you create/modify them in Photoshop (or equivalent), you save them as PNGs or JPGs, and you’re done! You might wrap them all up in a custom file format to compress/encrypt/streamline them, but that’s pretty simple and you¬†can do that at the very end of development.

Data assets are different. There aren’t any programs around that can edit “Icefall item types” files. I need to write my own “Item Types Editor”, which understands this format and can load, modify and save it. This leads to two problems:

1. I have to spend time writing an Editor. (the actual format load/save code could be shared with Icefall itself, but there’s all the UI!).

2. If I ever change the “item types” format, all the data I’ve previously created is now in jeopardy. (What I typically do is modify the ‘save’ code only, run the editor and¬† load each asset (old-code), and re-save it (new-code), then when that’s done I can modify the ‘load’ code.

Depending on the type of data asset, using Asset Text Files may be superior. I DON’T mean your game should store all of it’s data assets in plain text (yuck!).¬†Here’s what I mean:

Whip up a simple¬†plaintext¬†‘syntax’¬†that stores all of the information you want to include¬†in your data asset. Then,¬†¬†instead of creating an “Editor” with bulky UI code, create a command line utility that can parse your plaintext files and spit out your compiled data asset files. If you borrow your main game code for load/save, all you have to write is the text parser, and that can be as easy as you like: you’re dictating the syntax it has to interpret.

The BEST part of this system is that it makes changing the format of the assets later on very very easy. Oops, I forgot a field for my item types? No worries. Add the extra field to your text file sources (bringing to bear the full power of your fantastic Programmer Text Editor / IDE¬†you’re using – the programmers’ Photoshop), a quick change to the asset compiler to recognise the new format, and hit execute.

You get other benefits too: you can put ‘logic’ into your compiler without having to put it in you main game. (e.g. scale the values, dictate whatever “optional” or “Default” fields, anything!

It doesn’t work for everything (e.g. Icefall’s “Level Map” is huge and an Editor really is the right option for that) – but when it’s appropriate, I have found it works brilliantly.

2009
12.05

One of the hardest bits about creating Icefall was getting the User Interface (UI) just right.
Icefall’s chief inspirations are “old-school” role-playing games like Angband (aka Roguelikes: Nethack, Moria, Omega, ADOM all fall into this category). But these old-school games all rely on essentially a text-mode interface with a myriad of hotkeys. I want to make Icefall more accessible than that. So I took the UI elements from ‘modern’ RPGs like World of Warcraft, Titan Quest, and Dragon Age: Orgins: hotbars, cooldowns, drag & drop.

Of course these ‘modern’ interfaces are much more work to get right than a classic keyboard-driven one. Even though I’ve spent more time on this aspect than any other, it’s still not perfect. Here’s an example I found yesterday:

Icefall Backpack user interface

Icefall Backpack user interface

Looks easy enough. To equip the Apprentice Jerkin, players can either click and drag it to their Character Sheet, or else right-click it to equip. The problem: there are two, identical jerkins in the player’s inventory. Click and drag works fine, but if you right-click the second one, a strange thing happens: the *other* jerkin is equipped instead, and disappears from inventory.

Why? Well, right clicking an item in Icefall triggers a codepath to essentially “Activate Item: Apprentice Jerkin”.¬†It’s set up this way so that players can also drag equipment to their hotbar, and¬†equip it directly from there.¬†All good so far. BUT: internally, the inventory is stored as an array, and is stored from left-to-right, top-to-bottom. So when the “Activate Item” codepath is triggered, it goes looking for an Apprentice Jerkin to activate, and it finds the other jerkin (the one in the row above) first – so it activates it!

A rare situation, a completely logical consequence of the way I implemented right-click behaviour. Technically correct (There are no downfalls to the player if the ‘wrong’ jerkin is equipped: they’re identical by definition) and yet it feels completely wrong and would likely alienate a casual user. So I’m going to have to find a workaround ūüôĀ

2009
11.30

Because screenshots are always interesting, here is a screenshot of the “Character Creation” part of Icefall. This is one of the very first screens new players will see, as they opt to begin a new adventure the first thing to do is decide who they’re going to be. (I deliberately replaced the description text with Latin, don’t want to give away too many plot points at this stage!)

Icefall Character Creation, Nov 30 2009

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.

2009
11.27

I took a few days’ break from Icefall to develop a quickfire helper application for myself (a simple media-centre type program to organise, search and filter the various videos and music I have lurking around, with a few handy unique features like automatic IMDB-Lookup for descriptions, saves me typing them off the DVD cover).

After working on Icefall for so long, I was amazed at how quickly I was developing the code for the new program! When writing Icefall, I might create a single new source file in a night’s work, or maybe make 4 or 5 moderate improvements to existing code. On the media app, I was churning out half a dozen new source files at a time, and I had the entire application virtually finished in about three days.

Thinking about my observations of the difference, I eventually came up with the following formula:

Development Speed = Effort / (Complexity * Quality)

For a given amount of effort, I can get a lot more done on the media app, because A: it’s far less complex, and B: I care much less about the quality of the code. Multiply those factors together and you can see why Icefall development is approximately an order of magnitude slower: it’s a complex system, all the code has to be correct, robust, speedy, and extensible.

I’m convinced this is part of the reason why so many “we’re going to create the perfect application, that does everything and is open source” projects never reach version 1.0. With all the effort in the world, they’re just throwing huge numbers on the wrong side of the divisor.

2009
11.21

Taking a break from coding topics, today’s post explores how Icefall’s dialog User Interface (UI) has evolved over the course of it’s development. My automatic-backup tool keeps every version of Icefall available, so I fired up a few old versions and took some screenshots to illustrate the process.

Original Design

UI Dialog: Original

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

Icefall: 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

UI Dialog: 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

UI Design: Final

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?