BYOND

There are a lot of people on BYOND who want to make games. This is a wonderful thing! It means that many people are taking a look at programming, many people are brainstorming how to make games better, and that many people are beginning to understand computational logic (which I absolutely adore!). But there are some problems with how games are being made.

As usual, I will be using the newbie programmers that create fangames as examples of what NOT to do, but the message itself should be useful across the board.

Well enough of that, let's dive right on in!

Step One - The Idea

All games start with an idea, some sort of enjoyable way that one might wish to pass time. If you want to create a game, just pick an idea. Pick your childhood favourite something. Space, you liked space as a kid (or at least I did). Let's make a game about space.

Game Idea - Space Themed

Step Two - Brainstorm

You've got an idea, you have a base theme for your game, but it's probably not very well defined. We know that we want to make a game themed in space, but we don't know which aspects of space, or what the game is even going to be. This is where we brainstorm.

Go to friends (particularly if you are making the game-to-be with them) and start to figure out, "What exactly is this game going to be?" Get a true idea of what your game is going to be like. Make sure that it is fun for you, because if it's not fun for you, you probably won't care to try your best, update, or any of those goodies to the game. Then it won't be fun for anyone.

So we decide that because everyone likes pewpews, we're going to have some kind of space combat game. Games are more fun with others, let's make it multiplayer!

Game Idea - Multiplayer Space Combat game

Step Three - Planning

Excellent, the idea for the game itself exists, however, we have not planned the mechanics of the game. Let's work on that. You get together with your friends, you all figure out what has to actually go into the game.

There are many ways that this can be done, each unique to the person doing it. Here's what I suggest; use notepad to type out your plan, and save it with the source files. There are many advantages to this setup. The plan is easy to find (Goddess knows that I've lost many a file!). It can easily be passed between project members. It's easy to use as a fast checklist. And it's pretty hard to forget a feature that you keep planned with the project!

Here's how mine turn out.

Name: Mermaid Melody Online
Game: Turn-Based RPG

Player Variables:
- Health // Hp
- Voice // How strong your songs are
- Skills // List of skills
- Partner // Duet Partner (Mob Reference)

Gameplay:
- Explore the surface
-- List of things to do on the surface (detailing each one)
- Explore the ocean
-- Things to be done under the surface (detailing each one)

Special Features:
- Duet ability
-- Explanation

So now your game is planned out in detail on notepad. You won't lose it, and it is easily edited to keep up with changing plans. Now we get to the fun part.

Step Four - Code

Wow! We sure did a lot of prepwork before actually beginning the code! This is good!

Sun Tzu said:
"The general who wins a battle makes many calculations in his temple were the battle is fought. The general who loses a battle makes but few calculations beforehand. Thus do many calculations lead to victory, and few calculations to defeat: how much more no calculation at all! It is by attention to this point that I can foresee who is likely to win or lose." (The Art of War - Chapter 1: Laying of Plans)

"Great! Let's get our hands dirty Artemis!" Not so fast, tiger! We forgot one thing!

It's not really "required" but it helps if you set a goal for the week. It gives you something to focus on, and you feel like you are progressing towards a finished product. This will help you maintain your desire to code. Figure out what you want to do, then do it.

Things to remember while coding

Coding is often a trial and error process. Try something, it works, good! Try something, it doesn't work, TRY AGAIN. If your problem persists and you can't figure out why, then you go to Code Problems. If you want to bounce ideas around on how to do something, Developer How-To. It's okay to post, asking for help. It's not okay to post, asking for someone to do everything for you. Also, reference this post for some pointers on the Dev. Forums.

Also, when you make a feature, test it out! If you code a dozen procedures at once, and you test it only to find a bug, you now have to dig through twelve procedures to find a bug instead of just one.

Step Five - Testing/Fixing the Game

Your game is finished, but it isn't complete. Now you need to test it to fix any bugs that may exist. Get some friends together and let's abuse our space game to hell and back! If it's doing something that it should not be doing, fix it. Handle all of these bugs before release.

Note: Sometimes players prefer to open test. I'm not truly opposed to this, but I feel that if people think that a game is crappy when they first test it for bugs, they'll leave and never come back, ignoring that the game is being tested/fixed. (Just my .02)

Step Six - Stable Release

Now that your game has been cleaned up, it should be ready for release. So, set up a server, spread the word, enjoy your game!

Optional Step Seven - Update

Continue to update your game to make it better.

Common Mistakes

I'll admit right now that I have been guilty of doing some of these before. They're mistakes, and I'm not too keen on repeating them. I include them because I want to save you (the reader) some trouble if you're in the process of making these mistakes.

Fangames

You knew that this was coming. Do not set out to purely make a fangame. There's nothing truly wrong with fangames themselves. The problem is in how they turn out. Fangames have a bad rep, and if you think that you can overturn that, be my guest. Please, be the example! Be the city on the hill! There's nothing wrong with fangames. There's everything wrong with poorly made fangames.

(You'll note that the rest of these mistakes often run with fangames)

Ripping a Source

Come on. You're a good programmer (even if you're new at it). Do not rip sources and try to publish them as your own. Plagiarism itself is illegal, and BYOND won't list it, and you get a rep as a ripper that is very difficult to change. (I already have a rep as an extremist to some readers and it is unlikely that they'll change their opinions of me any time soon) Just don't rip.

Planning a website/forum

Here's the deal. Often game makers will make a website/forum for the game before it is even started. This is a very bad way to start. One. The game doesn't exist yet. What are the forums for? (Discussion of the game can be done in chatrooms and the like. Don't make things more complicated than they have to be.)

I think the logic behind this is that a website makes you "official." It doesn't. You spread the word that you have a website. People will look at all of the NOTHING that you have on it, laugh, and call you a joke. Having a site doesn't truly make you "serious." (Granted, paying for it means that there is a factor of "serious" involved...)

Make the game, then the website. The issue is a lack of content really. Forum games aren't terribly exciting anway.

Worry about Game Moderators instead of the game

Wooo boy. How many times I have run into this problem.

Game Moderators (commonly abbreviated "GM") have become somewhat of a joke today. Go to just about any fangame. GMs are the people with the special verbs to do whatever they want. This saddens me in that GMs are no longer GMs. They're just people with special benefits because of who they know. I whole a whole post on the issue of GMs here but the gist of it is, GMs police servers. They don't get special privileges. It's their job to make sure that your fun doesn't infringe upon someone else's fun. (And vice versa) So please, don't go around planning special GM verbs before the game. There's no game yet to police anyway.

(Also please note that not all games need GMs.)

Isolating Assistance

Do not bite the hand that feeds you. I have seen this time and time again (it has even happened to me).

If you ask for help on the Dev. Forums, (as I stated earlier) do not expect someone to feed you answers. They will tell you how to move past your current road-block, but they will not make your project for you. No one will be Granny Mae to you. We don't do finger painting and then make cookies together. Is there an issue of attitudes? Certainly. Even I (unintentionally) make what can be seen as snarky remarks here and there. (One guy even said that I was useless despite answering his question to a t because I did not show any code!) What happens is that attitude is seen as insult to the helpee. The helpee insults the helper "back" and the helper says, "Screw it. You don't need me," and leaves. Avoid this scenario.

If you don't undersatnd someone as they explain it the first time, ask about it. Do not throw a fit.

As an add on, when you post in classifieds, you're still asking for help. However, it's different there. It's not a "self-help" anymore. You're asking for someone else's services.

From Fullmetal Alchemist:

"In order for something to be gained, something of equal value must be lost."

You are asking for someone else to give you their time and effort. They need to be compensated for this. If you read this link you'll see an example of a good way to handle the classifieds. What often happens, is that compensation becomes "GM" or "Admin." These things are not compensation! Rather, they are, but they are generally not acceptable. (You'd know more about that too, if you read the link that I posted earlier.) Money talks.

I'd also like to point out that it is not uncommon for people to inform you in two sentences what I often say in a few paragraphs (I like to babble). Usually it's something like, "GM is not compensation," or, "You reward work with more work?!" These people are trying to tell you how to get a better response to your ad. Yes, it often sounds like an insult. Yes, sometimes it is one, but it is said with love (Tough love's the best love of all the love there is) When you isolate these people, you're shooting yourself in the foot.

Ignoring Player Input

Your players are only interested in making the game as enjoyable as it can be for them too. If they toss you a few lines on ways to improve it (removing log training... *hint hint*) you might want to take a look at it. Talk with them. Figure out what they were thinking. You can still say now afterwards, and maybe they'll quit playing. That's okay! Just never pass up an opportunity to improve your game from a player point of view.

Conclusion

Your games are not all going to be big hits. In fact, odds are that none of them will. It's cool! None of mine are hits either! The point is, if you think about it, it doesn't matter if you get to Point B from Point A. If you wind up at Point C, you might find something better. The destination doesn't matter. The journey is what matters. You made a game. You learned some stuff along the way. Use this stuff to make your next game, and maybe that one will be a hit. Either way, making the game is still a blast.

Note: Yes. I know that my method of making games is very reminiscint of those essays you wrote in high school. Those essays focused on organization of ideas, which is a very useful skill (or so I find) in coding.