ID:154208
 
Can someone tell me the steps to designing a game? I tryed to look at unimax's tutorial but it was a broken link. Or if you could give me a good site that would be fine.
That is a very open ended question.
Let us start with a single question and I will help you create a good idea. Good idea means that no one or no company has the idea copyrighted.
What kind of game do you want to create?
In response to Exadv1
Well it's an idea that several companies has used. But giant fighting robots like Gundam. This is a very widly used idea. Several animes and games have these.
BurningIce wrote:
Can someone tell me the steps to designing a game? I tryed to look at unimax's tutorial but it was a broken link. Or if you could give me a good site that would be fine.

If you're curious about how to start coding, there's my tutorial. Though I didn't get the impression that's what you're after.

If you want to know the steps to take to get your idea into reality, I'm not sure there are any steps per se... really you just have to open the program and start coding. To know what to code, decide what features you want in your game, then think about what variables and procs you'll need. Figuring that out can be difficult at first but gets easier with practice.

Z
You might want to check out ByondBwicki... specifically, Gazoot's pages on inspiration. There's a few good pointers in there.
My game-designing steps work in an order that goes something like this (Although, since I've never actually release anything (come close!) you might not want to take my advice):

1. Conceive of idea. Usually by combining a few of my favorite features from a number of other games, programs, stories or whatever out there that I liked.

2. Let that idea fester for a while until it becomes well-enough thought out that it could possibly be made into a game.

3. Start work on the graphics for the game. Deciding how they'll be layed out should have been in part 2. If I can't stick with the graphics long enough, the game probably wasn't worth making anyway, if I lost interest in it this fast. Usually motivations will come and go though, and I'll work on the graphics little by little until I have something workable enough to actually start programming.

4. Here's the killer. I open up DreamMaker, start a new environment, and I think, "Oh crap, I can't decide what to name this thing!" I usually either give up here and never think about the project again, or I think of something spiffy enough for me to ignore it and move onto step 5.

5. Get the basics done. Usually this involved setting up the world information in the code, view size, name and all that. Then I setup all the basic turfs I need to start building my first map. After that, I decide how I want the map to look. By the time I get a decent map (if I didn't get this far, the game idea stank and wasn't worth fiddling with), then I stare at the map for a while until I can convince myself that this will indeed be a cool game. Otherwise I trash it and save the graphics for something else.

6. I've been motivated by looking at my map now. Time to get to work! First step, put in a say verb, then show it to whoever is online on my pager at the moment (usually Spuzzum or English) and if they like the graphics, I can safely work on it a little more.

6. Alternatively, I may have been motivated by the graphics and been so eager to work on a certain proc that was involved in one of my ideas for the game. I'll work on that for a while and forget to put in a say verb, so the first time I show someone we'll end up communicating over pager until I remember to put the say verb in.

7. I keep making more and more procs until I get sick of the game then put it away and go work on something else.

8. A while later, I take it back out again and work on it some more, then get sick of it and go work on something else.

9. Repeat step 8 until the game is finished. You'll usually give up before then, though. If not, you'll be so sick of it from hosting it to show off to people on your pager, than you wouldn't enjoy it if it were finished anyway, so you pitch it.

That's how Foomer's games get published. I hope you understand.
In response to Foomer
Thanks that was what I was looking for... I think. Do all of you have alot of trashed projects? I have 3: 2 DBZ games and an RPG called broken lands.
I just made a game from start to finish in 27 days. I think I'm qualified to answer your question ;)

As for me I'm at a level now to where I can skip a lot of the pre planning. But none the less I've been making games for well over 20 years now so..

Best thing to do is get a few pieces of blank paper. Let theses be your drawing boards for ideas, charts information. To look at a game as GD(Game Developer) you must realize the behind the scene matrix of how everything works. Also everything has loops and ends. By that I mean, some things will loop back and relate to other things in the game, or it will have a resolution and ending, ex: death of a character.

Once you have this in mind start thinking of the Genre you want to code for, the basics are: Action, RPG, Strategy, Board-games, Word-games(MUDS), Sports, Sims. From these you can grow your ideas into the directions you need to code for. Graphics of course will come much later in the planning stages as you start to make content for your game. Also if this is your 1st game, never over do yourself, a simple finished game is much better than a "This could be a cool game if.." because you have a good start but don't know how to code in all the cool stuff you planned for. If you want to do things you don't know how to do, get someone else that can code in on your project to help you.

Also understand that each genre has a different planning phase. Action - coding mechanics, RPG - storyline, Strategy - gameplay, Board-games - gameplay/rules, Word-games - depends on the direction your headed this could be anything, Sports - game/code mechanics, Sims - gameplay/rules/charts-game matrix.

Then once you have all this planned out, and how everything that will be in your overall game will interact, you can begin making content and coding. Also you can at first keep it simple like 1 - Player type/class, 1 - Monster/Mob and once you get those two working and interacting with each other, add in more later.

Hope this helps you out and lets you know what your getting yourself into. As to Foomer's comments on being sick of your game, you most likely will, but I actually like playing my new game Star Traders, I just hate looking at the code after this crunchof 27 days.

LJR
In response to LordJR

Hope this helps you out and lets you know what your getting yourself into. As to Foomer's comments on being sick of your game, you most likely will, but I actually like playing my new game Star Traders, I just hate looking at the code after this crunchof 27 days.

LJR

I hope I don't because this is gonna be a cool game, but I'm afraid I will.
I don't usually follow specific steps, except one:

Get the hardest part done first.

In most games I approach, there's a key (or two) to the core engine that really drives everything else.

My first BYOND project--which I abandoned in an undetermined state--was a test of special multi-tile mobs and their movement capabilities. I had to figure out a lot of algorithms for exactly how the mobs would move. That was the key to the project. (Unfortunately, I never developed much of a game around that, and it stalled.) The whole thing was sort of an exercise in proof-of-concept.

Incursion started much the same way: I built a name generator, figuring it would come in handy for a future project like an RPG, and was inspired by that to see how close I could come to a Risk-like map generated at random. The map generator was a whole new set of challenges, but it was the biggest key to that project. Now the game is progressing further, built on top of those key elements.

If I wanted to create a game like LordJR's Star Traders, for example, I'd work on the economic models first. Once I had all the algorithms planned out for how prices would rise and fall, the rest would be simply a matter of building up the game a piece at a time.

How would I handle an RPG? I'd probably build a very very rudimentary map and give chars a few quick stats, then I'd build the battle system. After the battle system would come everything else.

Leftley's Bombard: I'm willing to bet that landscape management (including icons, calculating elevations, etc.) and determining how to alter the land after a shot were the absolute toughest parts of what he did. He's been working on tank AI on and off lately, but that's actually comparatively easy. (Sometimes, though, harder tasks do pop up late in the development process.)

Tanks: I bet some of the oldest parts of that game are for tank movement, turret rotation, soldiers running around, walls that can be destroyed, and towers firing on things. A bigger piece would be Shadowdarke's map generator, which probably also came early in development. Otherwise it's been built up in stages: New weapons, new interfaces, new tank upgrades, etc.

It's been my experience in game programming that you get the hardest part out of the way first to see how feasible the entire game is. If you get the key code in place, it's possible to build around it; but if you can't get the key code to work, you'll get stuck early.

Lummox JR
The most important phase, in my opinion--and I think you'll probably go through several games before you start getting the hang of this--is sitting down and figuring out the basic framework you're going to use for your code. You can, with a little knowledge of DM, just dive right in and start throwing a game together without any prior planning... but things go astronomically more quickly, speedily, and smoothly if you develop an open-ended framework to build off of. The worst-case scenario is where you end up re-writing the exact same code for every single type of object that has similar properties; if you set it up well, in contrast, you need only write one set of code and you can create a huge variety of objects based on that code just by plugging in different variables and small, minor procs.
In response to Lummox JR
Tanks: I bet some of the oldest parts of that game are for tank movement, turret rotation, soldiers running around, walls that can be destroyed, and towers firing on things. A bigger piece would be Shadowdarke's map generator, which probably also came early in development. Otherwise it's been built up in stages: New weapons, new interfaces, new tank upgrades, etc.

As I remember, the map generator came along *very* early, before Tanks even existed. It was part of Darke Dungeon, and then Shadowdarke decided to make a quick game based on it.
Actually, it wasn't lack of planning as much as it was setting my sights too high. I started My Life as a Spy 10 months ago, as my very first BYOND game, and I'm still working on it. I imagine there are a couple of months left in the development cycle before I'll be relatively happy with it. I now consider MLAAS a thorn in my side, as I'm obsessed with finishing it, but really want to move on to my next projects.

I DO NOT reccommend starting off with a big project. I came to BYOND in smarty-pants mode. I had been playing computer games since Pong was in the arcades, programming for twenty years, and actually write code for a living, meaning I do hardcore programming every single day.

Oh sure, I would have been done with it long ago if I worked on it more than one day a week, but it still would have been months of time. More importantly, if I hadn't had a strong background in programming, it never would have gotten half as far as it has.

So my advice (do as I say, not as I do!) is to start small. VERY small. It's far more rewarding to write a tiny programming gem then a huge epic game that is rife with bugs, and forever unfinished.

After MLAAS is done, trust me, the games are going to be much simpler.
In response to Lummox JR
Lummox JR wrote:
Tanks: I bet some of the oldest parts of that game are for tank movement, turret rotation, soldiers running around, walls that can be destroyed, and towers firing on things. A bigger piece would be Shadowdarke's map generator, which probably also came early in development. Otherwise it's been built up in stages: New weapons, new interfaces, new tank upgrades, etc.

I had already been working on the map generator for Darke Dungeon before I decided to work on Tanks, so that was the easiest part (though I made a number of refinements to it because of features I wanted to include in Tanks.)

You are right that my first priority was getting the tanks, towers, and turrets working properly. Then came the projectiles. Those parts of the program have hardly changed since the first week of development.

The soldiers came much later, because I never intended for people to run around outside of their tanks. It took quite a bit of work to include them in such a late stage of development, and they are still not quite balanced right. If I had planned for them from the start, it would have been painless.

Another concept that is central to Tanks is the four team/rogue system. I want to update the Tanks team system, but the current system is so deeply enmeshed within the program, that I'll have to practically rewrite the game to make it happen.


The most important stage of development, in my opinion, is when you are still working on the concept, long before you even begin to code. You'll make little projects to test concepts, like Lummox JR mentioned above. I've written a hundred concept projects. However, before you write an actual game, you want to know how it works and what you want it to do. Without a strong concept and a guiding design document, your game will have no focus and will fall apart.

Brainstorm about your game, writing down everything that comes to mind no matter how silly or difficult it may seem. Then forget about it for a little while, at least get a full night's sleep before looking at it again.

Next time you look at it, refine your ideas and figure out how they fit together. Start working on the systems that happen behind the scenes. Don't worry too much about the actual code yet, unless you want to make a concept project to see how well something will work. You will probably want to stick to psuedocode, i.e. "chance to hit = my agility + my weapon modifier - (target agilty + target armor modifier)" instead of "hit_chance = src.agility + src.weapon.hit_modifer - (target.agility + target.armor.hit_modifier)"

You'll want to work out most of the math for your game in this stage. I've seen far too many people on BYOND put the cart before the horse and wait until their game is partially playable and filled with all sorts of features, then start asking people about ideas on combat system. They'll face the same problem I had with adding soldiers to Tanks, or worse yet, the more extreme problem I'm having with adding a more flexible team system to Tanks.

I find it very helpful to lock in my ideas by writing a design document. This document is much more organised than the randomly jotted ideas and notes that have come up to this point. While organising the design document, you'll also find places you might not have covered while working out your systems. Refine the document as often as you need to.

Now that you know what you want to happen, and more importantly how it will happen, you can start coding the actual game. Break the systems down into managable chunks and you'll be amazed at how easily you can solve problems that you thought were enormous.
In response to Skysaw
Yep I was here when you started MLAAS. It was very good in it's first tests better than anything I was able to do when I was a newbie, and I've looked up to you ever since.
In response to Shadowdarke
"refine your ideas and figure out how they fit together. "

I've had problems for lack of this before. In my third game ever created using BYOND, Distant World (after Experimentor and Ensya), I of course whipped up some graphics first so I could be motivated enough to continue working on it by staring at the graphics, conceived a few ideas that I thought would be fun to throw together into a game, and started building.

A few weeks later, the game was 95% finished, but I really had no way of finishing it because of some inevitably fatal flaws that were deep-rooted in the game, since I hadn't taken the time to think them out first. Really, a game should be fully playable in your mind before you start working on it in code.

The biggest problems with Distant World were, for one thing, lack of any way to win, and another, lack of anything interesting to do after you'd done everything :oP On top of that, the game would always get to the point eventually where you simply could not contain your colonists and they'd all start starving to death because you couldn't possibly get enough food for them all.

I'm still working on the game now, and I think up new ideas and possible solutions for those problems, but all in all, I still don't have it put together properly. The hardest part is making something that you can optionally do while you're waiting for your colony to produce stuff. For example, you land your base, setup the first structures, and what do you do while you're waiting for the first structures to finish building? Nothing! Well, that wouldn't be so bad if there were at least a helpfile. Maybe I could make a built in information center that alerts you after you land and starts telling you stuff...

Anyway, that's what happens...