2. On Planning a Game

Last lesson we asked ourselves some questions about our motivation. In this one we’ll present some more technical questions to consider. In the next lesson we’ll answer them for the sake of our tutorial game.

Note that the suggestions on this page are just that - suggestions. Also, they are primarily aimed at a lone hobby designer or a small team developing a game in their free time.

Important

Your first all overshadowing goal is to beat the odds and get something out the door! Even if it’s a scaled-down version of your dream game, lacking many “must-have” features!

Remember: 99.99999% of all great game ideas never lead to a game. Especially not to an online game that people can actually play and enjoy. It’s better to get your game out there and expand on it later than to code in isolation until you burn out, lose interest or your hard drive crashes.

  • Keep the scope of your initial release down. Way down.

  • Start small, with an eye towards expansions later, after first release.

  • If the suggestions here seems boring or a chore to you, do it your way instead. Everyone’s different.

  • Keep having fun. You must keep your motivation up, whichever way works for you.

2.1. The steps

Here are the rough steps towards your goal.

  1. Planning

  2. Coding + Gradually building a tech-demo

  3. Building the actual game world

  4. Release

  5. Celebrate

2.2. Planning

You need to have at least a rough idea about what you want to create. Some like a lot of planning, others do it more seat-of-the-pants style. Regardless, while some planning is always good to do, it’s common to have your plans change on you as you create your code prototypes. So don’t get too bogged down in the details out of the gate.

Many prospective game developers are very good at parts of this process, namely in defining what their world is “about”: The theme, the world concept, cool monsters and so on. Such things are very important. But unfortunately, they are not enough to make your game. You need to figure out how to accomplish your ideas in Evennia.

Below are some questions to get you going. In the next lesson we will try to answer them for our particular tutorial game. There are of course many more questions you could be asking yourself.

2.2.1. Administration

  • Should your game rules be enforced by coded systems or by human game masters?

  • What is the staff hierarchy in your game? Is vanilla Evennia roles enough or do you need something else?

  • Should players be able to post out-of-characters on channels and via other means like bulletin-boards?

2.2.2. Building

  • How will the world be built? Traditionally (from in-game with build-commands) or externally (by batchcmds/code or directly with custom code)?

  • Can only privileged Builders create things or should regular players also have limited build-capability?

2.2.3. Systems

  • Do you base your game off an existing RPG system or make up your own?

  • What are the game mechanics? How do you decide if an action succeeds or fails?

  • Does the flow of time matter in your game - does night and day change? What about seasons?

  • Do you want changing, global weather or should weather just be set manually in roleplay?

  • Do you want a coded world-economy or just a simple barter system? Or no formal economy at all?

  • Do you have concepts like reputation and influence?

  • Will your characters be known by their name or only by their physical appearance?

2.2.4. Rooms

  • Is a simple room description enough or should the description be able to change (such as with time, by light conditions, weather or season)?

  • Should the room have different statuses? Can it have smells, sounds? Can it be affected by dramatic weather, fire or magical effects? If so, how would this affect things in the room? Or are these things something admins/game masters should handle manually?

  • Can objects be hidden in the room? Can a person hide in the room? How does the room display this?

2.2.5. Objects / items

  • How numerous are your objects? Do you want large loot-lists or are objects just role playing props created on demand?

  • If you use money, is each coin a separate object or do you just store a bank account value?

  • Do multiple similar objects form stacks and how are those stacks handled in that case?

  • Does an object have weight or volume (so you cannot carry an infinite amount of them)?

  • Can objects be broken? Can they be repaired?

  • Can you fight with a chair or a flower or must you use a specific ‘weapon’ kind of thing?

  • Will characters be able to craft new objects?

  • Should mobs/NPCs have some sort of AI?

  • Are NPCs and mobs different entities? How do they differ?

  • Should there be NPCs giving quests? If so, how do you track Quest status?

2.2.6. Characters

  • Can players have more than one Character active at a time or are they allowed to multi-play?

  • How does the character-generation work? Walk from room-to-room? A menu?

  • How do you implement different “classes” or “races”? Are they separate types of objects or do you simply load different stats on a basic object depending on what the Player wants?

  • If a Character can hide in a room, what skill will decide if they are detected?

  • What does the skill tree look like? Can a Character gain experience to improve? By killing enemies? Solving quests? By roleplaying?

  • May player-characters attack each other (PvP)?

  • What are the penalties of defeat? Permanent death? Quick respawn? Time in prison?

A MUD’s a lot more involved than you would think and these things hang together in a complex web. It can easily become overwhelming and it’s tempting to want all functionality right out of the door. Try to identify the basic things that “make” your game and focus only on them for your first release. Make a list. Keep future expansions in mind but limit yourself.

2.3. Coding and Tech demo

This is the actual work of creating the “game” part of your game. As you code and test systems you should build a little “tech demo” along the way.

Try to avoid going wild with building a huge game world before you have a tech-demo showing off all parts you expect to have in the first version of your game. Otherwise you run the risk of having to redo it all again.

Evennia tries hard to make the coding easier for you, but there is no way around the fact that if you want anything but a basic chat room you will have to bite the bullet and code your game (or find a coder willing to do it for you).

Even if you won’t code anything yourself, as a designer you need to at least understand the basic paradigms and components of Evennia. It’s recommended you look over the rest of this Beginner Tutorial to learn what tools you have available.

During Coding you look back at the things you wanted during the Planning phase and try to implement them. Don’t be shy to update your plans if you find things easier/harder than you thought. The earlier you revise problems, the easier they will be to fix.

A good idea is to host your code online using version control. Github.com offers free Private repos these days if you don’t want the world to learn your secrets. Not only version control make it easy for your team to collaborate, it also means your work is backed up at all times. The page on Version Control will help you to setting up a sane developer environment with proper version control.

2.4. World Building

Up until this point we’ve only had a few tech-demo objects in the database. This step is the act of populating the database with a larger, thematic world. Too many would-be developers jump to this stage too soon (skipping the Coding or even Planning stages). What if the rooms you build now doesn’t include all the nice weather messages the code grows to support? Or the way you store data changes under the hood? Your building work would at best require some rework and at worst you would have to redo the whole thing. You could be in for a lot of unnecessary work if you build stuff en masse without having the underlying code systems in some reasonable shape first.

So before starting to build, the “game” bit (Coding + Testing) should be more or less complete, at least to the level of your initial release.

Make sure it is clear to yourself and your eventual builders just which parts of the world you want for your initial release. Establish for everyone which style, quality and level of detail you expect.

Your goal should not be to complete your entire world in one go. You want just enough to make the game’s “feel” come across. You want a minimal but functioning world where the intended game play can be tested and roughly balanced. You can always add new areas later.

During building you get free and extensive testing of whatever custom build commands and systems you have made at this point. If Builders and coders are different people you also get a chance to hear if some things are hard to understand or non-intuitive. Make sure to respond to this feedback.

2.5. Alpha Release

As mentioned, don’t hold onto your world more than necessary. Get it out there with a huge Alpha flag and let people try it!

Call upon your alpha-players to try everything - they will find ways to break your game in ways that you never could have imagined. In Alpha you might be best off to focus on inviting friends and maybe other MUD developers, people who you can pester to give proper feedback and bug reports (there will be bugs, there is no way around it).

Follow the quick instructions for Online Setup to make your game visible online.

If you hadn’t already, make sure to put up your game on the Evennia game index so people know it’s in the works (actually, even pre-alpha games are allowed in the index so don’t be shy)!

2.6. Beta Release/Perpetual Beta

Once things stabilize in Alpha you can move to Beta and let more people in. Many MUDs are in perpetual beta, meaning they are never considered “finished”, but just repeat the cycle of Planning, Coding, Testing and Building over and over as new features get implemented or Players come with suggestions. As the game designer it is now up to you to gradually perfect your vision.

2.7. Congratulate yourself!

You are worthy of a celebration since at this point you have joined the small, exclusive crowd who have made their dream game a reality!

2.8. Planning our tutorial game

In the next lesson we’ll make use of these general points and try to plan out our tutorial game.