The challenges of a game’s sound design

Posted on 10. May 2013 by Sascha Willems

Usually I’d add some nice screenshots to show off progress on “Phase 2“, but this time it’s an area of game development that’s pretty hard to show off in screenshots : Sound design.

I find this is one of the hardest parts as far as game design goes, at least for me. I do all the parts of game development on my own (design, code, content, etc.) but when it comes down to sound design, the result is usually so bad or bland that (I guess) most people just turn it off. I remember searching for and creating sounds for a shmup some years ago that took weeks, and when I heard the combined result of that effort running in-game I knew that I just had wasted a lot of time. It was just horrible. Though I don’t have any problems imagining how certain aspects of the game should look and feel, I usually don’t have a clue about “how” a game is actually supposed to sound.

As for the sound design for Projekt “W” – it’s pretty much non-existant. All the sounds in the current build are the same as on the first release of “Phase 1″, and these few sounds don’t add anything to the atmosphere and some of them (like the menu swoosh) are downright annoying. So during the last few weeks I played through some smaller indie games (mostly from IndieDB) and payed close attention to the sound design of these titles. I then quickly noticed that even a few simple GUI sounds can add a lot to the atmosphere of a game, and if you combine them with a fitting soundtrack (I’m still searching for new background tracks, more in the ambient vein) they quickly become a real bonus to the game’s atmosphere.

And since people think that the graphics are pretty good for a one-man hobby project I’d like to get the sound design to a similar level. So for the last few days I’ve been collecting and creating new samples for the user interface (with samples for actions, units, projects, etc. to follow) and even though I only changed and added half a dozen basic UI sounds (button clicks, menu transitions, confirmations, etc.) the sound design has already become a much closer fit for the game’s visuals.

So hopefully the new sound design (that’ll at least partially come with the next release) will add even more atmosphere to the game!

And since I’m sure that a few (hobby) game deves read this : How do you handle sound design? Do you have the same troubles, or is there any easy way to get this part of game design right?

Introducing the AI builder

Posted on 2. May 2013 by Sascha Willems

The next public release of “Phase 2” will include a new feature, the AI builder.

Managing your regions (constructing and upgrading buildings) becomes more and more tedious the longer a game has been going on, and once you own dozens of regions later on in the game that you’ll have to manage, this task gets very repetitive and takes up a lot of your time. And since monotony can do a lot of damage to the gameplay I decided to add the option to let the AI do the construction and or upgrades for your regions. And since most of that code was already in place (for the AI controlled nations), getting this feature into the game didn’t take to long.

So starting with the next public release (sorry, no ETA yet) you’ll be able to set up an AI builder for each of your regions with the following options :

Disabled
The default state. The AI builder won’t interact with that region and it’s up to the player to construct and upgrade buildings.
Constructing buildings
The AI builder will construct new buildings on free building spots. Once all buildings spots are occupied he’ll switch to passive mode and keep an eye on pollution and happiness in the region. If one of thess crucial factors reaches a dangerous low the AI builder will try to change the building layout of the region to e.g. counter high pollution levels.
Upgrade buildings
Upon ending a turn the AI builder will check if any of the buildings in it’s region can be upgraded to a better (newer) version. If that’s the case he’ll start constructing upgrades.
Construct and upgrade
The AI builder will first fill up all available buildings spots with suitable buildings (with priority towards economic power) and then start to uprade existing buildings.

This new feature will hopefully take out a lot of the repetitiveness in the later parts of the game, making it more fun to play. But note that the AI isn’t perfect and that it’s using predefined upgrade paths for the different building types, so if you need the best region layouts possible you’ll still have to do it on your own.

And one thing I’m still not sure about is wether I should implement some kind of penalty when the AI builder is active in a region. Maybe there’ll be a penalty on economic power, having the region output less funds per turn if the AI builder is enabled or something similar. And I’m also not sure yet on wether the AI builder will be available from the getgo or wether it’ll be implemented as a technology that you’ll have to research first before you can active it. What do you think?

Projekt “W” Phase 2 – New beta release (#170)

Posted on 7. April 2013 by Sascha Willems

It took much longer than initially expected, but here comes a new release of Phase 2, both for linux and windows :

(Windows) Projekt “W” – Phase 2 – Open Beta rev. #170 (~74 MBytes)
(Linux, i386) Projekt “W” – Phase 2 – Open Beta rev. #170 (~78 MBytes)

Selection of screenshots :

As hinted in my last postings this release includes the new space backdrops as well as the extensive ingame tutorial that’s aimed at both beginners, as well as experienced players that wan’t to know about the details. Due to the extensive nature of that tutorial (70 chapters, ~ 25,000 words in two languages) it took me almost 3 weeks to get it done, and I plan on adding some more chapters and details in the future.

I also changed some parts and visuals of the main menu, getting it more in line with the new space backdrops. And the new game screen now also shows the options on the nation selection screen, so no more clicking through two different screens for starting a new game.

Other than the above changes there were some bugfixes and small additions (e.g. correct display of special characters on Linux). You can find the changelog for revision #170 here.

Now with that release out of the door I can hopefully start to implement the last few missing features, add some more content and do some balancing, getting closer to a final release.

Implementing the ingame tutorial

Posted on 20. March 2013 by Sascha Willems

Now that the open beta of “Phase 2” has been downloaded a few times (with a 10:1 ratio between Windows and Linux) it seems that people like it. But one thing I’ve heard several times now was the lack of a tutorial. Since the game is pretty complex, especially compared to the current games, many people are finding it hard to get into the gameplay and actually win a game (I guess it’s the same thing I felt when I played my first matches of “Panzer General” almost 20 years ago).

So I started (re)implementing an interacitve ingame tutorial. “Phase 1″ had such a tutorial, but it was pretty basic and since so much changed for “Phase 2″ I decided to start from scratch. My plan is to have an ingame tutorial that teaches you all the important parts of the game so that you can hop in the game and win after working through the tutorial.

And as usual this turned out to take much much longer than expected. At first I hoped to get it done in a week (after my work), but I’m now in the third week and I’m roughly half-way through. The index of the tutorial contains 70 (!) chapters, and that number may grow while writing the content and scripts for the tutorial, and it already contains over 10,000 words for the tutorial texts (not including scripts and such for each tutorial step). And since I’m doing the tutorial (like the rest of the game) in two languages (german and english) it takes ages to get it done. I’m even spending my breaks at work to translate chapters from german to english to get it done.

Technically the tutorial is stored in an xml and divded into several main chapters with tutorial steps as their subchapters. Each subchapter contains a text and a subnode for commands that are executed when this tutorial step is started. These steps include opening up a window, changing the game’s view, highlighting UI elements, creating divisions, constructing buildings, etc. So the tutorial contains a very light-weight and simple scripting engine that allows it to be interactive instead of just text explaining stuff. I’m also thinking of expanding the tutorial so it can work as a contextual help too, so that you can e.g. open up the help on the tutorial window and you get the content and highlight from the corresponding tutorial step, which could be a nice addition for players not to keen with the gameplay.

So the next release of the game will finally (again) include an interactive ingame tutorial (which is much better than the external html manual), along the new space backdrops and some bugfixes. Though I don’t have a date for you yet, but my estimate would be “within the next two weeks”.

Redoing backdrops and tuning globe shaders

Posted on 4. March 2013 by Sascha Willems

The backdrops of the different nations have always annoyed me since I started to work on a 16:9 (and currently 16:10) widescreen display. When I created them way back for “Phase 1″, I made them with Corel’s Bryce (a pretty old version) and rendered them for 4:3 and 5:4 displays. And I always wanted to redo them since starting to work on “Phase 2“, which has been some time now, but never actually got around this and never had a clue what to do.

And after witnessing how bad they actually look on a big screen I decided it was time to replace them, and also to get rid of the water plane. Though the water plane was a nice visual gimmick with it’s shaders and reflections, it always felt unnatural to have the globe float above an infinte waterplane. And it also hindered gameplay somehow since it could obstruct the lower regions of the globe.

So along with the old nation backdrops I also removed the water plane and went with a gorgeous space skybox instead (I used this great open source tool to create the skybox). It feels far more natural to watch earth from space (though the nebulae around it is pure imagination and not near relity), with a backdrop that actually rotates with the globe (instead of the old static nation backdrops) and no oddly looking waterplane that the globe could be “dipped” into. Just take a look at the screenshot and you see what I’m talking about :

And if you take a close look at the globe you may notice that it looks a bit better than in the last release. That’s because I worked on the globe’s shaders to make it look more realistic, and also tuning colors and saturation of the different textures. Also note that I restored the old day/night-line that moves over the globe like in the real world again.

And along with tuning the visuals of the globe I also got rid of some fixed-function stuff that’s now done in the shader like the cloud cover. For years this has been an additional sphere that was just layered on top of the globe. I added that functionality to the globe shader (which is now using 6 different textures) giving a slight performance boost.

So what do you think of this new backdrop? I like it much more than the old ones, and it feels more natural. Note that I’ll try to get a video of the updated graphics up in the next few days, as it looks even better in motion.

It’s not completly finished yet (I quickly implemented the changes yesterday and this evening) and I want to add some dynamic objects to the scenery. E.g. a glowing sun in the far background as well as the moon circling above the earth. And yes, I even plan to use that moon as part of a global project

Projekt “W” – Phase 2 – First linux release!

Posted on 15. February 2013 by Sascha Willems

Believe it or not, but after a month of hard work (and only very little sleep), the first open beta release of “Phase 2” for linux (i386) is finally here!

Only a few small issues had to be fixed since my last posting about going multi-platform. No big deal, only a few visual glitches, missing staff images and (very annoying) a missing flood fill algorithm. I use flood fill to generate the colored territorial maps on each turn, and lazarus doesn’t implement this for the linux widget sets, so I had to write one on my own that isn’t slow as hell. And then I did some final game testing this afternoon and only found the game to be perfectly playable, so I decided to finally release the linux version.

Download :
(Linux, i386) Projekt “W” – Phase 2 – Open Beta rev. #142 (~65 MBytes)

Important : Please run the included “startprojektw.sh” script instead of the application itself as the game needs a certain library to be in the search path to run. If you run the application itself without libbass.so (which is what the script does), the game won’t launch!

Also note that I updated the windows release too :
(Windows) Projekt “W” – Phase 2 – Open Beta rev. #142 (~60 MBytes)

So if you’re a linux user and haven’t been able to play my latest game, you can now run it without using something like Wine. But please note that there may be bugs not present in the windows release, and that I only tested on one linux distribution, so I can’t tell about the other numerous distros out there. So if the game is running for you feel free to comment with your linux distribution so I can see where the game is running and where not.

Going multi-platform, part 5 : Finishing touches

Posted on 9. February 2013 by Sascha Willems

phase-2-linux After weeks of hard work and learning a lot about the differences between coding on windows and linux, the current source revision of Phase 2 is completly functional on linux and playing the same as a windows version. So if you’d put them side-by-side in fullscreen mode you wouldn’t notice any differences!

Currently I’m putting the finishing toches on the linux release and only a very few minor things have to be fixed and adjusted before I’ll release the linux version into the wild, so you guys can play with it and provide me with feedback, the linux world is far more fractured than the windows world, so I’d love to know how the game runs on different distributions.

Since the last posting I did the following for the linux source path of the game :

Switched to the BASS audio system
In my last posting I wrote about the problems finding an fmod linux library that would work with my game and free pascal. The problem here is that delphi/fpc support has long been dropped from fmod, and since a lot of declarations have changed, using the last delphi/fpc header with a recent fmod library wouldn’t work. So I switched over to BASS, a sound library that I already used several years ago. It still supports delphi/fpc, is leightweight, updated on a regular basis, free for non-commercial use and supports many platforms. You can get it from un4seen.
Since my different sound systems (fmod, OpenAL) are all abstracted via TSoundSystem and TMusicPlayer classes, adding in BASS only took me 15 minutes, so the game is now running on a different sound API and the linux version now also plays music and samples.

Added resolution selection / switchting
This was a lot harder than I intially thought. For windows this is pretty simple (as I’ve been using it for years), but for linux I had to do a lot of research before I started implementing it. In the end I went with xrandr and you can now change resolutions and windowed / full screen on linux like on windows.

Implemented performance fixes
I hinted at this in one of my recent postings. There are several performance differences between free pascal and delphi, so code that ran pretty fast on delphi made the game crawl on free pascal. One example was the transfer market. On delphi I had all texture names for all available staffer picutes in a stringlist and on drawing each staffer entry in the selection listbox, I looked up the texture ID of the staffer’s face via this stringlist. If that image was already loaded into VRAM I draw it, if not it get’s loaded from the virtual file system. On free pascal that code made the game go down below 10 fps when opening up the transfer market window. So now I load up all staffer pictures when loading the game (only takes a few ms) and directly assing the texture ID to a staffer. Sicne this is faster in general, this will also make the delphi version run faster.

So the linux version is looking fine, and I hope to have a public release ready within the next two weeks, so the linux crowd is finally able to play my game outside of wine or virtual machines. And though it was a hard piece of work (partially making me wonder if it was worth all the hours of coding) I think it was worth it as I learned a lot about coding on linux. So for my future projects I’ll take multi platform support into account from the very beginning.

Going multi-platform, part 4 : First run on a native linux

Posted on 3. February 2013 by Sascha Willems

After another week of intense coding on “Phase 2“, trying to fix the mistake I made with nativeXML, I finally got all of the xml stuff switched over to my own xmlwrapper. As hinted at in my last posting, nativeXML wasn’t working on linux (and I haven’t been unlocked for their support forums, after over a week of wait!) so I decided to write my own wrapper unit that uses fpc’s or delphi’s xml implementation, depending on the compiler target. Once again this was a huge code change (thousands of lines of code) but now all of the game’s unit have been changed to use this xmlwrapper, removing any references to external xml libraries.

So with that obstacle out of sight I decided it was time to install a real linux one of my partitions. The virtual machine was nice for getting the first version compile and run in linux, but developing in a VM is kinda cumbersome, especially as the OpenGL visuals don’t mirror a real system, so instead of trying to fix some awkward visual bugs (that are only visible in the VM) I made room on my external harddisk and installed linux (mint, same as in my VM) on a partition. So now I can also boot into a real linux with complete hardware acceleration and an OpenGL implementation that offers me the same extensions and performance as on my windows system. Installation itself went pretty easy, though I must admit that the linux system oddly isn’t nearly as stable as my good old Vista64. Debugging my game often hangs the complete system, requiring a hard reset, my USB ports aren’t powered down when shutting down linux (which is annoying, cause my lit keyboard is still on power after turning off my PC) and my wireless network drops out every few minuts. But well, just for developing and testing my game it’s fine, and that’s what I needed.

So here are the first screenshot of the game running on a native linux installation. I actually wanted to post a video, but finding a working screen capture application on linux (like fraps or camtasia for windows) was kinda impossible and made me waste half of my sunday. But anyway, here is the first bunch of screenshots showing the running natively on linux directyl from the lazarus IDE :

As you can see from the screenshots, performance is already pretty good (though it’s lacking in several areas, I guess due to compiler differences between fpc and delphi). But there is still a lot work to be done before I can release a linux build into the wild. As already said the soundsystem is currently disabled (because of the FMOD package version I need not available anymore), fullscreen mode along with getting resolution list is also missing, and timing is currently done via GetTickCount, which isn’t nearly as accurate as QueryPerformanceCounter for windows. And there seems to be a small encoding problem, wrongly displaying special chars like Umlauts (‘ü’,’ ä’, ‘ö’).

But yes, it’s fully playable and with only a bit more work I’ll finally have a working linux version of Projekt “W” – “Phase 2″!

Going multi-platform, part 3 : First throwback

Posted on 28. January 2013 by Sascha Willems

Last weekend I worked on getting the lazarus / free pascal build of “Phase 2” to look and play exactly the same as the delphi build. I had to change some small things here and there, but after a few hours you can now no longer distinguish between the two builds, maybe except for performance. It looks that some stuff that’s pretty fast with delphi is kinda slow with fpc, for example accessing stringlists and stuff. But that’s nothing that can’t be easily optimized, so the first goal of getting the different compiler builds on par is done. This also means that the game is fully playable under linux.

But during my playtestings on linux (I ditched my ubuntu installation with it’s horrible ubuntu one interface btw., and now use mint) I noticed that all descriptions of nations, units, technologies, etc. were missng, as well as the whole credits text. And after hours of debugging, checking encodings, creating test applications, etc. I found out that NativeXml is not able to load text contained within XML nodes on linux. So a node like this :

<unit name="test">
 <description>This is a test description</description>
</owner>

Will return an empty node value on Linux. No matter what I tried, accessing it directly, via the first childnode, etc. it was always empty. At first I thought I’d be doing it wrong (though it worked fine on windows), but then I did a very simple test that failed : I loaded up the XML with NativeXml and directly saved it to disk afterwards. And guess what? All texts within the xml nodes were removed by the library!

So it seems that I can’t use NativeXml for linux due to this severe bug. Their forums seem dead (registered there the weekend, but haven’t even been unlocked there so I couldn’t post the problem), and finding people that use it for linux is almost impossible. So all the thousands of lines of code I replaced to get the xml stuff to work on windows were just a waste of time, and I’ll have to remove this library again. I took a look at other xml libraries, but most either only supported delphi or were too bloated (dozens of units, huge source files, different dependencies, etc.). But well, that’s part of the learning process that makes programming so much fun (and sometimes so frustrating), and for the next external library I’m going to use (I prefer to write most of the stuff myself anyway) I’ll first check and see if it works on all my intented platforms.

And what now? Is the linux port in danger? No, rest assured, it’s not! Instead of relying on an external library for loading and saving xml I have written my own xmlwrapper that abstracts free pascal’s and delphi’s different xml interfaces into a single structure that I can use in my game (and coming projects). So now I load up an xml document via my own wrapper and compiler directives control wether delphi’s xml interface or free pascal’s DOM is used to fill this dynamic xml structure from the given file. The syntax is leaned towards the style of delphi’s xml implementation and parts of the game have already been changed to use my new xmlwrapper. So in my code it looks like this to get values from the xmlwrapper :

VFS.LoadXML('data\xml\nationinfo.xml', TmpXML);
for i := 0 to High(Nation) do
  begin
    Nation[i].History := TmpXML.Root.NodesByIndex[i].Nodes['history'].NodeValue;
    for j := 0 to LocalizationDB.LangID.Count-1 do
      Nation[i].Name[j] := TmpXML.Root.NodesByIndex[i].Attributes['name_'+LowerCase(LocalizationDB.LangID[j])].AsString;
   Nation[i].Stronghold := TmpXML.Root.NodesByIndex[i].Attributes['stronghold'].AsInteger;
   with TmpXML.Root.NodesByIndex[i].Nodes['basefactor'] do
     begin
       Nation[i].BaseFactor.Growth     := Attributes['growth'].AsSingle;
       Nation[i].BaseFactor.Loyality   := Attributes['loyality'].AsSingle;
       Nation[i].BaseFactor.Ressources := Attributes['ressources'].AsSingle;
       ...

So much for an open source xml library that was supposed to work with linux. So I guess this weekend will pretty much look like the second last one with me replacing lots of lines of xml-related code

Going multi-platform, part 2 : First compile and run

Posted on 21. January 2013 by Sascha Willems

I’ve been working to get the current code of “Phase 2” to compile and work under linux for the whole last weekend (and my eyes kinda hurt, again sitting in front of a monitor ). And things went much faster than I expected, so I was able to compile and run the game under linux for the very first time ever!

First step was to add code for all things that are specific to an operating system. So in addition to all the IFDEFs that differntiate between free pascal and Delphi, there are now also IFDEFs that differntiate beween windows and linux. Luckily MacOS and linux are pretty much the same when it comes to OS specific functions, so most of the IFDEFs for linux should also work there. This includes creation and management of the render context (WGL, GLX), getting the user’s home directory (to store logs, saves, screenshots, etc.) and much more. Currently there are still several functions missing from the linux version, e.g. getting a list of available screen resolutions and the possibility to change them via the settings like on windows. I also had to install an additional package for MESA (the software OpenGL implementation running in the VM) so it supports S3TC texture compression. That’s a must for the game cause almost all textures are stored as DDS and with compression.

Second step was debugging and stepping through the code. For some reasons it seems that there are small differences between FPC (2.6.) on windows and linux. For example I’m using a THashedStringList for getting texture indices by name from my texture manager. On Delphi this worked fine, whereas on linux I only got blank white quads. In the first place I thought that the OpenGL implementation in my VM wasn’t able to load the textures, but after some (unstable, gdb often lost trace) debugging I finally found out that the THashedStringList was case-sensitive by default, and setting this parameter to false oddly had no effect at all. So I just changed my texturemanager, it now inserts and compares with uppercase texture names all the time. Same goes for the localization database, which was suffering from the same problem.

In the third step I had to remove the sound system (for now). The game uses a rather old version of FMOD for it’s soundsystem, and though FMOD works with Delphi and FPC and also win, linux, macOS, they dropped Delphi/FPC-Support some time ago. And since I don’t have the last linux package version of FMOD that I used for the windows releae, I just couldn’t get it to work. I haven’t yet found that version anywhere (not even in FMODs archives), so I guess I’ll have to go for a different path on linux. I actually once wrote a soundsystem based on OpenAL, so I may take a look at it and use that one for linux.

After these steps I was finally able to compile, link and run the game under linux, for the very first time in the long development history of the game! Yeah, that’s kind of a historic milestone for me and was worth spending a whole weekend in front of the IDE.

As for a public release it’s still a way to go. First I need to get sound in again, some OS specific stuff is still missing and I also need to setup a real linux somewhere, as the VM is nice to test but I wanna see the release running on a real linux before I’ll spread it to the public.

But yes, linux support is finally coming, and with it maybe also a MacOS release somewhere in the future!