Ultra Fickle Overtones

UFO:AI

There's beta installers for Linux and Windows for the popular open source game UFO:AI. The changelog for version 2.2 is impressive. The download link is a bit hard to get to - a ploy to stop too many players mistakenly downloading the beta when they didn't realise it might have bugs. Anyway, grab it here, and help them make UFO:AI 2.2 a great release. :-)

There was an interesting comment on the observation I made regarding the version number of LordsAWar:

0.0.3 for the lordsawar version doesn't mean 3% done. The game has most aspects of Warlords 2 implemented, where as freelords only has a few.

Well why version 0.0.3 then? Ok, I admit, version numbers are probably one of the least important aspects of game design. But, come on, really, if your game has lots of features and close to what you consider "1.0" for your game, then label is as such. People who are casually looking for a game to play will see 0.0.3 and think, "not even alpha." They won't play it. Players are fickle like that.

Version numbers imply the amount of progress towards the author's vision of the game. To me, 1.0 is the original vision and past that are evolutions of that vision.

JCRPG

Speaking of vision, I'll also give a quick mention to JCRPG whose author seems to be relentless in his efforts to bring a quality classic RPG framework with all the modern trimmings. Some of his trees are not to far off being life-like in quality. If somebody had the drive to start making a game based on his work so far, thereby pushing things even further, we could see some amazingly atmospheric games.

My brother alluded to an interesting point when commenting on the state of modern gaming. FPS games are monotonous, they are rarely atmospheric. It's just the same sprint shoot sprint cycle except with different weapons and backdrops. The gaming genre has become boring as the limitations of games have eroded away. Complete freedom to move often has the undesired consequence of making the world less interesting as there is no longer a challenge to navigating it - just find the next gap and run through it, all guns blazing. CRPGs used to be mazey, claustrophoic ordeals where you constantly had to plan to avoid getting into too many consecutive battles as monsters were quite fatal. The game worlds were not massive, but they were hard. The gaming industry seems to have forgotten that an enclosed but well defined world is more intriguing than a a massive open one which just looks pretty and has no substance.

Maybe I'm wrong, I haven't played many commercial games in the last 5 or 6 years, but when I have it reinfoces the above feeling. Just a thought.

Debunking reasons not to open source indie freeware games

There are many significant indie game projects that are committed to creating a quality free game where the developers are afraid of the consequences of making the development public by publishing the project under an open source license.

Now I'm not saying that open source is the only way people should choose to release their indie games - different situations do need to be evaluated on the merit of the benefits brought by being open source - but frequently, when asked, the reasons for declining to open source a project are usually bogus.

One of the problems is that the topic of open source is a polarized subject - people are either strongly against it or strongly for it. Those falling into the latter category are almost always experienced with using and/or developing open source software, and in my experience those against open sourcing of their projects often do not fully understand the concept, do not appreciate the benefits it brings, and suffer irrational fears of what might befall their project should they license it as Free Software.

Over the years I've tried to change the minds of several game project developers, usually met with stubborn resistance. Hopefully this article can help projects earlier on in their development cycle before people have committed themselves to keeping their free game project as a closed source one.

Frequently cited reasons for keeping a game project closed source:

• People will cheat


• The code is a mess


• Control of the project will be lost


• Somebody will steal my/our game


• The game will be spoilt (i.e. we don't want to reveal the story)

People will cheat

True, there will always be those who try to cheat at any popular game. However do you think security through obscurity will prevent this? If anything, it is worse; the project may be less secure because the design and implementation are not under scrutiny. You are better to open it up early so people can point out the flaws and they can be addressed early - to change a design or implementation in a mature project is far more difficult and the subsequent upheaval will upset many players.

The code is a mess

I've seen this one countless times: "I want to open source my project but the code is a mess, so I'll wait until I clean up the code."

I've also seen this one many times: "My [piece of hardware] died and I lost everything :'(."

And this one:

That last one was silence. People often get distracted by real life and disappear. An exciting looking set of screenshots become vapourware and onlookers get frustrated.

Nobody writes perfect code or the perfect design the first time, even seasoned pros. Nobody cares if you have hacks or the code is a mess. They do care if you release a fun game. Guess what, if your project is open source and attracting interest, somebody may even rewrite parts of it for you. If you suffer a hardware failure or find something else that takes you away from your project or the Internet, or you even die (it happens!) then you have left a legacy that others may continue.

Control of the project will be lost

Ok, if you are an asshole this is probably a valid point. Abrasive people will upset others, beyond the point of redemption. So all you obnoxious and inconsiderate baffoons have me here, I can't debunk this for you. In which case loss of control of a project may be an indication that you should correct your ways? A blessing in disguise! However, for decent people ;-) it is a myth...

Control of the project remains in the hands of the contributors. Sure, if you stop and people continue your work you may lose control but then you are no longer working on it? If you get re-involved in the project you will find developers receptive. Otherwise you keep as much control over your game as you allow others to have (you don't have to let everybody have commit access or admin rights) and almost always contributors are very, very respectful of the original author.

As long as you work on your project, you will have significant influence. Exchanging direct control for influence is almost always going to be a healthy trade off. You will find more developers means better design decisions, better implementations. Although implicitly you lose complete control, you will still be directing the efforts of others. After all, the original game was your vision so people will listen by virtue of that alone.

If there is a rift so deep between contributors that a fork is created, the fork will be a different game, and you will be remembered for giving birth to the concept of this different game should your own project subsequently stagnate. In reality there are few forks, especially of open source games. Other than situations where development of the original game has all but completely stopped before the fork, or the fork has the blessing of the original author, I can't think of any bitter forks off the top of my head. TuxKart and SuperTuxKart maybe? When was the last TuxKart release? Are the games as similar as the names? :-)

Somebody will steal my/our game

People can't get away with stealing a project. I've seen a few cases with applications and usually the community backlash and lobbying shuts down the violators. I just can't see a commercial game company getting away with ripping an open source game. Not only will it be an open-shut legal case should it go that far, you'll have a large pool of support from a vast community of open source advocates. To be honest, I bet there'd be lawyers who'd even take on the case pro bono for you.

If it's not a commercial violation, then it'll be a fork of the game. Developing an open source game is not easy. It's a long hard slug. Forks only occur in extreme circumstances:

1. There is an impasse between key contributors in desires for project direction. The games will be different. You still were the original author(s) and still will be credited for your work as long as you were not a total asshole.


2. Your project stagnated. Isn't a fork and continuation of your work better than it bitrotting and decaying into a part of Internet history?

Ok, some of your artwork and media may make it into other open source games, but isn't that a compliment? Are you not pleased that your efforts have made the world a more fun place by contributing to another game? Hell, you can put it on your CV, that your work is in projects X and Y because it is that good.

The game will be spoilt (i.e. we don't want to reveal the story)

For a complete game, the majority of players will not go to the kind of lengths necessary to have the game spoilt for them (i.e. look at the code or research the story).

Some people will play the game early in development but they form the community that tests and contributes to the game. Somebody has to know things early, and the fewer that do, the fewer can make the project happen. The more people contribute to your game, the better it will be. Sure, a few people will not get the opportunity to enjoy a fresh experience with the final game, but they got to experience it develop, which is a different kind of enjoyment. And the rest of the world will get a better game because of the extra input.

Also people do not have immutable memory. If I play a game again after years of not playing it, I do not remember everything. It is ridiculous to be worried that people who try the game in it's early stages will have their experience ruined should they return later once the game is ready.

Afterword

There are freeware game projects where there is significant momentum and organization behind them. The benefits of making such projects open source are often not immediately that significant. However frequently these projects lose that momentum, a community that has existed on propaganda and screenshots gets frustrated and in the end the project actually upsets more people than it brings enjoyment to - you had the opposite effect! Games are supposed to please people!

If the project is open, the community can rally should problems be encountered, and the chances of your game making it become far higher than if nobody has access to your work.

If momentum is never lost, the extra contributions, the extra eyes and testing to remove bugs, the extra demand for porting to other operating systems will all benefit your project. There may be administrative hassle (forums etc) but almost always for decent projects volunteers will take that on for you. The community is a resource and open source projects can and should use their communities. Freeware titles just can not do that.

Make the smart decision, open source your freeware game. There is a good reason that those experienced with open source strongly advocate it's application. It works. It's not a miracle cure for a dying project though, so don't wait until you have already lost your way, strike whilst the iron is hot. It is never too early to open source your freeware game project!

Freeciv Beta + Mania Drive Update

There's been an update to Mania Drive. This one introduces a beginners storyline, which is a welcome addition to any non-expert drivers given the difficulty of the previous release! Lots of bug fixes, lots of new levels, and this game is definitely now one of the leading Free Software driving games available.

Also of note is the 2.1-beta2 release of Freeciv. I checked out the SDL version and it is really looking nice. However, the term "beta" means beta. The release is laden with bugs. Loading it up, the "Start New Game" option is disabled. After manually starting and connecting to a localhost server, the "Server Settings" button was impotent. Still, I remembered "set aifill=6" to give me some opposition although I couldn't work out how to make them tougher (and was too lazy to google) so played on easy AI.

I'll start by saying that they really need to review most of the UI - it is a usability nightmare. Everything is iconized making most actions guesswork until you gain any familiarity. The icons are very small, making them awkward to hit with the mouse. It's little things like the options icon being in the top left corner but not being at the edge making it far harder to spot and hit than it should be. It's like the Windows 98 start button all over again.

A simple tip for the devs - the tooltips are too slow, making them more frustrating than helpful. In fact, I'd forget tooltips for the little buttons and instead have a region above the buttons where it immediately displays the name of the button under the cursor:

The city dialogs are dreadful. They need rethinking from the ground up. I only got anywhere by guesswork - the unit queuing mechanism is completely unintuitive. Make it drag and drop, please. Also it would be really nice to have preset queues since I often make the same 4-5 entries in the build queue for each new city.

Also, why the devil are the science, revolution, and tax buttons located on the unit display in the bottom right? Group things together sensibly! Don't stick things somewhere for symmetry even though they do not belong there.

Also I think it's time to realise that moving the entire view for automatically moving units is 1) disorientating 2) annoying and 3) distracting. Either reset the view back to where it was before the automatic unit movement [since that's where I wanted to be] or making a sub-window (transport tycoon style) showing the currently active unit. Here's a mockup, with a few other peeves highlighted:

One of the most annoying problems was the UI moving the mouse cursor - often it was impossible to select units or cities because moving the mouse over them made it jump somewhere else.

Another glaring problem is the one highlighted in a previous blog on Freeciv - the lack of notifications to speed up multiplayer games really impacts single player games. I built two wonders but was never told about it - I only found out by spotting one city building city walls (I never do) and another on coinage.

I could go on [this all came from only 30 minutes of play] but, like I originally pointed out, this is a beta. If you want something reliable then stick with Freeciv 2.0.x for now. However, this is shaping up as a very nice game with good graphics that make Freeciv 2.0.x/1.x look incredibly dated. I look forward to the final 2.1 release although I don't expect it in 2006 on the evidence of this beta.

VDrift - More Cars & Tracks

There's a significant update to VDrift, the open source drift racing game. Now it has a decent selection of cars and tracks, 19 and 12 respectively, to play on and development seems to be picking up pace. This is an excellent game and I urge any people interested in racing games to get involved. With a bit of community dedication this could be turned into a really polished commercial quality racing game.

At the moment they are looking for people to post screenshots. There is only a binary for Linux of the latest release but I'm sure other platforms will follow sooner rather than later.

Loose Cannon is a 3d Gauntlet-style post modern shoot-em-up. The previous release (0.4) was promising but shaky. I'll have to see what this update is like.

I see Eternal Lands has had an update too. I've known about this update for a couple of weeks, just forgot to post about it. Still, I'm not an EL fan. I don't really understand what motivates people to play a game where the main focus is on harvesting - that is, your character sat down with numbers occasionally popping up over their heads representing improvements or gained goods. Still, I have a friend addicted to EL so it can't be that bad, it's just not for me.

I was quite interested to see Dune Legacy make an appearance on the Linux Game Tome. I remember playing Dune II back in 1992 and really enjoying it's gameplay. I then remember playing Command and Conquer and noticing how they'd improved the graphics but the gameplay was always essentially the same.

Then, eight years later, out came Dune 2000. It still had identical gameplay to Dune II, right down to some of the real playability bugs (units not always defending themselves, especially if you accidentally set them shooting the floor - they'll craterise the landscape whilst being picked off by weaker enemies) just it had pretty 3D graphics. I was disgusted. Now I see references to it being a remake of Dune II, but at the time I remember otherwise and recall an interview with the lead developer describing how innovative they were being.

It's always great to see game innovation and Dune II was amazing for it's time. It's always dismaying to see a company like Westwood then become so unoriginal. It's like they sacked all the people with decent ideas. One of the great things about Free games is you don't see people sinking into a wash-rinse-repeat development schedule pumping out meaningless titles that stick to the same formula after a decade. Unconstrained by commercial handcuffs where the priority is the money and not the game, people work on what they believe makes a good game.

Are recent C&C releases still as pathetic? Still based on gameplay that hasn't really changed since 1992?

Know your market - OPTIMISE!

Going back to Yoda Soccer, I had earlier talked about performance issues on my 1ghz laptop. Upon reporting the problem, I had this response:

This is likely because the game requires a graphics card with 64MB of video ram.

Let me get this straight. A remake of Sensible Soccer - a game that ran on the Amiga 500, an Atari ST, the SEGA Mega Drive, and a 486 PC - requires a 64mb graphics card? That is ludicrous.

If you are making an open source game, know your market. Your market is typically not people with high-end graphics cards. If anything, it's people with older PCs who have less cash who do not want to invest in an uber-PC to play games. Of course, you have the ideological few who purchase a Cray to play Supertux, but they are the minority.

So, with your market in mind, and knowing the kind of graphical and computing intensity your game requires, an open source developer should not be satisfied with something that performs badly.

Optimise, and optimise early.

Why optimise early?

• Your game will be respected more by players if it performs well, regardless of how complete it is
  
• More people will come to play your game and spread the word about it
  
• You will understand the underlying architecture of your codebase better if you focus on refining it
  
• Your codebase will become cleaner as you work on optimising it
  
• You will naturally eradicate bugs and improve user experience during the course of optimisation
• You'll become a better programmer through learning while optimising code
  
• Future development of your game, by yourself or by attracting new developers, will be easier because of the above reasons
  

Is your game slower than it should be? Why are you waiting? Stop feature creeping and start making it faster and smoother. A simple game that plays well is better than a complex game that barely works. Of course, the pragmatic position lies somewhere between those two extremes but err on the side of the former because that is what will impress people the most. It will also help keep you motivated because of the reasons I have mentioned.

Certainly, requiring a 64mb video card for a game that was written on 15 year old hardware is outrageous. Perhaps it is because they use BlitzMax, but surely BlitzMax can't be that inefficient. Hopefully in the future the Yoda Soccer developers will consider porting away from BlitzMax so this game can be enjoyed by those of us who are not using fast machines.