August 2006

Ingame Hexfield and more Gamedesign

Coding on the game is fun, doing game design is fun, but coding boring tools to create content isn’t. So I usually switch between those three things on the fly, so that the boring part of creating tools doesn’t overweight the fun of doing the creative stuff for my current project.

And therefore, after coding some hours on “WeltEdit”, the editor to create all content for my current project I went on to implement the three-dimensional hex battlefield into the game, and now have it up and running in it’s own window, nicely implemented into the GUI. Now I “only” need to fill it with the military units that’ll be in the final game and some additional environmental stuff (the shots in an earlier post were from an external test-application, so the models shown there won’t make it into the final game). Since I already have created the datasets for the military units in the above mentioned editor, next would be to create the 3D-Models for the units. But that’s usually pretty fun, so I’m kinda looking forward to do some 3D-modelling again (it has been quite some time since I made my last object in a 3D-modeller).

On the game design front, I started making a list of the buildings that the player can build in a region. And I must admit that it’s a really interesting part of the game design, cause it’s not just something like “this kind of building sounds nice, so add it to the list” but you rather have to think “this building could be interesting for the player to build and now also give it values so that he really wants to build it in the game“. I’ve already created some strategic games where the player was able to have buildings, but I never really thought about the strategic aspect of the buildings back then like I did today when creating that last. Back then I just added buildings that could be of interest and didn’t really take time to balance them. But this time it’s different. So first I made different categories for buildings and each categorie will have a different number of buildings. But all the buildings inside a category have their goods and bads so there will be a building that e.g. improve your population growth by a huge amount and a similar building that’ll only improve it by a smaller amount, but that also won’t cause as much pollution as the first one. So in the end the player will always have to weighten the positives and the negatives of each building before he builds it, which makes building much more strategic than in my games before. And to make it even more interesting, the number of buildings a player can have per region will be limited to a rather small amount (maybe 10, but I also think that I’ll even lower this, but that’s something I have to try out when playtesting), so that it’s of even more strategic value which buildings to have in a region.

Some infos about gamedesign

Maybe some of you want to know how I do the design for my games, so I thought to write down something on this.
Note : I’m no game designer and I never work
ed on commercial titles (though my freeware games and apps are rather successfull), so take the following stuff as my personal view on this matter, don’t cite me on this in a fiery discussion or so.

Most important notice about gamedesign :
>Your PC is the most dangerous enemy of creativity! <

Why you ask? Plain simple : you can do so much stuff with your PC (surf the net, read mails, play games, watch TV, listen to music, and so on) that it’s v
ery easy to get distracted. So it’s (at least for me) often the case that I try to do some gamedesign and then think “ah well, you haven’t read your mails for an hour or so, just quickly do it and then carry on”, and then you also think “now that I’ve read my mails I should take a quick look through some forums” and this goes on and on, and at some point you notice that you have your game design document open for hours, but haven’t written down a single line. And what’s even worse is the fact that due to all the distraction your mind usually won’t be able to spill out great ideas for your game. All my good ideas came out of my mind when I turned away from my PC (just switch the screen off) or was doing something totally unrelated. So maybe if you’re running out of ideas, turn away from the PC and try to relax or do something else, as the ideas then tend to come in by themselves. But don’t forget to write them down later!

The best tool (or call it “application”) for game design :
>Plain Pen-And-Paper<
This goes directly together with the above point. The best tool for doing game-design related stuff (may it be writing down ideas or drawing graphics) is a piece of paper (or a memopad, so that your stuff won’t fly all over the place) and a pen. At least that’s how I did all GUIs for my recent games, and most of the time those designs made it (with small adjustments, on paper I only do rough outlines with descriptions) into the final game, and that is also the case with my current game. Now you could also do all those fancy drawings in applications that were designed for this, like Photoshop or Corel Draw, but you’ll mostly suffer from what I wrote above. If you do those designs on paper it’s like a flowing river, you start drawing and the ideas start to flow through your head, go down your arm and drop onto the paper via your pen (literally, don’t take this too serious 😉 ). Something that usually won’t happen when you sit in front of your PC after you have opened up your favorite drawing application.

So much for now, hopefully some of you also see the above things the way as I do!

Tools and Content

Small note : I now put the abbreviation for the working-title of my current project before postings dealing with it, so you can directly see what the post refers to.

The last days I spent on coding the tool needed for putting content into my current project. I already had some tools from the old prototype, but they were neither finished nor what I really wanted to quickly create content. So I made one single application (although not totally finished yet) where I can create all the content for my game, like region-settings, unit-info and buildings and export (and also import from) to XML. So I guess I’ll spent the next days (or maybe even weeks, as I want to do some more complex things, including a small in-game scripting language needed for buildings and science) on creating the content for the game.

But when that’s done I can finally start putting my fingers on the gameplay-stuff and AI and everything else needed for making the game playable. Morever I also still work on the gamedesign document and just finished the military aspect of the game, so I now exactly have what kind of units there will be and how armies work, which will be an important part of the game (no army = no expansion).

Animated skinned UI-control

I already wrote (and posted screenshots) about the skinned controls in the GUI of my current project. And this time you can even see it in motion, as I attached a small video I captured of that control which you can see here (it’s a flash movie, about 500 KBytes big).
Due to the fact that swf is not the best format for videos it doesn’t look as good as in “reality”, but you should see that I also added a fade-in and fade-out to the controls, so that the buttons slowly fade in and seem to kind of glow out when you leave their mouse area.

Other than that I also cleaned up the old code, fixed out the memoryleaks that were in from the “early” days when I wrote this protoype and threw out all 3DS-models (and loading) and replaced it with my own .x-loader (see an older post here as to see why I prefer .x over .3ds). So now all code is up to my current coding standards and it shouldn’t be too far before I have something playable.
And in addition to that I also made the UI even more independant of the application that’s using it, as you can now load everything from and XML-file, so in your app you just do something like MainGUI.AddWindowFromXML(‘testwindow.xm’) and all information about the window and the controls that are placed inside the window are loaded by the GUI and the window can direclty be used within the application (one thing, if needed, you still must do in the code, is to set callbacks if you want to do some additional stuff when that window is drawn).

GUI – Coding and some Hex(es)

After having done the layout for the GUI, I started to implement a new skinned control into the already existing GUI-part of the project. Basically it’s a control consisting of different parts and every part has it’s own texture (overlay, the whole control has it’s own background) and is activated (rendered) as soon as the mouse cursor enters it’s polygonal area. The area itself is specified as a polygon, so you can recreate every complex shape that such a control can have. But to make things easier for me I also added functions to create the polygonal areas from basic primitives like spheres and stuff.
Adding this was no real hard task, since I already had a rather finished OpenGL-GUI (including windows, buttons, listboxes, buttons, panels, memos, images, etc.) from back when I started to project in 2003, and although the code was 3 years old it was clean and almost up to my current coding-standards. There were only two
things in that old code I didn’t like. First, back then I used objects instead of classes (just file it under “lazyness”) and so I also had no basic GUIItem-class, which e.g. made me render the different objects types in a separate loop. But I changed both those points and now all object types are derived from the TGUIItem-class, which contains most basic things like the drawing function and so on. Nowadays this is the way I always implement something like that, especially since it makes the code look cleaner and also makes using it easier, but that was 3 years ago, so no big deal, especially if I compare it to other code I wrote 4 or 5 years ago. That means for now the coding part of the GUI is finalized, and I just need to finish the graphics and put them into the game, and as usual (at least for my later projects) I use XML-files for defining the objects in the GUI (and in the different windows), so no need to change a single line of code for making changes to the GUI-layout.

And now to another part of the game, that I already planned back when I started with it. You can see a screenshot of the turn-based fights on the left. I still am not totally sure if I should put it in or not. Back then I planned to open up this 3D hex-battlefield in which the players had to fight against each other as soon as one player attacks the region of another player and depending on the outcome of this fight, the attacker would overtake this region or not. Just think of it as a very light version of SSI’s Panzer General. So if I decide to put it in, I’ll also add an option of just letting the CPU calculate the outcome of the fight, so the player can decide if he want’s to have a real turn-based fight (gameplay over time) or just want to see the final result (time over gameplay), with the first option giving the player more control over the outcome of the battle. But well, as mentioned I’ll still think about it and see if this will make it into the final game or not.

More on the GUI

Did some more work on the GUI and I guess what I’ve got now is going to make it into the final game (the screenshot already comes from within the game). It has the control center with all important buttons (still not named on the screenshot) and also plenty of space for the information the player needs to know about.

And, most important, it (at least in my opionion) perfectly fits the theme of the game. It’s the red color and glow that always tells the player that he should be in a state of alert, as all possible things can happen. Now the next step is to label the buttons and also add some nice background graphics to them. I don’t want to do plain labels, as that would kind of destroy the “flow” of that UI part, so I’ll try some graphics with overlayed captions that don’t stick out to much. Second next thing then is the distribution and positioning of the information on the yet empty parts of the UI, but I already have some ideas about what to put on it and where to put it.

Some GUI-Work

I spent some hours doing the basic layout for the control center of the game I already posted about. After doing some drawings (by hand) to get a hang on how it should look, I fired up photoshop and after several hours (and several designs) I came up with the skeleton you can see in the screenshot (click for bigger view) on the left.
Right now it misses captions and symbols, so you can’t see what the buttons (the globe in the middle is, maybe as you already guessed, for ending the current round) are done, but that’ll be added. This also shall be the main-part of the UI in the final game which is used to access the most important “parts” of the game, and my idea behind it was to give the player an easy way of accessing the most important things with a single click, and nothing should be burried deeper than two clicks. Cause especially in complexer games you often have even important functions buired under buttons which are only accessible after several click-throughs, and that is something I really dislike so I try not to drift into that direction with this project.
So besides the 3D-globe and this control center, there won’t be much more on the screen (by default, which means unless you open some windows of course) except an addtional information bar in the top of the screen which I yet have to design. This bar will contain all (yes all, I want to have the player to be easily able to see all important informations without having to open different windows or so) important information, though there will also be statistics and stuff you can access via an extra window. And to make the style fluent, that bar will look a lot like that control center in the shot above : simple but with style.

So much for now, stay tuned for the next update 😉

Refining the game design

Well, I’m still working at refining the design of my game project mentioned in my last entry. And since back then, alone the document in which I wrote down changes and additions to the initial gamedesign is already 10 pages long. So the ideas are flowing and everything is coming together. And this also is the first time that I ever invested so much time in writing a game-design document.
Up until now I usually just wrote down outlines of my idea and implemented the details while coding, which works fine for arcade-like games (see e.g. my Bomberman-clone or Terrorcide), but not for a more complex game-type like a roundbases-strategygame I’m working on right now. So when I’m finally finished with that document I can directly start to create content (graphics, 3D-models, etc.) and coding, without having to worry about implementing details of the gameplay.

And on another side-node : I started implementing a COLLADA-exporter into the NewtonPlayGround, after an internal discussion over at the Newton-SDK-Developer forum. Since this is an industry-wide format which also is open, it’s great for unified distribution of 3D-scenes, and when at least all SDK-developers support it, it would help users of Newton to load (and also find) scenes for their newton demos. But I myself don’t really like COLLADA very much, it’s so bloated and exporting even smaller scenes create huge files with dozens of nodes which makes writing an exporter very exhausting.

Back again

Well, after a bigger break I’m back at coding again (at least hobby-coding, already did some “serious” coding during the last months) and I have started to work on something new that’s actually rather old :
Back in 2003 I started on a roundbased strategy-game and wrote a rather big design document and also made a working prototype (but with no actual gameplay in it). But soon I realised that the design of this game was too complex (both in terms of gameplay and in terms of content I had to create), so I dropped it.
But some days ago I read through the old design document and decided to stream-line much of the gameplay and content, so that it’s more fun to play and that my chances of finishing it someday are much bigger than with the old concept. But for now I won’t reveal much more, except for this mysterious screenshot (click for some bigger view), maybe some people know at least a tiny bit about this project.

Stay tuned, I’ll have you updated on this. And I also plan (after finishing it) to do a write-up, where I also want to tell a bit about the process of streamlining my first game design to make it more interesting, as this is the first time I did such a thing with an older project of mine that I initially wanted to stop forever.