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?

Aside from that, I have added randomized favicons to blog and fought off a small wave of comment spam. Also I have started a thread I called Design Drills on FGD forums – the idea is to exercise our game design skills by collectively discussing some game idea without any plans or obligations to ever implement it. Unfortunately the thread is not getting too much interest, so if there is someone who reads my blog, but does not read FGD or have not noticed the thread, I would appreciate if you give me a hand with getting the discussion rolling.

Digression about settings

Before talking about the game desgins let’s make a small digression about the commundo universe. None has been selected yet, but there are three possibilities I am currently considering. One option is what TheAncientGoat has proposed once on the FGD forums – it is a sort of a mixed setting, mainly magical but with technological elements too. Its high level concept is that magic is an actual physical force/energy being harvested and stored in a form of a special substance. Second option, is me creating an universe of my own – it would probably be some sort of a historical (fiction) setting, as I think those are greatly underutilized in games. I also hope gathering informations about a specific time period would be easier than thinking out a complete new world by myself. Finally I have considered using an existing FOSS game setting – I have found the European post-apocalyptic world being constructed by the PARPG team to be pretty interesting. That option has the additional benefit that if I could talk mvBarracuda and other PARPG members into that form of cooperation between projects then we would have two games in a commundo right from the start.

Requirements

Let’s start with some requirements regarding the games. Because this is a first game in a commundo system it should meet several conditions:

• be relatively easy to program;
• not require a lot of artwork;
• artwork that it does require should be reusable in subsequent games;
• be dividable into episodes;
• familiarize the player with the shared world.

I have come up with three game ideas that meet those expectations in one way or another – other designs are certainly possible, but this is what first came to my mind.

Idea 1 – hazard

First idea was inspired by discussions here and on FGD forums about creating a mini game as a commundo starter and it is this idea that gave me the designers block. It has some obvious pros – mini games are relatively easy to program and compared with the mainstream titles do not require a lot of content. But there are several cons too. First of all the simplest mini games typically do not present any world to their players and if they do, they do it in a tongue in cheek manner (Puzzle Quest, Puzzle Pirates). Lack of seriousness is understandable considering that, for example, Tetris used in Puzzle Pirates to represent combat, does not physically resemble combat in any way and humor is the easiest way to help with that incoherence. Second problem is that artwork used by mini games is frequently quite specific to the game – cards or pawns may be useful for other mini games, but not that much for a shooter. On the other hand if we are going to have some cut-scenes or other type of narrative elements those would be reusable regardless of the genre. The last problem with mini games is that they may be difficult to divide into episodes. To get around these obstacles I have come up with several ideas:

• gameplay of the mini game should represent an actual gamble existing in the shared universe – that way there is no inconsistency between gameplay and what it represents; mind that a gamble does not have to be a classical card or board game – in a highly technical or magical setting the visualization can be quite free-form;
• for the episodes to make sense new gameplay elements should be constantly introduced – this can be done in several ways:
  • adding more and more rules in every episode – like in real life when someone is learning a new game he may ignore some more intricate rules in the beginning; this could be useful for a few first episodes that will effectively act as a tutorial;
  • adding “in house” rules that can be different for each episode and provide variations in the gameplay – asside from rules as such, this can also mean house specific cards, pawns or board modifications;
  • adding a possibility to cheat during the game, letting the player use different cheats in subsequent episodes or making him defend himself against cheats used by enemies – that way we build a meta game of cheating based upon the “official” game;
  • creating something like chess puzzles – complex gameplay situations that the player has to bring to a desired resolution;
• the protagonist is a gambler and a cardsharp – that way we explain why gambling plays such a big role in his/her life and we can show his history from the perspective of the games he/she has played;
• introductory cut-scenes (or cut-comics, or even cut-texts) can be used to present a story and a world vision to the player.

Ok, so this is the first idea. The problem with it that I have not mentioned is that I have never been a great card or chess player or had any interest in gambling and so I am quite clueless about how to design such a game. I also have some doubts about how much variation can be extracted from such a design to justify making it episodic.

Idea 2 – puzzlification

Second idea is to create a puzzle game that has a strong emphasis on level design and presents a bit abstracted physical activity. Best known games of that type would be Lemmings, Lost Vikings, Goblins or Commandos. Another big inspiration when considering this idea was the series of Deadly Rooms of Death (DROD) games by Caravel Games. DROD is a puzzlified hack’n’slash – it is played in turns, rules and AI are deterministic and it requires a lot of careful planning on the part of the player. What is important about DROD is that while the other examples may require significant amount of animations, DROD manages to create a compelling gameplay with very minimal assets – no animations, sprites made of rotated versions of a single image and so on. Surprisingly this looks much more acceptable then it could be expected, in large part thanks to the turn based gameplay. I think applying a similar puzzlification method to another game type, for example a stealth-based squad-level wargame like the Commandos, could be very interesting. The pros of such solution are that the player’s actions are much more physical and so gameplay easily lends itself to telling stories and presenting the game world. Also the division into episodes is quite straightforward. The coding and artistic effort required by such game would be higher than with idea 1, but also many of the in game assets could be reused in other games.

Idea 3 – strategy

As I have already mentioned in the previous section, the turn based gameplay of DROD greatly reduces the asset requirements. And if we are talking about turns then we have to mention strategies. In fact the idea of using turn based gameplay to reduce the asset requirements first came into my mind when I realised that such an otherwise technically advanced game like Panzer General 2 used virtually no animations at all, asside from a few generic explosions. And it is not only a case of PG2 – many modern turn based strategies even if they use animations, still offer the option of disabling them – advanced players prefer it that way, because it makes the gameplay faster and the presentation less distracting. This leads to a conclusion that a “hardcore” turn based strategic or tactical game could also be a viable option for a commundo starter. The biggest advantage of a strategic game as a commundo starter would be its great potential for world presentation. Strategic games are perfect for showing the geography, politics, history and other world features. I have noticed that a few well known universes started out as strategic games, like World of Warcraft and Warhammer – this is a strong indicator of the world-building potential of this genre. The big cons is that even if the content requirements are comparable to idea 2, this is still the most ambitious design, requiring significant amount of coding work including a serious AI system. An advantage is that most in-game assets could potentially be reused in other types of games. Also, in a similar way to idea 2, it is obvious how to divide the game into episodes. Last but not least, I like strategic games, so designing one would be quite fun for me.

Comparison

To conclude the post let’s do a little comparison of those three ideas. I have presented them in the order of complexity. Now what we get in exchange for that complexity is suitability for building and presenting a world. First idea is quite cumbersome at that, as the world vision is not being presented during gameplay and has to be delivered through cut-scenes. The second idea is significantly better as the player is supposed to see some world visualization. Finally the third idea has large amounts of world wisdom naturally embedded in the gameplay and so it is able to deliver a lot of it without boring the hell out of the player. Also starting with a game of a more strategic scope lends itself to the top-down approach to world building – for such a game it is important to know how far is village A from city B, but it is irrelevant whether a policeman in the said village is a moron.

Now there are certainly some other possibilities I have not mentioned or thought about, like an economic game in the OGame style, but from the three presented options the second and third sound most promising to me – I think the additional world presentation capabilities they offer are worth the extra effort they require. The third option – the strategy – is a bit scary to me because of the need to develop a sensible AI, which is something I would not even know where to begin. So, unless I gain a sudden insight into the strategic AI design or someone willing to do it for me, it might be better to stick with the safer second option. And with that half baked conclusion I end this post and as always ask you, my readers for comments.

Today I want to talk about another idea for improving open source game development process. It is not exactly tied to commundo, but I think the two ideas can reinforce each other so I would like to employ it to start the first commundo. Sharing a world is a way of cooperation between several game projects. Therefore it cannot function properly without an actual game(s) participating in it and pushing its adoption. Now a shared world  is most useful for commercial style non-casual games that actually have the ability to present worlds to its players.

Commercial style games are big and complex almost by definition and so they will take a lot of time to implement. We don’t have that much time. We also refuse to make simple games instead (casual… meh). The only other option is to make the games small. Or even smaller. Therefore I would like to propose ultraepisodic games. Ultraepisodic games would work a lot like normal commercial episodic games, for example “Sam & Max”, only more episodic – each episode should be prepared and released within a month or even less, adding perhaps some additional preparation time before new seasons. Because teams working on FOSS games are much smaller than their commercial counterparts the episodes would also be much smaller, on the scale of a single level – hence the term ultraepisodic. I also think it would be benefiting to be able to make the new episodes even more frequently than the commercial games do – with a dedicated team, established world lore and asset repository two week time frame may be possible. To put the long story short, if the commercial episodic games are like comic books, then ultraepisodic games should be like webcomics.

The idea of episodic gaming is nothing new. The important thing is to analyze how episodic or ultraepisodic release model would benefit the FOSS games and commundos. In my opinion such approach would have numerous benefits.

1. It would be easier to keep the excitement of the authors, contributors and players high with regular releases once a month or so.
2. Players are more interested in content than in code. By making the game explicitly episodic and making episodes synonymous with releases we give them a reason to check out the new releases.
3. This would make recruiting new project members easier too.
4. Ultraepisodic games will be divided into short parts by definition. That way we sidestep many problems present in full-scale games – technological limitations, team management, huge upfront design effort etc.
5. Those people who “just can’t wait” for the next episode can be informed how to get the development version and are potential testers and contributors.
6. “Release early, release often” – episodes let us get early feedback about which features are fun, which are not and which were not even noticed – this makes it easier to prioritize our work and change things that are not as cool as we have imagined.
7. If the system is used within a commundo the first episodes can possibly inspire others to join it and create their own similar games within it. You can think of that as a sort of a “fan art”, or “user created content”. That way the later episodes can benefit from these new contributions – the monolithic game would not have that chance.
8. If the ultraepisodic games would work like a webcomics, than they could employ several established web comic earning schemes – including swag selling, donation drives, banner ads, paid membership with exclusive content and possibly a few others.

OK, so that’s probably all the pros I can think of. There are some cons, like not every game can be easily broken into episodes (like sports games) or some players may not like to play the game only a little bit at a time (but others may like it better, also season compilations can be made). I must admit I am not very good at coming up with cons when I feel excited about something. Hey, I feel excited again! That means I can resume my quest for Open Source gaming revolution once more!

As always I would very much like to hear what do you think about the idea, so please comment.