Bitcoin is an anonymous, virtual currency using a peer-to-peer network for transaction processing. As a system, it is also a marvel of cryptography and p2p tricks, so if this stuff turns you on, I strongly recommend reading the technical specification. Anyway, what really matters is that for processing the transactions the network nodes perform some cryptographic tricks that require significant amounts of computing power. Therefore to create incentive for hosting the nodes, the system has built in limited inflation that awards the newly created coins at random to processing nodes, roughly in proportion to their computing power. This is exactly what we need – an open-source system with small, easily distributable client code, whose work can be readily capitalized.

According to a FAQ on Bitcoin homepage it would take a modern PC a year to generate 50 Bitcoins with today’s selling price of 0.7 USD (although this is highly volatile), this gives us an estimate of 35 dollars for every computer-year of power that your network can gather. Now the amount of power is rather difficult to estimate and will depend on your install base and power gathering method. The Bitcoin system is still young and highly experimental, but it already allows you to directly purchase some stuff, most notably hosting services, but also t-shirts, some electronic gadgets and even coffee. See for yourself here. I, for one, will quite seriously consider adding Bitcoin-based CPUware donation system to my FOSS game when I finally make one – it will be interesting to see what kind of revenue can be generated that way.

First, a disclaimer – Bulletstorm is a big, single-player heavy, action game. If your game is different, the observations might not apply. Some observations are shaped by how Unreal Engine 3 works and might not be easily applicable to games created with other engines. Some might be difficult to apply due to technical limitations of an Open Source process – like having to exchange data through the Internet. Without any further ado, here goes.

Level design is paramount

It is pretty much impossible to overemphasize the importance of level design. Games live and die based on good or bad level design. It is the LDs that handle most of the smoke and mirrors of the modern game development. It is them who glue together the art and code and it is them who in practice implement large parts of the game design. Bad level design can fuck up everything and good level design can go a long way to cover shortages in other departments. I want to really emphasize this point, since I know that quite a few FOSS game projects focus heavily on code and art and treat level design as an afterthought.

Some examples. Performance – no matter how heavily you optimize your code, the LDs can still bring the game to a standstill if they put too much stuff in the level. On the other hand fitting the level into the limited memory on consoles almost completely depends on LDs smartly designing them so that they can be easily loaded and unloaded section by section as the player progresses through them. Art – in the early days we had few assets of our own and the LDs managed to put together half of the level using just some models of pipe segments. Generally level design is a lot like the top-level of the art in game, implementing things like visual language and proper composition. AI – 80% of “dumb AI” that you see in games is really LDs, not programmers fault. Game design – if you want to put a sniper rifle into the game you will need level designers to create areas with long shooting distances where it can be used and possibly some introductory level where players will be able to get used to it.

I think I will write a whole article with much more detailed examples of how everything in a game depends on good level design. For now you should just accept that it is incredibly important. Even if you are using randomly generated levels this also applies to you – pay attention to your generator as after the core gameplay loop it is the second most important thing in your game.

Level editor is probably the most important feature of the engine

After reading the previous section, I think it should come as no surprise that I think a good level editor, being the key to a good levels design, is extremely important. Not only for the LDs – the programmers and QA also benefit a lot from being able to easily create test and proof of concept maps. It is not only my sentiment – I have heard many people voice the opinion that good editor is the very reason why Unreal Engine 3 has become the industry standard for the action games.

Now, this is a shout out to all FOSS engine creators. Download Unreal Development Kit and see for yourself how Unreal Editor looks like. Editing text files and exporting from 3D modellers just does not cut it these days.

Search for the core gameplay loop

Core gameplay loop, called core combat loop in the case of FPS, is the kernel, the most inner part of the gameplay. It can stand on itself, independent of any other game elements, it is the part that the player will be repeating over and over again and all the other game elements will generally build upon and reinforce this foundation. In Bulletstorm the CGL is “disable enemy with a body move, finish him off in a crazy way with a weapon or another body move” and it includes the mechanics of movement, weapons and body moves (kick, slide, thumper, leash). In Gears of War it would be “take cover, take shots at enemies in the firing range, find another cover with better firing range, change cover” and it includes the mechanics of movement, weapons and taking cover. In Mount and Blade it is the melee weapons combat system. In Fallouts it would be the tactical combat and dialogue systems.

When designing a game it is crucial to identify its core gameplay loop as soon as possible – probably it should be the first thing you do after you stop patting yourself on the back because of how brilliant the idea is. Find what it is. Then ask yourself some questions about it. Have you really thought that part through? Does it sound fun and engaging? If not, what can be done to make it so? How is it different from CGLs of other, similar games? If it is not different, then how do you want to differentiate your game as a whole? How flexible is it? Take a notebook and try to sketch out some simple gameplay scenarios – essentially mini level designs. How many can you come up with? What are the risky (difficult to implement, possibly not fun) parts? How much work will it take to implement it?

It’s pretty obvious, so why do I make so much fuss about it? It is not uncommon, even in professional gamedev, to get all excited and carried away with the grand vision of all the possibilities of the game, how cool the world or story sounds and to completely forget about the essentials. And then at best you end up creating the CGL by accident – usually copying some sort of “industry standard” – and at worst you end up with interactive something with no real gameplay. I believe this is the most common in RPG projects – authors will write a lot about what great ideas they have for various game elements, but forget to fully specify the core gameplay (usually combat). Pretty good “big industry” examples of it are the latest games by Peter Molyneux – you can see he really gets off on giving bazillion possibilities to the player, but fails to base it on a basic gameplay that would be in any way remarkable.

As you are implementing the game, again your first goal should be to prototype your core gameplay loop. This does not mean you have to implement every single mechanics in it – for example if you plan to have ten different weapons in a shooter, you can implement only one or two – but you should implement enough of it to be able to answer all the above questions with practical examples. Why is it important? First of all, if you have CGL implemented, you have a game – perhaps not a deep or a complex one, but a game non the less. Without it, you just have an interactive something. Second of all, CGLs are sometimes tricky to get right – it may turn out that what looked good on paper is not fun to play when implemented – and you want that information ASAP, so you can either improve your mechanics, or ditch it altogether before you have invested a year worth of work into it. Third, once you have it, you can iterate over it, add features, experiment and stuff – you have the foundation. Aptness of every change that you make can be easily verified against the backdrop of the CGL. Fourth, level design is rather tricky if you can’t play test your levels with CGL. And, as already said, level design is paramount. If you don’t implement your CGL right away it may turn out that all the levels have to be redone once you do.

Tweaking will make any mechanics better

Whatever mechanics you create, it will have some parameters. Movement mechanics will typically have walking speed, strafing speed, turning rate, jump height and so on. The simplest machine gun shooting mechanics will have at least damage per shot, rate of fire, clip size, reload time, maximum ammo capacity and range. Programmers will frequently just pick some sane values and consider the task done. What you should realize is that there is an entire universe of possibilities hidden in those parameters. Enable tweaking them via configuration files, or even better, live during the game. Try out setting some extreme values and see how this affects gameplay, then you can find some interesting intermediate points. An example – consider what kind of gameplay challenge it would create if we tweaked the gun to have a high rate of fire, small clip size, long reload time and damage per shot tweaked in such a way that an enemy can be killed only when all the bullets in the clip hit him. Consider how would it change if we tweak the damage so that you need whole clip + 1 bullet.

Doing that type of parameter space analysis will not only make your mechanics better, but ultimately can even save you some work. Notice that all non-sniper, bullet based weapons in games like Call of Duty are, from code perspective, the same thing only with different parameters and visualisations. By simply adjusting the parameters you can create several weapons out of one, introduce character classes or RPG elements to your game, or create new game modes. Proper tweaking can make a boring mechanics challenging and a good mechanics brilliant. It is one of the secret sauces (others being polish and lack of bugs) that make the difference between great and good-but-it-lacks-something games.

This is all for now. In the second part I will focus more on technical aspects of game development.

WARNING: IF YOUR COMMENT IS NOT VISIBLE IT MEANS AKISMET SPAM FILTER ATE IT. I CHECK THE SPAM FOLDER TWICE A DAY AND WILL UNSPAM YOUR COMMENT AT THE NEAREST OCCASION.

What will change? The biggest change will be broadening the blog’s scope. Previous approach, that is focusing mostly on improving free software games development process, was too limiting and I simply did not always have ideas on the subject. So, what new topics can you expect to see on this blog? Here are a few ideas:

• game designs – sometimes I come up with game designs that I think are quite smart, but that I do not plan to turn into actual games – either because they would require way too much resources, or because despite being smart they just don’t turn me on; anyway, I will share those designs with you, to see what do you think about them, perhaps someone will have an idea how they can be further developed;
• game making philosophy – these will be my general ideas and opinions about creating games that are not strictly relevant only to Free Software games;
• technical ideas – I am a programmer, right? Sometimes I have ideas that are of strictly technical nature and to claim the “I thought about it first” award I will post them here;
• advice that I am not going to follow – so far I have followed the policy of publishing only those ideas about Free Software games that I was going to follow on my own; now I will also publish those, that for some reasons I am not going to follow – mainly due to some personal traits and conditions that make it difficult in my case;
• artistic creations – this will be the extension of the “Drawing for the Programmers” series, that will include stuff like 3D models, drawings, animations etc. – generally I want to show you that with proper attitude any programmer can rise above creating “programmer’s art” and become perhaps not a great, but a competent artist; for that purpose I am currently putting myself through the production process of some assets for a hypothetical game and I will show of the results as soon as I have them; I will probably share some general tips and tricks that I have gathered along the way as well;
• music – I am considered a good pianist by some; for a long time I have been pondering the idea  of recording some stuff and putting it on the net, so if I ever muster the courage to do it, I will obviously post it here too.

I haven’t yet decided whether I will engage in any FOSS game project. I suppose I will engage mostly in myself-directed, probably small, indie-style projects. I know this is a rather selfish approach, but unfortunately seeing that I am already implementing AAA commercial titles as my day job, “just” implementing a game is not going to cut it for a hobby – I need creative control to keep me interested.

I will probably drop PEG (Post-apocalyptic Economic Game) or put it in a freezer for now. It is a big project and I have been unable to isolate the minimal core gameplay mechanics that could be quickly implemented and that would sound fun to play. Or perhaps it has just been abandoned for too long and lost its “fresh” appeal. Or perhaps I am just not into economic games enough to create something like it.

I have a few ideas for new blog posts, but no backlog, so I can’t put up any schedule to when they will be published. I hope you will find them interesting once they are done.

Most people do not fully utilize the computing power of their machines. I do not have any statistics, but from anecdotal evidence I’d estimate that circa 80% of our time in front of computer is spend using little more than a web browser, or something equally computationally simple. And even if we do utilize our CPU the GPU usually sees even less use. Hence the idea – after playing the game we could present the player with a dialog requesting permission for running some sort of a distributed computation client. Something along the lines of “Did you know that you utilize less than 20% of your computer’s power? You can donate the remaining the remaining 80% to the game’s creators to help us make it better.”

The gathered computational power could be used in several ways. First of all, it could be sold. There is one service that tries to create a market for distributed computing power, however it does not seem to be functional anymore. Perhaps there will be more in the future.

Second possibility is using the power to create something you can monetize. Some ideas from the top of my head are rendering movies, running simulations, indexing and analyzing data sets. This model could be thought about in a following way: the enterprise has one income generating branch that depends on running some enormously complex computations but this branch is powered by the second one by releasing cpuware games. Think about distributed Google killer.

The last possibility is using the computing power to perform calculations directly aiding the development process. This is a bit troublesome, as unfortunately there are not that many game development tasks that can be eased using vast amounts of computing power. One possibility would again be rendering cut-scenes. Other would be the recent idea of using global illumination models for static lighting of 3D levels. Unfortunately I am not aware of any FOSS game projects making extensive use of any of these technologies. To take real advantage of that computing power we would probably have to invent new methods of software development. Two underutilized programming methods that come to mind are neural networks and genetic algorithms. I am not an expert on any of these, but I can imagine that instead of writing an AI by hand a programmer could create some tests checking whether it behaves correctly and send them to the cloud to train neural networks with. Or if the neural networks seem too radical, then genetic algorithms could be used to build FSMs exhibiting required behavior.

That’s all for now. If you have any ideas or want to ask questions please use the comments.

The system is very simple and this might just be its strength. Low flat fee makes joining the service a simple and possibly spontaneous decision. I hope that when faced with a question “is supporting the Internet creators, whose works I enjoy, worth drinking <a few drinks of your choice> a month less” at least some people will answer “yes”. I know this was the logic I used when I signed up for monthly donations to the Amnesty International a few years ago. The other end of the system is also beautifully simple – you just click the “flattr” button when you think something is worthy of your money. You don’t have to make any substantial financial decisions, as your monthly rate does not change, you only decide into how many parts you want to divide it (that is if you care).

Obviously there are many details to be handled – avoiding frauds, legal issues, the exact way the money is going to be shared or how to nudge people into making their monthly contributions high enough. But nonetheless the idea looks very promising. Once it goes out of the beta and is available in Poland, I will surely be one of the first subscribers – after all such a noble cause is worth drinking one bottle of wine a month less.

Also – I do not know if you have noticed, but Wikipedia has started a donation drive. Remembering how much inspiration Wikipedia’s example gave me and how much time daily I spend on Wikipedia, donating was an obvious thing to do. If you have some loose money and feel the same, please consider donating too. For those impulsive types there is a Wikipedia donation banner on the blog’s sidebar.

For the last 3 weeks or so I was polishing out a high concept document. This is a document that is supposed to present a vision of the game, perhaps describe a few unique ideas about it and not to detail the game design in every possible detail. Many mechanics that are quite certain to be included in the game (like some sort of a combat system) were not described. My main sources of inspiration during writing of the document were: Fallout RPGs (mainly the third part), Fallout Tactics, PARPG story design documents, Settlers II, Anno 1701, Dwarf Fortress and Majesty – The Fantasy Kingdom Sim.

I want to try out a new way of cooperating in the process of creating a document. For that I have published it through the co-ment service. It is a system for commenting a document very similar to stet – a tool used during the drafting of GPLv3 which I have happened to like a lot. To add a comment click on the “>>” button to show the sidebar, click on add tab and mark a part of the text that you would like to comment on. Registration should not be required. You can also read and comment the article directly on co-ment site.

Let me elaborate a bit more on the preproductions. What exactly is the preproduction and why is it so important? It is the experimenting stage of game production, when you try to figure out whether your game ideas are technically possible and how to make them entertaining. In commercial studios that stage typically consists of creating many proof of concept levels to check various features in isolation, as well as a “slice of gameplay” – an actual level taken from the middle of the game, that shows how all the features mix together and what will the final art, level design and plot look like. It is worth mentioning that during the preproduction game design can change drastically – one well known XBox 360 3rd person shooter, which title I shall not utter here for the fear of NDA, was initially supposed to be focused on vehicle combat but ended up focused on chest height walls. Nice makeover, eh?

How do the preproductions look like in the FOSS gamedev? If the game is a clone of a commercial product, than that product serves as a sort of a preproduction – it is typically a good game, so if it is copied faithfully enough, the clone will be good to. If the game is a “liberated” one, than it probably went through preproduction when it was still closed. But when it comes to original ideas being developed as FOSS from the ground up, I am afraid that frequently they just do not have any preproduction at all. For various reasons it is difficult to perform a preproduction within a FOSS project. For one thing, it requires throwing out or remaking features that do not fit in and this may be hard considering the constant shortage of manpower and the risk of offending contributors. Other problem is that a preproduction may give the impression of the project spinning in circles and make it more difficult to find them in the first place. But skipping the preproduction has serious consequences – the game will not be as fun as the commercial counterparts and it may be difficult to keep the project heading in the right direction, because that direction has not been established through experimentation in the first place.

Having described the problems, let me tell you now about Mister Philip K. Dick, because he might have known an answer to them. Since high school, he was one of my favorite writers and definitely the favorite SF writer. I own most of his books that have been published in Poland in the last decade – both novels and story collections. One interesting thing I have learned about Dick (pun not intended but inevitable) because of this collector-like passion is that most of the ideas that he has used in his novels have been first “test driven” in the form of stories. I do not know whether he has done it because he literally wanted to first test the them, or perhaps early in his carrier he had problems finding publishers for novels so he wrote the stories instead. Whatever the reason, that practice gave me an idea applicable to FOSS game development. A lone creator or a small team could, instead of trying to create a big game, create many small ones – one or two levels long, based on a single idea, with just enough story to set the mood, without tutorials, savegames and so on. Those would be the short stories and gameplay slices of the ideas. Some of them are not going to work out good, but that is expected and nothing to worry about. Some will and the players will let you know about it – those ideas you can refine and package into bigger games. Those would be the novels.

Such approach gives creators several advantages:

• they can try out much more ideas then they could when focusing on big productions only and still retain the option to turn the good ones into full scale projects;
• they will quickly gain “street cred” for delivering actually finished, albeit small, games;
• they get more objective judgment of the ideas then “gut feeling” can give;
• they may get feedback about how to improve the underperforming ideas;
• once they decide to put some ideas into a full blown game, the small games will fill the role of proofs of concept and gameplay slices, therefore becoming the preproduction stage;
• if they want to acquire donations or contributions it will be easier to find both if there are already many people who have played the “short story” version;
• they will have something to show off right from the beginning that will help to keep the project heading in the right direction.

I had a lot of difficulties fitting small games (that is smaller than episodic) into my view of how should the FOSS games be developed. Adopting the technique used by Philip K. Dick gives me the possibility to use them in a way that solves several other problems of FOSS game development. I hope others will find that aproach useful too.

And what do you think?