So you want to make a WME game? [WME Resource Center]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== So you want to make a WME game? ======

This short article is not intended to walkthrough you through the process of WME game creation, but offer a small guidance for those who feel lost in the game development. I offer here my own experience and of course I don't have any "license" on the one and only way. Motivation of this article arose from quite a few private chats on IRC channel which led me to wording some of my ideas for all who are interested. I've seen quite enough of really dirty and messy code to want warn you, that this is way which leads to hell.  Also some of my ideas could sound quite pedantic to you, but trust me, the more strict are you to yourself, the more easy will your game progress. Also note, that this tutorial is aimed for beginners and those more advanced will not find any groundbreaking discoveries so move along. ;-)

So let's get started:

=====Overview=====

You obviously woke one day with the idea of making game and since it probably held you for quite some time, you decided to try the transition from idea to something more real. It's also very unlikely that by that time you truly realized what are consequences of such an unfortunate idea. When you play a game, it can look really simple and manageable, but as soon as you start with doing it, you can very fast drown in the process itself. 

To help you resurface let's state a few really obvious facts. Your typical adventure game is in fact a multimedial project and will consist of a few main building blocks:

  * Story - the core of the game, we will get there later
  * Graphics - the look of the game
  * Music - the strange beeping noices your PC speaker makes (oh wait, it's 2005 already)
  * Sound - important layer which is able to lift your game way way up
  * Scripting - WME encapsulation of the aforementioned stuff

Ha, you may think, what about puzzles, interface etc.? Well to me puzzles and interface is fixed part of the story. I would never put a puzzle in game without relevance to the story! I understand that slider puzzles, timed mazes etc. are very frequent but unless they have really tight relevance to story, there are no option for me. So these things are part of the story and not that the story is here just for justification puzzle presence.

=====Story=====

The story - ah, the core of an adventure game. Why so many teams starts with doing gfx, coding etc. without having the story solid and in place? I assure you, this will lead you to premature end of your game. So before you even run WME finished story with puzzle design, ideas about interface, map of locations, item specification etc. should be in your so called "design document". All this can be done without even touching WME or asking gfxers to make more and more images. Also with this ready you have better probability that you will get missing team members. Internet nowadays is full of persons claiming they will do game which will beat all existing games. If they were true, we will have no time developing games, since we will spend our time playing this google of amazing games. Sadly it doesn't happen so we have to contribute ourselves.

Okay, I don't want to slip too much into game designing, because there are around way better resources for that and my point is showing a few key aspects of WME game creation. Some things are really specific and it pays off to follow them right from the beginning. Imagine the following situation, you create your super duper game and in one third you realize, that you made some design flaw, which forces you to rewrite thousands of lines of your gamecode. Would you be happy? Or does it sound familiar? To be honest I have been there too before. But enough babbling and let's get a bit more specific.

=====The big split=====

One common denominator of successful project is dividing it into smaller manageable chunks, otherwise you will get lost in a huge mess. Also some main division will help us to manage the project for obvious reasons. You can see, that our nice bullet already show s some ideas how to divide your prroject. WME has a great feature called packaging system. It works like this: you can create as much directories in your Project Directory and than in Project manager just **right click** it and choose **Promote to Package**.
From now on your compilation will create package from this directory as well. So if you stick to some basic resolution, you can create a few following folders in your project directory and promote them to packages: 

  * data - for scripts
  * music - for music
  * sound - for sounds
  * speech - for speech (easy voice localization just by replacing one package)
  * gfx - for graphics

In your script you still reference it as if it was in one big package, which is obvious plus. Now what is the big difference? Other than having everything neatly organized, imagine, that you are testing with your international friends your game and you make a simple coding mistake - you simply sent them repaired **data** package which is only 1MB in comparison to GFX which can be 400MB. 

But my division won't end in this simplistic way. WME is really nice regarding to packaging so I have separate packages for each logical game location. Not only it's more clear to see through the ever increasing ammount of data, scripts etc., but it's easy to debug, test and synchronize with the rest of your team. I'd say stick to splicing your game into small manageable chunks and you will be less frustrated.

=====Making it readable=====

My first real complaint about some of the code I helped to debug is the absolutely terrible and unreadable typography. I presume that I am not alone and poor Mnemonic comes through even bigger mess, but even what I saw looks terrible. It's usually nice to get some good rules and than stick to them. Like if i have any blocks they should be aligned. Here's the example:

<code script>
method HelloWorld()
{
  var greeting;

  switch (language) 
  {
     case "german":
        greeting = "Hallo";
        break;
  
     case "english":
        greeting = "Hello";
        break;
  
     case "swahili":
        greeting = "Jambo";
        break;
  }    
}
</code>

This formatting makes the code instantly readable without necessity to spend ten hours by reformatting it to something reasonable. Next thing is comments. You may live in a filosophy, that //comments are for cowards//, but nothing can be farther from truth. You will need them down the road, since game is NOT thirty lines of code you put together in ten minutes. Game development will last at least months and you will make awesome lot of bugs which will wait for debugging. You will of course forget some of the ancient obsolete code lines and will then figure out what does this strange loop putting pi into an array and than multiplicating it by 42 mean. Without comments you will be lost. Also don't think in a way "I will comment it later.". Truth is, that you most likely won't. :-) So better write that comment there and don't have to painfully remember later. Which brings us to another principle of mine. 

**NEVER experiment on main project.** If you decided to try some principle which is unknown to you, it's really easy to make a separate WME project and test your ideas there. Quite often you mess it up completely and you don't want to find your main project destroyed or at least dirty. You should be pedantic on what to include into the main project. Think about it as of a place where only clean code belongs. Nobody prevents you from creating your test folder where you can change quick and dirty solutions, but once you decide to include it into the real thing, make it clean (and use soap too)!

=====Variables and "what have I meant with this?" syndrome=====

Okay, this being said, let's move onto our next big problem: **variables and objects**. I already wrote a tutorial about them which can be find [[kbase:variables_and_objects|here]], but right now I will speak about semantics. It's really obvious mistake to fill your code with variables named //a, a1, a2, a3 etc. // It's even worse if you think you are cool and name your variables aptly like //SuperVariable15 or MyLittleBlueDaisy// when it has completely no relevance to the code itself. Right now you like that idea, but later on you will hate yourself while trying to spot a bug you made six month ago.  My advice is to be really strict and name variables according to what they really do. So if you need a variable for loop, why not name it this way? 

Even worse is the situation with global variables. If you still believe in your //a, a1, etc.// naming convention you can easily use the same variables for global variables as for the local variables! This will lead to unpredicatablity of your scripts and lead you to alcoholism or even worse listening to reneissance music. On the other hand, if you will be systematic and use for example some kind of prefix for your global variables, you will never encounter this. If you are still clueless, here is a tiny example, how can your variables look like: 

<code script>
global gDoorEntity;
var DoorEntity;
...
...
DoorEntity = "open";
gDoorEntity = "closed"; 
</code>

On the first sight you see not only what your variable is attached to but also what variable is global and what local and you will never mess this up. 

Now when the idea of variables is hopefully clear we should really start thinking about objects. It's again stated in the aforementioned tutorial, but let me restate again. Are you really sure it's easier using three separate variables you need to take care about then nicely encapsulated example like that? 

<code script>
var DoorEntity;
DoorEntity.State = "open";
DoorEntity.X = 120;
DoorEntity.Y = 70;
</code>

=====Switch the IF off=====

I will **switch** onto next issue. Please remember: **IF'S ARE EVIL** Too many if's killed an elephant and you can be sued by greenpeace. Also with overusage of if's you can end in hell. Now seriously, learn how to use **case** and start to love it. Again a small example:

<code script>
switch (DoorEntity)
{
  case "open":
    actor.GoTo(100,20);
    break;     

  case "destroyed":
    actor.GoTo(100,20);
    actor.Talk("We shouldn't hand those zero gravity guns away so easily.");
    break;     
 
  case "closed":
    actor.Talk("I can't walk through closed door. Wait for Hopkirk.");
    break;
}
</code>

With more and more states included isn't **case** nicer and more clear that way? 

=====Truth is out there (in WME documentation)=====

Okay, last technical thing before I bore you to death. Guys listen. **WME has excellent documentation** You should learn how to read it. I mean it seriously. 97% of all your problems is hidden there! Yet sometimes it feels that you rather post questions at forum than to look into this chm file. It's a shame, because we could use our time at forum more productively if we discussed principles and not things which can be easily found in docs. I know that everyone including myself came through the period of asking about obvious, but please at least look there. It's sometimes funny when you mentioned that it's in documentation and the person in question says " well, I haven't look there yet.". If you can't find it there feel free to ask, but make that first step - look there. ;-)

And that concludes for a few tips I have for you. It will grow over time when some other ideas come to me, but right now I am done typing. I hope you could find at least a few things useful and hope to see some new exciting adventure games.