Warning of the Day

ID:45030
 
Jul 7 2008, 5:58 pm
Keywords: miscellaneous
"Never announce something you have not yet done. Try, and you will be instantly robbed of the determination to do it. 100% guaranteed!"

How many BYOND developers (myself included) have only learned this lesson after abandoning multiple projects (Peregrine City, Reverie, Nostalgia, etc.)? However, it was never my vigorous propaganda campaigns that killed my projects, it was always a combination of feature creep and ambitious programming.

There's a lot of lessons I've learned from developing projects that I wish I had known years ago. Some of them can be summed up in the same way as the Warning of the Day:
  • Only program those features which the game absolutely needs, and release a 1.0 version ASAP. Once that's done, you can always release sequels.
  • Don't open the doors until version 1.0. Why should your players come back when the game is finished if they've already seen everything in development? Further, why should you finish the game, if you've already seen everyone play it in development?
  • Make the interface first. The hardest part of programming a game, and the least rewarding part, is the interface: the title screen, the ending, putting players into a waiting queue, etc.. These things only get harder as you program more of the game. However, once you have input and output programmed, the internals are easy. This goes for games as well as modules.
  • Always focus on what the game absolutely needs at this moment. Sure, that GM jitsu would be awfully cool to program and use against n00bs, but your game really needs a working saving system to step forward. Always do the next step, otherwise you're wasting time.
  • Stick to one project. That game idea you had today is the coolest ever, and it would be really fun to program, but you know what? You have a game you're half done with, and at some point it was the coolest idea ever. Give that other idea two months, and it will be just as boring as this one. The only way you'll ever have a finished game is to stick to one and finish it.
I'm sure you all have tips of your own, and I'd love to read them. For instance, Gughunter warns that you shouldn't stop to make icons or other resources when you're on a roll with programming. Keep a supply of place holder graphics and audio handy so you don't sabotage your own productivity. Have any other tips? Reply and I'll add them if I think they're good advice.
Jul 7 2008, 6:10 pm
This is a personal rule I force for myself to commit. Though you should never release your game to the “world”, always have a close friend, or a brother, to help you test out your game and the online portion. The more they say they like it the more motivation you will gain. Also who knows, they could possible give you ideas you would have never thought of.

One more rule I use is always complete the most boring parts of the program first and fast, such as a joining queue. Several times I have started working on the most exciting and hardest stuff to program foremost, and when it comes to the last stretch I lose motivation as the additions I need to add do not interest me.
Jul 7 2008, 8:27 pm
I agree with most part of what you are saying, besides one point.

"Make the interface first."

If you know exactly how you are going to program your game and exactly how it is going to turn out and exactly what the gameplay is going to be like then yes.
Otherwise, NO!
Any features regarding input control, GUI and stuff like that, should in my opinion be made after all the core gameplay elements and such are coded.
With coded I meen, finished, won't be changed or expanded anytime soon.

Besides that it's also very much in conflict with: "Always focus on what the game absolutely needs at this moment." since BYOND offers you a standard interface that will do the job quite well in most cases.

"Stick to one project." I feel is very personal.
In the end you are coding to have fun, and if you like to code something other than your great idea then I'd say "why not".
I personally feel that if it's rewarding and fun for you to create 3 half finished projects (and learn from them alot) you might rather want to do that than trying to stick trough creating one boring finished game.

Just sharing my views,

- Fint
Jul 7 2008, 9:07 pm (Edited on Jul 7 2008, 9:14 pm)
The rule which I always have to remind myself of is:

"Don't exceed your original scope. Games naturally evolve as you work on them, but don't let them evolve too far. It's okay to make new features that support the existing content, but not at all okay to add entirely new gameplay elements. Otherwise you'll be trapped in an endless spiral of half-finished systems, which individually are all exceedingly brilliant but in combination are still not enough to make a playable game."

To cite an example: Interstellar Inc. was originally called Interstellar Retribution and was intended to be a realtime team battle board game vaguely along the lines of Star Fleet Command/Star Fleet Battles. It is now a vicious, life-sucking monstrosity which I term "a space-operatic single-player open universe" that purports to be a mixture of Starflight, Star Fleet Battles, Elite, MegaTraveller, and way too much else. ;-)

A significant issue with II is that much of the game's content is created even though core systems of the game are still entirely non-existent. After ripping out the existing movement code in order to adopt a new location system, I never did replace that code, for instance; the game is entirely unplayable, even as a concept demo.
Jul 7 2008, 9:56 pm
So true. I have billions of unfinished projects.
Jul 7 2008, 11:32 pm
Sounds a lot like the agile software development philosophy.

Jt said:
"After ripping out the existing movement code in order to adopt a new location system, I never did replace that code, for instance; the game is entirely unplayable, even as a concept demo."

I have something pretty much exactly the same. This 2D zelda-style flash game that had its own file structure, loaded and packed away dungeons. Then I expanded it massively and never actually got round to making the player able to walk around again. Still working on getting the multithreaded sockets system perfected. :p
Jul 8 2008, 12:11 am
I generally program just for the enjoyment of it, rather than to produce a finished product, so I often have a couple of projects on the go so that if I don't feel like working on one of them I can work on something else. I also tend to have an idea, program a basic solution, and then refine and add features as time goes on, such as with my Mandelbrot set generator.
Jul 8 2008, 5:31 am
I don't think I've ever followed any of those. Probably why I have around 40-45 unfinished projects..
And only one I can even call "finished" to an extent.
Jul 8 2008, 7:18 am
Make the interface first. The hardest part of programming a game, and the least rewarding part, is the interface: the title screen, the ending, putting players into a waiting queue, etc.. These things only get harder as you program more of the game. However, once you have input and output programmed, the internals are easy. This goes for games as well as modules.

Its important to have your interface built so that you know your interface will be able to handle what you want your game to do. It really sucks to add a cool system only to realize that your interface doesn't support it and you have to go butchering things later. But don't go overboard when designing interfaces either - keep it simple and clean, and worry about glitz when the game is playable.


Stick to one project. That game idea you had today is the coolest ever, and it would be really fun to program, but you know what? You have a game you're half done with, and at some point it was the coolest idea ever. Give that other idea two months, and it will be just as boring as this one. The only way you'll ever have a finished game is to stick to one and finish it.

Just to amend that a bit, this isn't to say that you can't work on more than one project, but its very important to stick to one project AT LEAST UNTIL ITS PLAYABLE! If you come back to a project later only to find that its unfinished and you can't remember what you were working on when you left, chances are you're not going to start up on it again. But if you come back to a project that you can just add new stuff to, then its all well and good.

That goes back to your first point.
Jul 8 2008, 10:54 am
Meh, there are a few of those I disagree with. For example, I don't make the interface until I have the basics of the game done. For example, in my GIAW for example, I did the interface last. Why? Because I came up with ideas while I coded. Also, for longer projects, when I come up with a good, short* idea, I take a break. I mean, coding one thing only for a year can get boring without breaks. As far as placeholder icons go, I just quickly sketch out little icons as I go along (maybe a square, or a little cylinder) and as far as audio goes, I never add that until I finish.

*It usually takes anywhere from a week to a month to finish these "mini ideas".
Dec 11 2009, 8:27 am
Addendum: This line seems to be a matter of confusion:

Make the interface first.

Now-a-days on BYOND, interface means "A .dmf file", but this is not what I meant when I wrote this article.

Here, interface refers to how your player will interact with your game. Will he type verbs? Will he use the keyboard? The mouse? If you don't answer these questions first, then your users will end up with a VERY bad interface, such as having to walk up to someone and click an "attack" verb over and over again.