As Opticode expands during the coming months we’ll be looking to take on a few more programmers so shoot me an email if you’d like to work for an agile company working on some of the latest Microsoft technology.

I’m still working away on the back story to CIC which has become my spare-time hobby. I’ve been asked by quite a few people about CIC’s status and I’m happy to report that while the direct development is on hold, the design is always evolving and the game will be released eventually.

In other news I’ve been busily working towards big milestones at work and all is going well.  I’ve started playing with HGE (Haaf’s Game Engine) and so far I’m enjoying it.  I’ve just put a small game together which I’ll release later in the week for everyone to try out.  I decided after writing an article and all the months of work on BSG and CIC I needed a small pet project for the weekend so I threw something together in a few hours.  I’ll have full stats when I release the game.

That’s about all for now.  CIC is still creeping along slowly however with 9+ hours of work per day and then an hour or so of article writing I haven’t had the brain energy left to solve some of the complex problems I’m facing in CIC.  It is moving along smoothly though and I have movement with missile pathing working nicely.

This is just a quick post to say happy Easter and let you know how things are going at the moment. Things at work have been going crazy leading up to big milestones so I’ve been putting in 10+ hour days for a while now. This has left me little time to work on my latest blogs, but rest assured, I have a number in the works. I’m currently playing Silent Hunter 4 in all its bugginess and as usual still playing as much Company of Heroes as I can with my limited spare time.

CIC is moving along quite slowly. I’m looking to convert my engine to use 64bit floating point numbers (doubles) so I can accurately represent the entire Solar System down to centimeter precision. Once things settle down at work (probably not for a few more months) I’ll look at getting back into ~10 hours a week so I can make some more progress.

I’ve had some requests for blog articles which I’m working on at the moment. If anyone else has any requests please post a comment and I’ll write up an article if I know enough about the subject. Until then, have a great Easter.

Without accounting for the orbital parts, I’ve estimated about 55 hours of work to reach the tech demo. As I’m doing a lot of overtime at work at the moment I won’t be able to hit my usual 10 hours per week of work so I can’t set a date for the tech demo yet. Having said that, I’m making good time so far and will do as much as I can when I get the chance.

As always, any comments, ideas or feedback on the ‘fun’ parts of orbits or anything to do with moving in space is always welcome. I’m aiming for true* Newtonian physics which will allow for fun real 3D combat thanks to my as yet unannounced time algorithm.

*Many games claim to have Newtonian physics only to add in a ‘dampener drive’ (or equivalent) which magically takes away all the pains of REAL Newtonian physics. I hope to have a game that finally allows true physics without the player worrying about spending hours speeding up and slowing down.

The big question here is why am I adding ‘true’ 3D to my game, is it just a gimmick? I’ve been thinking about this recently and come to the conclusion that it’s not. If I go back to my initial reasons for adding true 3D, it was not to try and sell more copies or add more features, it was to allow more strategy in my game. Not only that, it was to add true strategy to the game. Space combat (as explained very well in Ender’s Game) will be truly 3D and we’ll need to unlock our minds from thinking about ‘up’ and ‘down’ being relative to the world (or planets) around us, instead they are relative to where the enemy is. Hopefully this will make for engaging gameplay, I’m willing to bet it is and I just hope I can make the interface to pull it off.

So that’s where things are at the moment. I’m hitting the books with design and working on some more complex 3D math problems. I’ll keep you posted on how things are going and will start to set out a schedule soon for Alpha 2 which will include 3D movement.

The Mini-Game

As part of a mini-game for CIC I wanted players to be able to play a chess-like game allowing one of the 4 or 5 players per ship to conduct ‘Electronic Warfare’ against other ships they were battling with. I needed to do a lot of prototyping of the game rules testing different types of units, different board sizes etc. For the greatest flexibility in prototyping I decided to implement the entire game logic in script files allowing rule changes on the fly. After investigating the different options for scripting languages, I chose to go with GM Script. It also gave me the added benefit of trying out GM Script on a small sized project to help decide if I should use it for the high-level AI in the rest of CIC.

During the creation of the board game engine I first created chess and checkers, using script files only, to make sure I had enough features for a full chess-like game. I then created a separate script file with the rules and unit types for my ‘Electronic Warfare’ game. It shows just how flexible scripting languages can be, with a simple change in script file completely changing the game.

Game Monkey Script

GM Script is “a simple, small, game / application extension language for C++ coders”. It’s similar to Lua, but designed with C/C++ game programmers in mind. Using a C style language it allows script (.gm) files to be loaded and executed at run-time. The script files allow many useful features from configurable variables to complex functions. I found it easy to use, simple to integrate with my own code, and generally a great benefit to the project. I highly recommend anyone to check out GM script for any scripting solutions they need in the future, and feel free to contact me for any more detailed info or questions.

MiniMax (with alpha-beta pruning)

Thinking back to my AI subjects at university I remembered that minimax tree traversal was one of the best forms of AI for chess-like games. After some investigation I decided I’d implement minimax for my chess game, and after a few hours of coding had simplistic tree generation and traversal implemented. The basic concept of minimax tree traversal requires you to generate a tree of possible moves from the current board layout (and all moves from each of those moves etc). Each set of moves is a new level in the tree, and the children for each node are all the possible moves from that board configuration. The number of nodes in the tree quickly blows out with only looking ahead a small number of moves (currently I look forward 3 or 4 moves). To allow looking forward this far I needed the game to run a lot faster. I added my own memory pool, I compressed my board and unit class sizes as far as I could and ran AMD’s optimizer (CodeAnalyst) over my game to find any bottlenecks. After squeezing as much performance as I could out of the code I ended up running into a brick wall, I couldn’t have both the flexibility of a scripting language and still have the speed to run the minimax algorithm properly.

Script vs. AI

As a lot of the core gameplay was implemented as functions within GM script, every time I called them I had a major run-time hit which wasn’t a problem during regular play, but when generating thousands of possible moves it soon grinds to a halt. Don’t get me wrong, I’m not saying you shouldn’t use scripting in your games; it’s just that you have to choose where you use it wisely. One area of the GM script that allows your app to still have excellent run-time performance is configuration variables. By loading all of the definitions in at once (at load time) and storing them in regular C++ structs/class you can then access them at full speed while still having the flexibility of originally loading them in from script. There is no native support for binding GM config files to C++ struct/classes however it’s a simple task to create this yourself. Using configuration variables I’ve managed to get around the problem for now, however it means I can’t have any of the extra features (like special moves such as castling in chess) working with the AI.

The main performance problem will occur if you use script in a time critical part of the game loop. Scripting languages when compiled to non-native byte code will be 10-100 times slower than native code.

Conclusion

So in summary, GM script could be a great addition to your game, in moderation, and minimax is an excellent algorithm to use in any chess-like game. Minimax has fairly limited uses outside of that scope, however it was fun to implement and only took a few hours to get up and running, with a few extra hours optimizing it. I now have the fun task of making the AI smarter through the ‘score’ it gives to a particular board configuration, the better the algorithm, the smarter the AI will be. Once I’m happy with the AI I’ll look to start integrating it within CIC and see how it plays with the rest of the game. Then it’s on to implementing all of the fancy features I’ve come up with over the past few months of design. I’d like to thank Shauno for working on the art for my ‘Electronic Warfare’ game, it goes to show again just how much better a game looks when a real artist has spent even a few hours on it.

Below is the list of 7 rules I follow during the design of a GUI for any game.

1. Less is more

People in general become overwhelmed and confused easily. This is particularly true when playing games as people use them as a time to relax and enjoy themselves. Work out what the player’s options are in each section of the game and remove any UI elements that aren’t relevant or that are used infrequently. From speaking with gamers from casual to hardcore I’ve found that confusion actually grows exponentially with the number of UI elements you have on screen at once.

2. Context sensitivity is in

Context sensitive help and options are all over Windows XP for a reason, it makes life so much easier. If you are right clicking on a folder then you’ll want to perform different operations to right clicking on the start button. In games, there are a multitude of different approaches you can take from performing a different action based on what they clicked on to bringing up different options in a radial menu when they right click on a different object.

3. Match data to representation

Programmers like to represent everything with numbers on screen. It’s quick, gets the data across and doesn’t take up much room, what more could you want? The use of numbers to represent some data is fine, such as the number of arrows left in your quiver, but displaying the current health of the player can be done in better ways. The first time I saw this work really well was playing Sim Ant over 10 years ago. The player had to assign a resource between 3 different options. Rather than have 3 numbers you could change where increasing one decreased the other two they had a triangle where you dragged a dot to any point in the triangle representing a split of the resources. It was so simple and elegant and even though I was only 10 years old I instantly understood what to do.

4. Mouse over help is in

This is another concept introduced by Windows that works well in games. The Movies does this really well by displaying a help bubble with general information about the object and after a few more seconds displaying more detailed information. World of Warcraft has one of the best mouse over help interfaces I’ve seen in a game to date. Nearly every UI element in the game has information telling you exactly what it does removing the need for a manual or even looking through a help file.

5. Give immediate feedback for every action

This is a key point to reducing the frustration of the player. Whenever they click on a button or object you should let them know that the game has registered their action, from simply playing a sound to playing an animation on the button. Warcraft (the RTS) used to give an immediate response from the character when you ordered them to do something even though the character didn’t actually perform the action until the server sent the response back. You couldn’t notice any problem as your brain was satisfied that the character understood the order and was just a little slow to get moving. If you’ve ever found yourself clicking multiple times or yelling at the screen because you’ve clicked 20 times and nothing has happened you will understand how frustrating this can be.

6. Keep the user from moving all over the screen with the mouse

You should try to position UI elements together in their logical groups as much as possible. It’s a good idea to keep UI elements to the sides of the screen out of the way, but try and keep them all in the one area rather than around more than 1 or 2 sides of the screen. In this picture the red parts indicate how much of the screen the user can click on. World of Warcraft succeeds by keeping everything to the bottom while Nexus has 3 sides of the screen where you may need to click meaning you spend a lot of time moving all over the screen to select different options.

7. Design before you begin

Ad hoc GUI’s show and they are really awful to use. This point was reinforced with how difficult the initial UI in CIC was for most users. They were overwhelmed with choice and had options they hardly used. Most parts of your game will only be seen infrequently, however you can be guaranteed the GUI will be on their screen the entire time so it’s important to design it properly. This is reinforced by the fact that releasing your game with a simple ad hoc GUI and then fixing it in a later release means the users will have to re-learn an entirely new interface and they will have picked up bad habits from your first ad hoc design.

I’m working on a small game for a friend for the next month or so after which I will be continuing work on my board game which will be part of the “Electronic Warfare” section of CIC.

[Edit] For my blog on why trying to remove GUI’s completely is a bad idea, go here.

I’ve got a list of 5 polish items which will make the game easier to play, so I’ll implement as many of them as I can. None are too critical so it’s safe to introduce them at this stage. I’d highly recommend checking out the tutorial videos if you haven’t already as without in-game tutorials the game is quite daunting to begin with. This will be a major factor over the next few months as I work out ways of fixing the interface design (which has been ad-hoc so far) and basically making the game accessible to all players.

I’m away this weekend visiting my parents so I’ll try and upload before I go and leave everyone to try the game out over the weekend.

PS. Happy birthday Ryan and Amy…and good luck in your interview tomorrow Kel.

I’ve also decided to unlock the forums so you no longer need a login to post.  There’s still a poll running and if you want to give any feedback about CIC it’s a good place to start.

Cliff and I had 3 player test (he used his laptop as well) and it all went well.  There were a few bugs we found, however most of them have since been fixed. I’ll be doing a few more multiplayer tests before I’m ready to put the a build up on the net for everyone to make sure there aren’t any major issues.