ID:120630
 
In case you missed them, be sure to check out programming tips #1 and #2

When you first start programming, the problem you're trying to solve is "how do I write code that'll do ______?". Initially you're happy just to get something working, who cares what the code looks like. But when you try to develop a complete game this indifference can become a problem. As your code gets messier and messier, the project becomes harder to work on - you're more likely to write code that has bugs and they become harder to track down and fix. Eventually it'll get to the point where you're wasting a lot of time, don't feel productive, and are more likely to stop working on the project.

As a more experienced programmer, instead of asking "how do I do ______?", you should start asking "what's the best way to do ______?". In this post we'll look at different ways to write a simple function to see how certain ways are better than others.


It's a good habit to write code in such a way that you can add new features later. You never know what you might want to add to your game, so it's good to make everything generic and flexible so you can easily implement any new idea that pops into your head.

But sometimes it's better to do the exact opposite.

It can take a lot more time to write good code. Cutting corners can save you a lot of time. The key is determining what corners you can cut - the right shortcuts save time, the wrong shortcuts will end up costing you more time later on.

Decide what features your game won't have.

Suppose you're making a somewhat typical RPG where players have items and slots to equip them in. You can spend weeks making a completely generic system that supports a flexible number of slots with complex relationships between items and slots they can be equipped in based on the player's character. For example:

A normal, human-like character has the equipment slots you'd expect, but a two-headed ogre has two helmet slots, two necklace slots, and four earring slots. To a human character a bracelet goes on the wrist slot and a belt goes on the waist slot, but to a giant bracelets are treated as rings (placed on the finger slot) and belts are treated as necklaces (placed on the neck slot). A shapeshifting character can transition between normal form and wolf form - in wolf form they get four bracelet slots but lose some other slots.

This sounds really cool but it also sounds really time consuming to develop. If you can say with certainty that your game won't have these features, you don't need to waste the time making it. If you're only going to have three item slots - helmet, armor, and weapon - there's nothing wrong with doing this:

mob
var
helmet
armor
weapon

If that's all you need, that's all you should write! Some people would look at that and think it's terrible because you can't easily add the features I mentioned earlier. What would really be terrible is spending more than five seconds writing this code if you know it's never going to be more complex than this.

Decide what needs to be done now, what can be done later, and what doesn't need to ever be done.

Suppose you're working on the character creation system for an RPG. When creating a character the player will get to type in their name. There may be many concerns you'd have about players selecting their own names:

1. You don't want duplicate names.
2. You don't want bad words in names.
3. You don't want names with characters that are difficult to type (©, §, ¥, etc.).
4. You want names to follow roleplaying rules (ex: so no characters are named "LukeSkywalker3142")

If there are still other parts of the game you need to develop, you don't want to waste a lot of time on this. It's important to do things in such a way that you can expand them later but not consume a lot of time right now. Things can easily get out of hand:

Suppose you want to make names unique across all servers in case you later let players use the same characters across multiple servers. Suppose you want to have a central database of bad words that all servers refer to - this way you can add to the list at any time. Suppose you want to have character names be approved by someone (ex: the game master) before they can be used.

These things can take a lot of time to code but you don't need to implement them all right now. Some of those things you may never need to implement. Right now, all you really needs is a proc like this:

proc
is_name_valid(n)
if(length(n) < 2 || length(n) > 50) return 0
return 1

As long as you call this in your character creation process you can later expand this check to include more features. This is all you need right now and you can get back to implementing more important things. You might eventually realize that some of the other features (like a central database of bad words) aren't needed. Any time spent expanding this feature right now when you should be focusing on more important things is a waste. Any time spent adding features here that will never be needed is a complete waste.


Some parts of your game will be simple, some will be complex. There's nothing to gain by writing complex code to do a simple task, there's just a lot of time to waste. Identify when you can keep things simple and use that to your advantage.
Oh you sly bugger ;)
Character naming restrictions were on my mind =)
Although I can steal from you too, I forgot to check if a name is too small! :)
IainPeregrine has told me much about this topic. The important stuff in game creation comes before writing any code. You need to make a set of guidelines for everything so you don't add a jumping blob that literally defies your game's laws of physics.
If you think of cool stuff and decide it's too late in development to implement it, save it for a sequel.

And for the naming thing, Hazordhu has a system where you can give names to people (default "[gender] [race] Stranger"). All forms of communication and action messages show you the name you've given the person. No swearing or difficult-character filter necessary there, and I don't think duplicate names are a problem in a roleplaying world so long as you can be distinguished by appearance or middle/last name. You can even wear a hood to mask your name (until you've been exposed).
Kaiochao wrote:
IainPeregrine has told me much about this topic. The important stuff in game creation comes before writing any code. You need to make a set of guidelines for everything...

The previous article explains the problems with trying to do too much planning before writing code.

Every project is unique. Unless you've made hundreds of games there will be many issues you'll run into that you've never had to deal with before. If you try to define how everything is going to work you'll run into problems because you're not experienced enough to know how to plan your way around certain problems - you're not even experienced enough to be able to identify what problems you'll run into. Some planning is good, but thinking you can plan out every detail is bad.

This article is about a slightly different topic. Instead of making decisions about *all* features you're going to have you make decisions about *some* features you're *not* going to have. This is a lot easier because there are more features your game will lack than there are features it'll have. It's also easier because you don't have to identify all features you're not adding, just some of them. Everything you're not doing is a corner you can cut.

I wouldn't put much stock in IainPeregrine's advice. He means well but his advice is often saying "here's how I do things, it has worked for me, it'll work for you too", but its not that simple. I go out of my driveway and turn right to head to work but that's not how everyone else gets to work.
A new method I've recently started trying is to simply sit down and make something small, fun and easy. At the moment, after reading that little back-and-forth between forum_account and Iain, I got the desire to make a small little cave full of zombies that I can attack. So I figured I'd start with that, which is simple enough, then slowly expand it to be a little more complicated. (And hopefully continuing to expand, maybe.)

(Well, that was mostly to see which method I preferred in calculating damage.)
I meant for these articles to be about general topics that can be applied to many different situations, but based on the feedback I've seen people seem to focus on the content in the examples. The examples are just there to show that the concept has applications and isn't just some theoretical nonsense I made up.

Do the articles make that clear? Or does this come across as an article just about equipment and character naming systems?
I know what your saying. But the experienced of us probably have trouble looking past their experience. And that's where the feedback from us becomes less useful.
@F_A
I personally believe I get the true meaning behind these posts. :>
Tiberath wrote:
But the experienced of us probably have trouble looking past their experience.

When your experience gives you trouble it's more commonly referred to as a "bad habit".

I guess I'll just hope that I can come up with a "big picture" article later on that puts these smaller articles in better perspective.