How to Write a Game: The Wesnothian Approach

Discuss the development of other free/open-source games, as well as other games in general.

Moderator: Forum Moderators

Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

How to Write a Game: The Wesnothian Approach

Post by Dave »

How to Write a FLOSS Game: The Wesnoth Approach

Part 1: Getting Your Project Off the Ground

Now that I'm 84% of the way, according to a simplistic reading of our versioning convention, to leading a FLOSS game project from inception to completion of a first major version, I've decided to write this essay on the Wesnothian approach to writing a FLOSS game.

As with the writing of Wesnoth, a large portion of the reason for writing this essay is self-serving: since it is likely I will want to write another FLOSS game one day, I want to develop a set of notes of the fundamentals of Wesnoth that were done right, and that I will re-use on my future projects.

Also, I suspect that a substantial number of skilled people would like to write FLOSS games, but struggle to do so, for various reasons. While I don't think I have all the answers, I hope they may pick up some ideas from my ramblings here. I am happy for people who feel this essay is useful or helpful to post links to it to web sites that might find it relevant.

This essay is targetted at people who have some skill that is beneficial to game development, usually programming. If you don't know how to program, then you will really have to learn to do that first. :) If people are interested in learning to program, I am happy to give them a few pointers if they write to me, although it's not an easy skill to acquire.

I will start with what I think is the biggest barrier to game development: lack of motivation, coupled with procrastination. You have several game ideas floating around in your head. They are all good ideas. Any one of them could make a great game if implemented well. Now and again one of the ideas really grabs your imagination. You start thinking about ways to implement it, and then how cool it will be once you're done.

But you just can't bring yourself to write enough code to get the project rolling. You might sit down and start something sometimes, but you invariably quit early on. Often during your very first session of development. Othertimes you might get a little way into development, but then as a few frustrating bugs strike, you decide that one of your other game ideas was better anyway, and decide you're better off restarting your development effort on that.

What to do about this problem? Unfortunately, I don't have alot of good answers; I still struggle with this alot myself :) I think it's the bane of all software development, but is especially prevalent in FLOSS game development.

The only real 'solution' I can give to this problem is a very partial solution. It's a solution that flies heavily in the face of conventional software development wisdom.

It's to aim for early gratification. That is, aim to have a reward for your development effort as early as possible. Aim to have something working, on-screen, and hopefully playable, very very quickly. If you're like me, and can get distracted easily, this will preferably within the first day of development.

That's how it was with Wesnoth: I thought about the game concept for a couple of weeks. Then when I sat down to start coding, I had a display that could scroll around a hex map by the end of day one. By the end of day two, I had units on the map that could be clicked on and moved. From there, it was simply adding features: each feature could be seen in action very very quickly.

Of course, this approach has some disadvantages. I suspect that many readers are already wondering where in the world I left the design phase, if I'm talking about something on-screen on day one. But, in my opinion, you definitely shouldn't bother with a detailed, written design before you start coding.

The 'design phase' is the period of time before you start coding, when you think up your game concept. You haven't really started work on your game yet, you are just mulling some ideas over in your head. Once you're convinced it's a good, workable idea, then you start coding, and don't look back.

During the 'design phase', the time when you are thinking about a cool game idea, try to focus some thought on how to implement it. Remember, ideas are very very cheap in computer gaming. Rather than simply thinking about your cool idea, think about how easy it is to implement the basic concept.

You're onto something good when you genuinely think that you can write a very basic, working version within a day or two. When you have already fleshed out the ideas for the classes in your head. I often have ideas for cool games, but when I think about it, I realize it'll be fairly hard to implement. Programmers tend to be optimistic, so if you think something is 'fairly hard', it probably means it's actually 'very hard'. You have to think of something that'll be easy. Something that almost seems trivial for you to be writing.

Another potential disadvantage of the 'early gratification' approach is that it leads you to writing code that might not be as extensible or flexible as if you think out and design things on paper beforehand. You may have some grandiose ideas, and feel compelled to put all sorts of 'hooks' in your code, allowing you to later implement these ideas more easily. For instance, if you are writing your game to be played by a single player, but think that one day you might want to add a networked multiplayer mode, you might try to put all sorts of hooks in to facilitate extension.

In my view, you should try to write good quality, reasonably flexible code to do the task you are doing. However, spending time trying to make your model incredibly flexible, is in my opinion, wasteful. The most likely result, especially very early on, is that this will cause your 'early gratification' to be delayed, and make your project far more likely to die a very early death.

What is crucial is to write very good quality code. Code that is robust. Don't write temporary hacks, especially early on. This will lead to bug-filled code and a project that will be abandoned in frustration. Just write good-quality code for what you are doing now. If you need to change it, or add to it later, you can modify your good quality code and add the new functionality.

If you try to add all sorts of 'hooks' to your code in the hope of accomplishing some grandiose scheme in the future, you will probably find out that your design has problems that require modification when you want to add the new features anyway. If your project gets that far in the first place.

All this, of course, is just the Keep It Simple, Stupid (KISS) principle applied to the start of a FLOSS gaming project. Don't think too big. Don't think too grand. Don't make it complicated. Just get a cool idea for a game that can be implemented easily, and go do it.

---

If you found this essay useful, or at least interesting, let me know, and I'll consider writing the rest of the series :)

David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
caranha
Posts: 135
Joined: September 15th, 2003, 2:34 am
Location: Japan
Contact:

Post by caranha »

Words of Wisdom, Dave :-)

I, for one, am the father of many FLOSS game projects that didn't live to see alpha. So I'm eager to listen to more!
--
Claus Aranha
Mad Scientist
ahwayakchih
Posts: 79
Joined: February 6th, 2004, 12:41 pm
Location: Warszawa, Polska

THX

Post by ahwayakchih »

That's very good text.
And it doesn't apply only to game development, but to any development.
I have much more unfinished (or even not-really-started) projects than the ones which can be called "finished" (project is never really finished, there's always something to add/fix/change ;)).

I'll try to go KISS way next time i'll start working on something :).

THX.
Darth Fool
Retired Developer
Posts: 2633
Joined: March 22nd, 2004, 11:22 pm
Location: An Earl's Roadstead

Post by Darth Fool »

I, for three, am interested in more...
Ayin
Inactive Developer
Posts: 294
Joined: March 30th, 2004, 4:45 pm
Location: Nîmes, France
Contact:

Post by Ayin »

Words of Wisdom, indeed.

Thank you, Dave.
cobretti
Posts: 466
Joined: February 19th, 2004, 4:38 pm

Post by cobretti »

I'm also interested in more, whenever you write it.
ott
Inactive Developer
Posts: 838
Joined: September 28th, 2004, 10:20 am

Post by ott »

Early gratification seems to be a spin on the "plan to throw one away" convention. It's often more important to start with a quickly built but working prototype, rather than something grand: the project is likely to mutate anyway as development proceeds. Then the later versions can use the experience obtained from the early version. Often the key issues turn out not to be the ones initially thought were going to be important. Getting something out the door early allows the real key issues to be discovered, without wasting time worrying about side issues.

Agree wholeheartedly with the basic philosophy, and it works for any software project.

Paul Graham has a slightly different take, and calls this principle "Worse is Better".
http://www.paulgraham.com/desres.html
allover
Posts: 14
Joined: September 30th, 2004, 10:52 pm

Very interesting...

Post by allover »

As a programmer, I found Dave's article fascinating. I think "early gratification" is more important for games than for other software. Any game needs a certain amount of code to make it work, followed by a great deal of story, art, and music. The sooner you get the game to a point where others can help (and want to help) with those others, the better.

I think the presence of WML is a *big* advantage Wesnoth has - the ability to create scenarios without seeming to have to program is a tremendous boon to Wesnoth. (It's not quite how I would have done it, creating a scenario language from scratch; I would have used python; but this *works*, which is a pretty compelling argument).

I think keeping the AI good enough to have an interesting single-player version was excellent also. I never like to play a multiplayer online game until I feel I'm "good enough", which is very difficult to get to unless you can play interesting single-player games. This means both: hard work on AI development, and careful control of the rules so that the AI can cope with them.

I think, also that Wesnoth's choice to use a pretty much stock fantasy world is a big help too - anyone who's played any sort of fantasy game feels like they can add units or scenarios without a great deal of difficulty. A more exotic (say, elves in the old sense: dangerous, fey, and capricious, or Chinese shaolin monks, hopping vampires, Imperial armies and riverboat assassins disguised as an opera troupe) would maybe be more interesting to players but would present a barrier to contributions. (Of course, at this point, such a campaign could be added to Wesnoth...)

It's maybe worth pointing out that if someone wants to create a different hex-based GPL game, they can plunder the Wesnoth graphics and sound to get it up and running. Ultimately it will surely want to develop its own look, but having all those terrain tiles, not to mention units, would give a game just the kind of jump-start it needs to get others working on it.

I'd be very interested to hear more from Dave, including pitfalls narrowly avoided (or fallen into), community-building advice, and any other pearls of wisdom...
Roots
Posts: 103
Joined: March 22nd, 2004, 8:22 pm
Location: Austin, TX
Contact:

Post by Roots »

Yeah I pretty much agree with everything Dave said, especially about the early gratification. I manage my own game project (4 months old soon), and while I don't even come close to having the experience and insight that Dave does, I do have a few comments to make myself. :)


I agree that early gratification is important, but I think planning is even more so. When I started my project, I had a solid 4 years of programming experience backing me, but most of it was for small school projects and assignments. I taught myself how to use SDL pretty easily and I had a simple boot screen, menu, and audio interface up within a week or so. That was my early gratification. Then as things went along, I quickly discovered that I needed to go back and re-write this function or add a new variable in a class, etc. I created a map that and walked a sprite around in it and that was great, but I knew that the entire video engine that I wrote had to be re-designed (it was small and primitive anyway), and so now I have to completely re-write that code.

So I guess what I'm getting at is that there is a trade-off between early gratification and code re-writing. Generally the more you do of the former the more you'll get of the latter. I discovered that once I sat down and made a UML diagram with all of my game classes and how they interact, I could design code much better and with peace of mind that I won't have to completely re-write things (or at least I haven't had to yet).


Anyways yeah thanks for sharing that Dave. Wish I would have read it 4 months ago. :lol:
Hero of Allacrost, a 2D open source RPG. Check it out at http://www.allacrost.org.
MagusXI
Posts: 8
Joined: October 12th, 2004, 7:57 pm

Post by MagusXI »

i have a question i have a game im thinking of makeing, sorta like an online FFT (final fantasy tactics sorta) but i dont know what programming language to write it in, i know a little C++ and a little python (teaching myself), any suggestions, also u guys know any good free compilers or tutorials, and also what exactly is SDL is it a programmin language/library, or is something to do with graphics, sorry lil new to the opensource world, also i dont know if i should use windows or my gentoo linux to make it, so far im leaning towards linux just for the sole fact that their is more of a chance of my windows partition will get a virus unlike linux? any suggestions would be great.
MagusXI
Posts: 8
Joined: October 12th, 2004, 7:57 pm

Post by MagusXI »

also i would like to add what is the best way to teach myself a programming language i mean i can read tutorials all day, and practice them but when it comes to writing my own program im lost, do i use a switch or an if then statement ect ect. thanx for the help



-if i can teach myself gentoo in one night i know i can teach myself programming.
Roots
Posts: 103
Joined: March 22nd, 2004, 8:22 pm
Location: Austin, TX
Contact:

Post by Roots »

Umm isn't this a little off-topic? :roll: Well here's my answer to your questions with my own opinions.

- An online FFT would be an awesome game, however it is an MMORPG and you should definitely not attempt an MMORPG project with your level of experience. These projects require magnitudes of more work and dedication than a stand-alone game. I recommend you start small and make bigger and more comprehensive games later once you have experience.


- There is no final answer for what programming language you should write it in. It depends on a number of factors. Do you want to develop it on a virtual machine so its completely platform independent? Try Java. Do you want to make it as fast as possible? Try C/C++. Do you want to make it quickly with minimal coding effort? Try Python (which technically is a scripting language, not a programming language).


- SDL is an API (Applications Programming Interface). Its basically just a library of code that you call to perform operations with video, audio, cdrom, input, etc. IMO, its extremely easy to learn and use (I taught it to myself this June/July).


- As for the actual machine you write it on, I choose Linux hands down, though I admit I've never programmed on Windows. My first reason is reliability. About 4 times artist/musicians on the staff for my game have lost all of their work because Windows crashed and won't recover. Also with Windows as far as I know you need to purchase or have access to V++ Studio or some program like that, which is at least $100, maybe more.


- The best way to teach yourself a programming language is to use it. The more you use a language the more familiar you will be with it, and just reading a tutorial or a book isn't going to let the language sink in. If you having trouble deciding what constrcuts to use, that basically boils down to experience again. Start with some small test functions, and move up writing more and more complex programs.


Hope that helps.
Hero of Allacrost, a 2D open source RPG. Check it out at http://www.allacrost.org.
Dave
Founding Developer
Posts: 7071
Joined: August 17th, 2003, 5:07 am
Location: Seattle
Contact:

Post by Dave »

Root's answers are generally very good :)

I will re-iterate that a MMORPG is hard to program.

Do you know anything about writing multi-threaded code? About network code? About scalable persistent data storage?

These are the kind of things the server for a MMORPG will require. To write one, you really have to know what you're doing.

In terms of programming, I prefer C++, but it's a very difficult language to know well. If you can get half the questions on this site right: http://www.gotw.ca/gotw/ then you are definitely good enough at C++ to program a game. However most C++ programmers would struggle to get even 20% right...

I mostly prefer GNU/Linux for development. It puts you much closer to the system, and imo is a really nice OS for programmers. However as far as C++ compilers go, Microsoft Visual C++ is leagues ahead of gcc in every respect (other than being non-free and less portable, of course). I'm still undecided as to what is the better OS to develop on.

David
“At Gambling, the deadly sin is to mistake bad play for bad luck.” -- Ian Fleming
MagusXI
Posts: 8
Joined: October 12th, 2004, 7:57 pm

Post by MagusXI »

i found a cool free C++ compiler from http://www.bloodshed.net (link may be wrong) i downloaded the sdl library/develoment packages :) thanks for the advide,
benheath85
Posts: 13
Joined: October 15th, 2004, 3:31 am
Location: dang near the mexican border

Post by benheath85 »

MagusXI wrote:i found a cool free C++ compiler from http://www.bloodshed.net (link may be wrong) i downloaded the sdl library/develoment packages :) thanks for the advide,
I started with that one too!

Someone else may have already beat me to the link, but Cone3D has some pretty good tutorials, if you want to check those out.

If you are learning Python, you may also look intoPygame for very simple game development.

Be patient, do well at school, and have fun.

---EDIT---
Roots wrote: As for the actual machine you write it on, I choose Linux hands down, though I admit I've never programmed on Windows. My first reason is reliability. About 4 times artist/musicians on the staff for my game have lost all of their work because Windows crashed and won't recover. Also with Windows as far as I know you need to purchase or have access to V++ Studio or some program like that, which is at least $100, maybe more.
o.o Well no, you can just use MinGW with MSYS and have a pretty good development environment absolutely Free. Probably about half the books you buy on programming something in windows come with the "introductory edition" of VC++ 6. (There's always a problem with that CD, though. :\) The crash thing bites though. You've probably got some data backup these days, right??? :)
Benjamin Heath

For those about to rock...
Post Reply