The only thing better than starting small is starting smaller
by m64 on Feb.18, 2009, under Possibilities
Hey there fellow free gamedevs. Sorry for the delay, but previous week at my studio culminated in a Friday all night crunch followed in my case by some really nasty flu and this did not help me write an article. The atmosphere around commundos has cooled down and it might be for the better as the flu has drained all my weekly enthusiasm reserves and some design decisions are difficult to make without it.
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.
- It would be easier to keep the excitement of the authors, contributors and players high with regular releases once a month or so.
- 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.
- This would make recruiting new project members easier too.
- 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.
- 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.
- “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.
- 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.
- 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.
February 18th, 2009 on 2:59 pm
Awesome as always, M, I even see this as fitting in pretty well with what I envision for the “system”..
A few questions and points I’d like to pose, though:
1. Episodic content works best when the engine or base code is already complete, something that is pretty rare in the foss world. Implementing new engine features over releases could work, but would require re-treading in ensuring that older “episodes” would work (unless different episodes are treated as different games, which brings in a new slew of problems, as instead of having to bug track a single game, you have to track that of many..)
2. Episodic games are all about story, weaving a tale, another thing that foss hasn’t really nailed yet. Writing up new content monthly is /way/ more labor intensive than just coding in a few features and fixes.
February 18th, 2009 on 4:05 pm
Ad. 1. I think code completion is not necessary – “Sam & Max” and other commercial episodic games come with a new executable for each episode, so it is possible that they have not only new content but also code. Bug tracking may be a problem, but I hope we will be able to sort that out somehow – don’t know how yet.
Ad. 2. It’s high time we start delivering story in our games too, so that’s not a problem. On the other hand would it be impossible to deliver a story-less episodic racing game, releasing a new track each month?
February 19th, 2009 on 12:07 am
Ad 1. – What the goat was trying to say is that the FOSS world doesn’t have ready-to-deploy engines, which you can instantly start developing a game which, which would be crucial for an ultraepisodical project, since it requires short development time and thus a reliable development pipeline, which, frankly, does not exist in the FOSS world, even after the release of the highly-anticipated but not so critically acclaimed Apricot project. I doubt that every ultraepisodical project would have a vast horde of skilled and experienced coders.
Other than that, I’d pretty much endorse this concept for quite a number of games out there! That is, if they’re focused on single-player content, what ultraepisodical cycling is perfect for.
February 19th, 2009 on 2:29 am
Well, I have misunderstood. I would not totally condemn all FOSS engines though, after all we have more engines than games – some of them have to be good enough.
I was also thinking about the idea that episodic games need a consistent story connecting the episodes. I am not sure this is necessary. Consider (again) “Sam & Max” – with 2 seasons and 11 episodes it is by far the most successful episodic game and it is a must play for anyone who wants to try going episodic. Its episodes are connected, but more by common locations and characters than by plot.
Also taking the analogy with webcomics further many of them (xkcd, wulffmorgenthaler) operate on a gag a strip basis and don’t bother with forming larger narratives. Others (Order of the Stick) start from the gag a strip system but develop into truly epic plots.
Also that is similar to a way many Polish low fantasy writers work (note – there is virtually no Polish high fantasy). First they write series of independent short stories featuring a certain character and roughly sketching the world. Only after having these sketches they start adding more “meat” introducing the world’s history, politics, religions, ecology, sociology and cosmology. I don’t know if this means anything to a non-Pole but that’s exactly how the Witcher universe was created. I think that if such a process could be replicated with an episodic game and a commundo this would make a smashing difference for FOSS games.
February 19th, 2009 on 11:00 am
Last paragraph: Kind of like Asimov did it… except his stories are more high fantasy
February 19th, 2009 on 12:43 pm
Well, I am not claiming this is unique to Polish fantasy, but that’s where I have seen this utilized most frequently. Perhaps “international” fantasy gets published in Poland only after it has reached the “trilogy” level and that is why I have not observed this process happening there.
February 20th, 2009 on 9:59 am
Great! short game webisodes sound nice, but how do you intent to deliver them? Are you trying something similar to Playdeb.net? Or do you want to make your own delivery/updating system?
February 20th, 2009 on 6:15 pm
I am not really trying anything yet. But I tend to lean towards the system where only some “loader” with perhaps some demo/tutorial level that does not change a lot would be distributed through distribution specific packages (to ensure dependencies are resolved). That loader should than be capable of downloading the new episodes on demand, possibly with their own binaries. Also sources and precompiled binaries will be available directly from the website. A RSS (or Atom?) feed and a mailing list, or possibly other broadcasting methods, like twitter and identi.ca, will be setup to notify players about new episodes.
February 20th, 2009 on 6:18 pm
I have some considerations about the 8th point of the post.
I think that the earning scheme for episodic FOSS games should be something more innovative than simple donations.
The donations should be used predominantly for the next episode, instead the whole game. The donor should be able to choose a specific scope where using the money during the donation. For example the choice could be between:
-focusing the next episode in a specific character
-using a specific graphic or music style in the next episode
-creating a longer story instead of improving the engine in the next episode
-correcting bugs of previous episodes
-no specific scope (general donation)
Connecting the donation to a specific aspect of the game the donor will have more power in the evolution of the next episodes and will be more satisfied to donate more.
The resetting of donation counter when a new episode is released and the constant cyclic release of the game could be useful things for earning money: the reset of the counter and the cyclic relase of the game could increase the donor perception that without his monetary help the game could finish without a new episode or that the new episode could be less funny that the previous ones.
Do you think this method could be realistic in FOSS episodic games?
Other interesting earning methods for FOSS project are also http://www.cofundos.org and http://www.micropledge.com/home
February 20th, 2009 on 10:04 pm
Cofundos seems like an awesome to fund and stimulate the development of FOSS middleware and gaming technology (game engines and their tools are mainly in my mind). If it comes to game projects though, you’re having only half of the picture in your mind. Programmers are only one part of the game development landscape
February 21st, 2009 on 12:14 am
MIX, I think something like that definitely could work. In fact some time ago I have proposed a bit similar model for monolithic games, that I have called “Donation adjusted schedule”, You can read the proposal at FGD forums http://forum.freegamedev.net/index.php?t=msg&th=2143&start=0&S=12b11bc88b20216bec060facb3edeb81
Your choice suggestions seem to be based largely around an idea of providing a story through a game. Not that there is anything wrong with this, but there are some more gameplay-specific choices that could be made available for the players depending on the game type. For example a racing game could have several track styles, apropriate to different racing styles and contest types. Players could be given a choice what kind of track should be developed next.
I do plan to write more about the business side of the FOSS gaming, but I just do not have any idea strong enough to present. I mean there are quite a few problems with successfully financing a FOSS game project and I feel much better when writing about possibilities than when listing problems – hence the name of the article series.
February 21st, 2009 on 1:04 pm
[...] The only thing better than starting small is starting smaller 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. [...]
February 22nd, 2009 on 12:10 pm
I came to somewhat close conclusions on FOSS games development a few weeks ago but with some differences in the end. You propose to make ultraepisodic games sharing same content/setting/art assets. I think there is also another good possibility – game authors can start with making ultrasmall games (casual size and style). Yes, development time is short but there’s also another bonus – you need very little art/sound/music to make the game feel good. So in essence it becomes much more feasible to just pay for the art instead of trying to find someone who would do it for free. I think they did so in Elephant’s Dream – they paid for quality voice-acting and soundtrack.
There’s an example – http://www.nitrome.com. They’re commercial and they’re not FOSS but they make a new flash game every week or so. The games are all pixel-art and mighty fun. How much does it cost to produce such a game? My guess it’s cheap and when you lower the quality of pixel-art a bit (theirs is top quality) it becomes dirt cheap.
Of course that way you either need some initial investments or try to implement some kind of donation model. I think I’ll try that sometime in the future – essentially I’ve got a pygame mini-game ready without the art I want (music and sounds are fine by me). So I’ll find out how much that stuff costs.
February 22nd, 2009 on 12:39 pm
While infidel has a point there – that is really a possibility how a programmer could realize his project -, what still bugs me is the question how non-programmers are supposed to realize their projects? If a game designer, work on the design and wait until a programmer is interested? If an artist, work out the art style and the universe and wait? Unlike in commercial development, there is no such thing as pitching a game idea in FLOSS game development (or is there? Maybe there’s a psychological pitching process going on ;P). My (somehow needless question) being: How can a non-programmer realize ‘ultrasmall’ games?
February 22nd, 2009 on 11:31 pm
Infidel, I think your idea also can be successful. In fact because you partially sidestep the content creation problem you might have an even larger chance of success.
Now the difference between our methods comes probably from differences in our goals. My goal is not only to crate a FOSS game, but to find some path FOSS games could follow to become more successful and ultimately comparable to commercial ones. That is why I don’t want to sidestep the content creation problem, but rather to take it head on and deal with it.
You are wondering about paying for the content. That is a valid approach if you have some spare money for the initial investment. On the other hand I feel FOSS programmers are unnecessarily demonizing content creation as something we can’t do. That’s something I was trying to address in “About the content and the electric guitars”. You should at least consider instead of investing in buying content, investing in learning to create the artwork yourself. You can buy some instruction books, artistic supplies and hardware, perhaps even find some plastic course to attend. As a side note this reminds me I need to draw something new for the “Drawing for the programmers” series.
February 23rd, 2009 on 12:57 am
Sindwiller, I am a programmer and so I have considered the whole thing from a programmers point of view. But honestly I think that due to over abundance of programmers in FOSS game scene an artist could possibly stand a better chance of forming an effective game team then a programmer.
How should an artist start a project? Well situation is pretty much symmetrical to what a programmer would. An artist should just start creating art for the game, defining its artistic style. When he has some artwork done for his project he should probably post a “help wanted” message FGD or other forum.
Now someone might say “but that’s not a game project yet, that’s just some artwork”!. But according to this, we probably should say to programmers looking for artists for their game projects “but that’s not a fantasy RPG, it’s a RPG about blocks!”. I mean that games are both art and code and frankly speaking it’s more art then code – starting your project from doing art is just as good as starting it from doing code.
Game designers are a quite different thing. That’s because designer has a game design document and not much else and we do get far too much “I have a great game idea, please make it for me” projects on the intertubes. Other problem is that in many cases the game design can’t be proved right without prototypes. In fact I will probably write an entire post about game design issues, as there are many misconceptions on the subject flying around.
February 23rd, 2009 on 12:59 am
One more thing – what do you mean “there’s no idea pitching in FOSS”? If so, what am I doing right now?
February 23rd, 2009 on 12:27 pm
I do plan to write more about the business side of the FOSS gaming, but I just do not have any idea strong enough to present. I mean there are quite a few problems with successfully financing a FOSS game project and I feel much better when writing about possibilities than when listing problems – hence the name of the article series.
February 23rd, 2009 on 1:15 pm
Well, I think everyone wishing to start a project needs to learn a little programming. Even if you won’t be able to make a game from scratch you’ll still be able to tune something in your ongoing project. And game designers particularly need to know something about programming because most of their design ideas have to be implemented at some point of time. Knowing about how stuff really works and how much it takes to make something tick is a tremendous help. Too many aspiring designers fall into the mistake of making huge unworkable designs. So IMHO in the end it boils down to two things – a set of available skills (designer, programmer, artist etc) and a set of realistically defined goals. Having ultrasmall games as projects at start hugely helps with both learning these skills and learning how to be realistic in development (management skill). The process itself is very much like an RPG/strategy game actually
> Now the difference between our methods comes probably from differences in our goals. My goal is not only to crate a FOSS game, but to find some path FOSS games could follow to become more successful and ultimately comparable to commercial ones. That is why I don’t want to sidestep the content creation problem, but rather to take it head on and deal with it.
I assure you that I have the same goal
It’s just the task of “create a FOSS game” comes before the task “create a successful FOSS game”. IMHO you should take steps one at a time. The thing is any FOSS project has to have significant value before people will start offering help so any project ultimately starts with one individual (or a very small group of closely-minded individuals).
February 23rd, 2009 on 7:23 pm
I think person wishing to start a game project should learn a little of everything – both programming and art. One lesson I’ve learned while working at a studio is that people with artistic background frequently notice things, important things, that programmers just don’t. And so enabling yourself to see that type of issues may be very valuable.
Problems with designers come frequently from some basic misconceptions about the game design process. For one thing, many fetishise game design document and think it has to be complete before the production starts. It’s just not true – in many (most?) commercial games GDD is not complete until the preproduction phase ends – precisely because an untested idea is next to worthless.
I am glad that we have the same goals. Now that I think of it I may have underestimated the potential of casual games. Although the goal is to make big games, perhaps casuals could also be means to an end. I will have to meditate about that.
February 24th, 2009 on 6:37 pm
I agree. I just agree.
February 24th, 2009 on 9:02 pm
No, no – I agree.