Preproductions in the style of Philip K. Dick
by m64 on Jun.02, 2009, under Possibilities
As an aspiring FOSS game creator I stand before some dilemmas and questions that I think may be common to other creators. One is that I have many game ideas – much more than I think I am able to turn into full game projects. Therefore I have to make some tough choices, which is hard without any other input than my gut feeling. Second, I feel there is a sort of unspoken premise of developing FOSS games – that you will be able to attract some contributors and make your games bigger then what you could ever do by yourself. But it is wiser to create small games, as big project require large initial investment before you will have a working product to show off and without that it is difficult to find contributors. Third, is the question of how to perform preproductions – without them it is rather hard to get the gameplay right, but they lengthen the project and move away the moment when you have something playable to show. I write about those questions today because I think I have found a possible answer and I would like to discuss it.
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?
June 2nd, 2009 on 5:26 pm
interesting concept. programming wise it would also encourage reusing existing code instead of starting a new engine from scratch for every minigame/level thingy.
architecture/team organisation wise it could also be valuable to try out different ways of organizing.
if you do try that please report your findings in detail, also the failed ones, we learn from mistakes as well after all =)
if you are interested in 3d rathen than 2d and can live with lua+ogre, i might be able to spare a bit of time. With the 3d-projects i’m involved in (iris and sfz) sharing the same little selfbuilt framework/lib thingy (lugre) enables me to set up small new projects very quickly.
June 2nd, 2009 on 5:30 pm
If you’re more into 2d, i could recommend taking a look at the löve engine. Again only if you can live with lua =)
June 2nd, 2009 on 8:29 pm
First of I am delighted to read a new post!
Very interesting idea you have, I would like to read an elaboration of what kind of mini/micro games it would be. I have a very vivid imagination so I may be far of in my interpretation.
June 3rd, 2009 on 11:04 am
First of all, you’ll start making the game alone or with very few people. This is not industry.
Best is to focus on making so-so playable “alpha” and later build features upon plugin-enabled engine. The crew will grow and self-(dis)organize over time (with bazaar-like cooperation models), so if your idea and alha product are good – you can have more helping hands over time.
This is, I believe, the FLOSS model of developing the game: finding/developing plugin-enabled engine and consequent building content and features upon it.
Selection of ideas is quite easy: if something similar is developed (like tones of roguelikes right now), you can put your work there, if there was no game like yours (it is still quite easy to invent such things!) before in FLOSS world – you just have to start from scratch.
June 3rd, 2009 on 5:44 pm
ghoulsblade:
Ability to experiment with different organization and implementation methods is another advantage, that I have not noticed, but which seems important. After all Brooks said “Plan to throw away one implementation – you will anyway”.
Certainly code reuse is desirable – both in the form of using existing engines, having some shared code and even borrowing code from other FOSS games.
q_X:
I know this is not the industry and that you will start with very few people. But I think we should copy from the game industry their best practices and one of them is performing the experimentation phase called preproduction. Doing a so-so playable alpha and adding features may be a good recipe for typical software but in my opinion it is a recipe for only a so-so game. And in FOSS conditions, I don’t know why anyone would want to help with creating a so-so game.
Example (for Tranberry):
I have this silly idea for a shooter where your primary weapon is shooting some sort of syringes that contain a cocktail of poisons and bacteria that a player can compose. The trick is that different enemies might react differently to different ingredients and so the player has to think hard about how to compose his cocktails.
There is a metric shitload of questions about how to implement such a game. How should the player know which ingredient is most effective against which foe – pure observation during combat or perhaps let him perform experiments on the corpses? If so, should the experiments be just one shot actions or perhaps they could incorporate some mini-game? Perhaps the syringe should be remote controlled and after hitting the player should have control over the administration of the ingredients? What kind of enemies would be best suited for that type of gameplay – powerful and solitary or weak but plentiful? How could that look in multiplayer? Can this idea be realized as a shooter at all? Perhaps it would be better as an RPG with pause or turn based combat, so the player has enough time to think about his actions? Perhaps the idea is completely bad and can’t be made into a fun game?
These are questions that can’t be competently answered without experimentation. What is more some of them are very hard to correct later down the road if we do not get them right from the start – for example the question whether it is worth implementing at all. How should we get around test-driving it? First I would take an existing FOSS shooter, like Sauerbraten. Remove all the weapons but one and rename it as syringe gun. Remove all the enemies but let’s say 2 kinds of them. Then I would implement a minimal version of the described system – with 4 or 5 possible ingredients (to simplify the interface and rules) and with just 2 enemy types to show how different cocktails have to be made for them. Some tweaks to the enemies’ parameters and AI will have to be made and a map to show off the idea. This should not take longer then one-two months.
Such prototype can be released to the public. Because we are openly stating that this is just an experiment no one should be mad about us using the Sauerbraten assets. We get feedback. We can change the parts player do not like and they may even have good ideas how to do this. We can try different options if players are willing to see them. If they and we finally decide it is great, then we can implement it into a bigger game. Finally if they do not like it at all, we can abandon it without devoting too much time towards it and go on to new ideas.
June 3rd, 2009 on 8:07 pm
After rereading my comment I think I should more thoroughly describe what are possible outcomes of such an experimental release.
1. Total success – after some modifications we can clearly see and players’ opinions confirm that the idea is really good and it has enough depth on its own to make an entire game about it. Thus we proceed with production.
2. Total flop – even after modifications the idea is not entertaining. We can abandon it in good conscience.
3. Partial success v. 1 – after a few reiterations it is clear that the weapon is fun to use in a shooter, but not enough to be used for a whole game. Fortunately enough we have already tested a few similar ideas and can combine them into a full game.
4. Partial success v. 2 – after reiterations it looks like the system would be great for a futuristic RPG. Unfortunately we do not have enough other tested ideas and we did not really want to make a RPG in the first place. We can propose the idea to an existing RPG project or leave it for now until we perhaps have a few other matching ideas.
June 4th, 2009 on 9:36 am
The idea of mixing poisons is really good feature
You know it’s too small to make game upon it. Just give a glance to the famous Vampire The Masquerade: Bloodlines or Planescape:Torment – the games are made with dozens of such ideas really good balanced (and I believe 30x more were rejected). You can contribute idea to the Biskup’s JADE (Adom’s author next project) or to Nethack (would be easy). Thomas will be interested.
Other way is to make with it one, really simple, thing – like the clone of Galaga or old good Commando – and have easy, but entertaining game where the idea of mixing oneself’s weapons of ingredients gathered on completed levels would be one of key features.
To take best what you can take, to mimic the industry – sure, but how *exactly*? I just don’t get it.
You’ll be never able to be better than The Witcher (Hitman, GTA, place what you want here). This kind of games *must* be managed, directed, team have to be made of ‘pro level’ people to make all textures, models, movies, music, levels and many other gamemakers. it takes few years even if all have full-time to work with it and engine is ready and running.
The only project reaching commercial level is (IMHO of course, and I don’t play too much) Wesnoth – wich is really simple game to do, but it took lots of effort to make all things stable and playable.
But let me explain as I see it.
I think only way when you have really limited resources, is to thinking things over and over again for years untill you feel “I can handle this, this is cool, genuine idea and people will like it”. And later make/find the plugin-enabled engine (so you can make full-featured Fallout or Xcom clone of your Nethack game if you wish simply connecting other display-receive plugin) and when the base it’s ready – have your game “preproduced” with it and bend it to your needs really easy. Adding simple plugin (and refactoring the contents of course) will easily change your Sauberraten-like FPS into some underwater labyrinth or racing (arkanoid, RPG – whatever) game. You just have to remember to have “batteries included” almost anywhere.
And how to implement it? Well, when the game will be in alpha, you’ll be far beyond it.
Look deep into the whole production thingy, not just at the time of the first prerelease, or demo.
My mind goes this way:
I have plenty of ideas, so I know: starting my particular project (unless it’s roguelike) is something like half year of work (no engine at start) to month (with engine I know well, and if some graphics and sounds are ready to take). If I have all the abilities and I know what I want (that’s a lie). All the things in the future will be affected with my (and others) further ideas, it would be nice for them to be easy-implementable as the plugins, not “rewriting whole ship… again”.
Let your hard work be playful.
June 4th, 2009 on 11:46 am
q_X:
Just for the record, I actually work at a commercial game studio and so I know exactly how much work does a commercial game require. And I know that at least for now we can’t afford such big productions.
I consider that thinking for years until you are certain your idea is perfect is not the good way to work, even with limited resources. Why? Because without doing actual experiments you are left to just gut feeling about what will be good. And one thing I have learned at the studio is that gut feeling is a bad adviser in that matters. Here you have a simple text that describes importance of preproduction in more detail:
http://gamecareerguide.com/features/745/how_a_game_gets_made_a_games_.php
Instead of thinking for years and years I could in that time spit out several such small prototypes. Some of them will have to be good and I will not that with certainty that comes from peer review. And those I can put together and turn into a full game, obviously not with a commercial-grade graphics.
Last thing is about starting with a so-so alpha and using a plugin based development. This is a good idea when thinking about software architecture, but not exactly when thinking about gameplay design. The difference is that typical applications get better the more features they have. Games on the other hand do not benefit from all features equally. Too many features can overwhelm the player or make the game too hard (or too easy). One feature can render other features useless. That is why although we can develop the features as plugins, we should have them well experimentally researched before going to production.
June 5th, 2009 on 1:19 am
Yes, me again.
Thanks for the link, was worth reading
Sure, You’re right, I won’t argue any more.
And sure, it’s all offtopic babbling.
I’m really closer to idea of thinking/preparing/coding the game as of writing a book, and playing as reading. So time based art rather than entertainment is my personal goal. I think this is where we’re totally different.
All this plugin ramble was to have a game near-ready, and still be empowered to change it in easy way with ideas crossing your mind over time. That’s all. Not to have glued golem of ideas, but good, smooth thing, where all pieces fit just right.
I think we both know it’s not the engine that makes good game better, but rather everything else.
Cheers
June 5th, 2009 on 7:12 pm
You left out the one of the most significant points – choosing the right tools for the job. For example, choosing C/SDL for prototyping is not so good anymore – C/C++ is not a very good language for prototyping and there are better tools available. The idea of rapid prototyping is successfully implemented and built upon in agile/xp environment btw.
Anyway – the more your chosen tools are suitable the more quickly you will build a prototype and the more it will be susceptible to consequent tweaks. From my experience I can recommend python with pygame library and haxe/flash. I wrote a small prototype game in pygame in around 30 minutes knowing almost nothing about the language except language reference and some tutorials (an almost complete game took a few evenings – it still lacks nice graphics and i’m too lazy to implement one). The biggest problem is that it generates 20mb packages with executables for people without python/pygame installed.
I tried javascript as a platform of choice – also nice speed of programming but huge execution speed problem (canvas solves these but aint available in IE which is bad), some compatibility issues with different browsers (you need some kind of library to manage it well).
As for haxe, it’s good and nice to program in. I don’t have a complete example ready yet but from what I’ve done in it it seems well suitable for rapid prototyping. What’s good about it is that flash is almost universally available so no big downloads – you can share your prototype with like-minded individuals very fast and start receiving feedback. People are also working on a haxe/cpp/sdl target so you potentially can build a native executable from exactly the same code.
There are some things which I labeled as problems which won’t be problems for everyone. The reason for these is that I always aim to make a complete game out of prototype without starting from a scratch.
I hope that information will be of some help
June 8th, 2009 on 11:09 am
q_X: Thanks for long discussion. Even if we do not completely agree about the goals and methods, the discussion always helps me to crystallize the ideas and to explain, at least to myself, how exactly are they different.
Max: I do agree that choosing right tools – not only programming tools – is very important for the project success. But I also think that good tools may be insufficient and that we need to somehow re-engineer the process of developing FOSS games and this is what I am mainly concerned with on this blog. Nevertheless you got me quite interested in Haxe – I have read about it some time ago and found it interesting, but I never really had the time to get to know it. Do you know if it has been used for games?
June 8th, 2009 on 3:41 pm
m64:
Yeah, I think it actually was written for games by a guy working for games development company Motion Twin. They use it for their online games and some other companies do, too. There are also a few game demos available.