10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
Go Back  Xtreme Visual Basic Talk > > > 10 Steps to Designing a Game


Reply
 
Thread Tools Display Modes
  #21  
Old 01-28-2003, 04:04 PM
crazycheetah's Avatar
crazycheetah crazycheetah is offline
Junior Contributor
 
Join Date: Apr 2002
Location: Sunny Southern California
Posts: 347
Default


Scripting would basically be a small programming language that the game would process. In other words it's a series of lines (or just one line) that the game's engine would read and do according to what it says. There's many advantages to this, though you lose a slight amount of speed (the speed loss is worth it though...)

For what it does: It does whatever the engine is set up to make it do... there are a great amount of possiblities you can put in a scripting system.
__________________
Code: PONG! | RPG! | Isometric RPG Map Editor!
Tutorial: IRC
Reply With Quote
  #22  
Old 01-29-2003, 06:09 PM
Optikal's Avatar
Optikal10 Steps to Designing a Game Optikal is offline
Codeaholic

Retired Leader
* Guru *
 
Join Date: Oct 2002
Location: Winnipeg, MB, Canada
Posts: 4,543
Default

Quote:
Originally posted by Kaluriel
we can all relate the the troubles of time travel
I dunno about you, but personally I haven't had much experience with time travelling
__________________
There are 10 types of people in this world, those that understand binary, and those that don't.
Reply With Quote
  #23  
Old 01-31-2003, 12:52 AM
Nerseus
Guest
 
Posts: n/a
Default

I think it's a good to divide the "tips for making a game" into two categories: tips for beginners and tips for experienced programmers. There are *totally* different tips for each group.

For beginners, you want something like:
1. Tweak existing code to see how things work
2. Play with sample programs and tutorials to learn basic concepts
3. Learn Debug.Print and MsgBox quickly, to help discover how the code is working and when
4. Do NOT try to write the next Quake 3, Warcraft 3, or Balders Gate 3
5. Jot down *everything* - what you want in a game, what you don't, etc.
6. Save often and save multiple projects. Chances are you'll change some code, break something, and wish you had your old version back
7. Try and listen to the "experts" on the forums - if they say "don't use a timer" then don't use a timer
8. Practice basic coding skills (indentation, comments, etc.)
9. Know how to use UDTs, classes, etc. before you decide which one to use
10. Finish at least ONE game before moving onto the next
11. Most important, don't write a map editor. Please, oh please, no more map editors. Figure out what game you want before you write tools (unless you're just experimenting with how things work)

For the more experienced programmer (a lot more planning):
1. Write sample apps to prove out your concept. If you plan on a tile engine, figure out the structure first
2. Write down everything you want, then scale it down to those features that will get the game running. It's easier to add features later, especially if you know what they are (so you can plan in advance). But do NOT get too bogged down with implementing everything in version 1.
3. Get to know your tools. If you're using DirectX, write a good error trapper/reporting/logger first so that you can debug easier later.
4. Design the layout of your game with pseudo-code, UML, or <fill in the blank>.

...you don't need more than 4 steps, you're experienced, right?

I like to start each project with a mix of UML and pseudo-code. The UML keeps me from getting into the details too much. If I start typing in class names and properties and such, I start thinking about how the code will work instead of concentrating on what the application as a whole need.
After I have the basics worked out (what the major objects are - which could be classes or UDTs), I write it in pseudo code, with comments as placeholders to be filled in later.

I know many of the "newbie" programmers think that all the planning is wasted, but you will learn one day, you will learn...

-nerseus

(hmm... 5 smilies, my personal best)
Reply With Quote
  #24  
Old 01-31-2003, 09:14 AM
Machaira's Avatar
Machaira10 Steps to Designing a Game Machaira is offline
Jedi Coder

* Expert *
 
Join Date: Aug 2002
Location: Abingdon, MD
Posts: 3,438
Default

Although your beginner tips aren't really specific to game programming, they have merit. It's amazing how many newbies are trying to make games without using proper coding techniques and without knowing the language.

As for the more experienced - I'm not sure if I agree with the writing sample apps first. If you're experienced you should have a good idea how well your concept will work. I guess whatever works for you though. The biggest thing for an experienced person is creating a good design doc. Too many experienced programmers (myself included at times) think they don't need a design doc, that they can just write the game. I'm sure even John Carmack and the like use design docs, so how anyone can justify not having one is beyond me.
Reply With Quote
  #25  
Old 01-31-2003, 11:16 AM
Nerseus
Guest
 
Posts: n/a
Default

I guess I was taking on "experienced" to mean experienced in programming, but not necessarily game programming. In that regard, it's useful to write (and keep) small test apps to prove out a piece of technology. Beginners tend to write a test app and just keep tweaking it, eventually turning what was a test app into a "game". About halfway through, they realize a major design mistake (such as how they store data or graphics information) and have to quit that project and start over.

I agree with a design document. I wouldn't get it too detailed though. Keep it around as a driving force so you don't lose sight of what you're writing but don't put so much detail into it becomes out of sync too easily.

Even a game like Pong should have a simple design document, IMO. It's good to decide up front what features you want to put in rather than add everything on the fly. For instance, do you want barriers for the ball to bounce off of? Do you want the ball to just pass off the left or right or go between two "goal posts"? Do you want multiple paddles? Maybe you want it to be a shooter-pong with regular and homing missiles. If you plan these things up front, it will go a lot smoother. And you can always put the "blue sky" ideas in a section labeled "if I have time" rather than trying to put them in the game from day 1.

-Nerseus
Reply With Quote
  #26  
Old 01-31-2003, 01:27 PM
Tintin's Avatar
Tintin Tintin is offline
Regular
 
Join Date: Jan 2003
Location: Netherlands
Posts: 50
Default

Quote:
7. Try and listen to the "experts" on the forums - if they say "don't use a timer" then don't use a timer
Quote:
11. Most important, don't write a map editor.
Actually I was about to start on writing a map editor for my game, but I suppose I better listen to the experts. Right now I'm using random generated maps (which works fine) but I thought it would be cool creating some maps of my own.
Why do you advise not to write one? It doesn't seem that hard... but perhaps I'm underestimating the difficulty. (I have to admit I have no idea what I would get into if I were to start on one, especially since the game uses a hexagon map)
Reply With Quote
  #27  
Old 01-31-2003, 01:37 PM
Nerseus
Guest
 
Posts: n/a
Default

It's not that map editors are hard - it's quite the opposite. It's that you can spend a year writing a map editor while all these great game ideas float around in your head, but you'll never get to writing your game.

Having said that, if you're writing the type of game that needs a map then you'll want to write a map editor first, at least a crude one. The difference is that you should *first* think about the game and what you want it to do (scrolling, one screen at a time, layers, etc.) then write the editor to get you a map that the game can use. The editor is not the game, it should just be a tool.

A common problem is writing a map editor then thinking "oh, this code is mostly what my game needs" and then proceeding to hack the editor into a game. If you keep the two separate, you'll have a much better time. If you don't, you'll end up with a mess or a LOT of rework later.

-nerseus
Reply With Quote
  #28  
Old 01-31-2003, 05:01 PM
Machaira's Avatar
Machaira10 Steps to Designing a Game Machaira is offline
Jedi Coder

* Expert *
 
Join Date: Aug 2002
Location: Abingdon, MD
Posts: 3,438
Default

Quote:
Originally posted by Nerseus
I guess I was taking on "experienced" to mean experienced in programming, but not necessarily game programming. In that regard, it's useful to write (and keep) small test apps to prove out a piece of technology. Beginners tend to write a test app and just keep tweaking it, eventually turning what was a test app into a "game". About halfway through, they realize a major design mistake (such as how they store data or graphics information) and have to quit that project and start over.
That's why you need a design doc.

Quote:
Originally posted by Nerseus
I agree with a design document. I wouldn't get it too detailed though. Keep it around as a driving force so you don't lose sight of what you're writing but don't put so much detail into it becomes out of sync too easily.
If you put everything in it and stick to it it won't get out of sync. That's the whole reason for it.
Reply With Quote
  #29  
Old 02-02-2003, 09:44 PM
Optikal's Avatar
Optikal10 Steps to Designing a Game Optikal is offline
Codeaholic

Retired Leader
* Guru *
 
Join Date: Oct 2002
Location: Winnipeg, MB, Canada
Posts: 4,543
Default

Quote:
Originally posted by Nerseus
6. Save often and save multiple projects. Chances are you'll change some code, break something, and wish you had your old version back
In case some of you don't know about it, Visual Sourcesafe (VSS) is great for this. You "check-in" and "check-out" your code. And it maintains a version history with rollback capabilities.

For example, every time you have a compilable version of your project, you should check it in to VSS and then check it out again before adding new features to your project. This will allow you to rollback to this version of the code at any future date easily. And it doesn't just store the last version checked in. VSS will allow you to rollback to ANY version of your code that you ever checked-in. Just remember to check-in/check-out your code every time you have a compilable version, and you never have to worry about breaking your code.

Not sure if VSS comes with all versions of VB, I use VB6 Enterprise here and VSS is included, not sure if it comes with all versions though.
__________________
There are 10 types of people in this world, those that understand binary, and those that don't.
Reply With Quote
  #30  
Old 02-02-2003, 11:36 PM
Nerseus
Guest
 
Posts: n/a
Default

I'm not sure how many people have SourceSafe, legally at least. I've always used it at work and couldn't live without it.

I like to actually keep more than one project sometimes, especially if I'm learning a new technology like Direct3D or DirectSound. Instead of having one "test" project that keeps evolving, I like to keep multiple test projects, each with one or two simple tasks. That way, if I figure out how to get translucency to work (for example), I can save that project and then work on adding inverse kinematics someplace else. I may want translucency and IK in my final project, but by keeping projects separate, I can go back to the translucency project later and make tweaks, to play around with different blend factors and such.

At work, I have about 20 projects ranging from ADO to XML to Databound grids. The ADO one has gotten a little big for its britches and has about 10 different connection strings commented out so that I don't lose them (also a good idea - comment instead of delete good code that isn't used anymore).

A friend of mine has another good idea. He creates what he calls "magic files". They're just text files, categorized into separate folders. Each one has a few lines of code and a lot of comments. There are tools on the market to do this as well - VS7 (.NET) even allows you to drag code to the toolbar to save in your projects! Regardless of how you do it, saving "old" code is a good practice.

-nerseus, he who types a lot...
Reply With Quote
  #31  
Old 02-03-2003, 02:24 AM
NoteMe's Avatar
NoteMe NoteMe is offline
Contributor
 
Join Date: Nov 2002
Location: Norway
Posts: 919
Default

About the map editor comment: I have made a working car game. And I made a map editor. Nothing fancy, just a working app. It took me less then an hour to put togheter from scrach and I have never made a map editor before. And it has saved me so much time when I wanted to build map 2, 3, and 4...
__________________
- I'm trying to be friends with everyone.
- So please try to be my friend too...
Reply With Quote
  #32  
Old 02-14-2003, 03:19 PM
AtonalPanic AtonalPanic is offline
Contributor
 
Join Date: Jul 2002
Location: Houston, Texas
Posts: 445
Default

Reply With Quote
  #33  
Old 03-07-2003, 11:59 AM
cjsworldmaker cjsworldmaker is offline
Newcomer
 
Join Date: Mar 2003
Posts: 2
Unhappy Design steps before code

What is a good set of steps to follow before any coding begins. I'm working on an RPG and I want it as complex as possable (magic, science, psionics, ect..). I've been working on the design alone for 11 years and despirately need a good set of steps to follow. At the moment, with no steps, everything gets done randomly. I start working on one part of the game and just run into a wall created by the absense of another part of the game, so I begin that part and it comflicts with the previous part. It's turns out to be a coninuous loop of adding removing and re-adding. Can anyone help?
Reply With Quote
  #34  
Old 03-07-2003, 12:11 PM
Machaira's Avatar
Machaira10 Steps to Designing a Game Machaira is offline
Jedi Coder

* Expert *
 
Join Date: Aug 2002
Location: Abingdon, MD
Posts: 3,438
Default

If your design document is fairly deep, you should be able to construct the base objects (entity, map, items, spells, whatever) and fit them together fairly easily. I'm assuming you have your combat and magic systems well thought out. Depending on the style and type of graphics you're using, that could be anywhere from relatively easy to extremely difficult. Do you feel like posting your design doc to let us see what you've done? The design doc for my RPG is already over 20 pages and it just describes the base objects and a bit of the combat and magic systems. It doesn't include graphics or scripting yet. I have a general plot but no specifics so there's another dozen pages or so as well.
Reply With Quote
  #35  
Old 03-13-2003, 02:24 PM
cjsworldmaker cjsworldmaker is offline
Newcomer
 
Join Date: Mar 2003
Posts: 2
Default Design Document

Quote:
Originally Posted by Machaira
If your design document is fairly deep, you should be able to construct the base objects (entity, map, items, spells, whatever) and fit them together fairly easily. I'm assuming you have your combat and magic systems well thought out. Depending on the style and type of graphics you're using, that could be anywhere from relatively easy to extremely difficult. Do you feel like posting your design doc to let us see what you've done? The design doc for my RPG is already over 20 pages and it just describes the base objects and a bit of the combat and magic systems. It doesn't include graphics or scripting yet. I have a general plot but no specifics so there's another dozen pages or so as well.
I don't have a design document, just a stack of ideas with no particular order. I can't seem to come up with a set of steps that I can stick with. Because of this dis-ordered method of designing I often lose my notes, and without steps it is fairly hard to replace them. My true designing only begun a few years ago, before that I was too young (I'm 18 now) to really be able to do much much less care.
Reply With Quote
  #36  
Old 04-01-2003, 08:30 AM
jf0rce jf0rce is offline
Junior Contributor
 
Join Date: Nov 2002
Posts: 211
Default

I tried to create a game myself, got almost done with it, a MORPG too... Learned alot by making it..To bad my computer crashed and burned (total format nessecary) and I didn't have a back-up

Think I'm gonna give it a go some time soon again ... , sure as hell learned alot by making the game
Reply With Quote
  #37  
Old 04-09-2003, 05:00 PM
pie4all88 pie4all88 is offline
Newcomer
 
Join Date: Apr 2003
Posts: 2
Default

Quote:
Be sure to eventually include an FAQ, About the game, dev team page, and a forum
Sorry if this does not pertain to the topic, and if it is a little late, but...
How exactly do you get a forum for your website? I have yet to find a free one. And I want to distribute my game

If you're interested in developing for a PDA (like the Palm OS), check out Kyle's Quest 2 at www.crimsonfire.com
Reply With Quote
  #38  
Old 04-09-2003, 09:41 PM
JimCamel's Avatar
JimCamel10 Steps to Designing a Game JimCamel is offline
Mostly Absent

* Expert *
 
Join Date: Jun 2002
Location: Christchurch, New Zealand
Posts: 2,006
Default

That would depend on what your webhost offers, but usually you need at least PHP and an SQL or MySQL database. There are sites which host forums too.
__________________
Sometimes it happens feelings die, Whole years are lost in the blink of an eye
We once had it all but event conspired, Sometimes
Now that it's over, it is through, It gets me everytime I think of you
Sometimes It happens, feelings die, Sometimes
Reply With Quote
  #39  
Old 04-10-2003, 08:12 PM
pie4all88 pie4all88 is offline
Newcomer
 
Join Date: Apr 2003
Posts: 2
Default

Hmmm... I use a free webhost--provided by earthlink, my internet company. I'll check into it; thanks.
Reply With Quote
  #40  
Old 04-19-2003, 12:39 PM
intrest86 intrest86 is offline
Newcomer
 
Join Date: Apr 2003
Posts: 5
Default

Quote:
Originally Posted by pie4all88
Hmmm... I use a free webhost--provided by earthlink, my internet company. I'll check into it; thanks.



If you do not have any luck with earthlink, I have two suggestions:

1) Anyone can get a forum at www.ezboard.com, but unless you are willing to pay a little bit you will have to deal with pop-ups and large banner ads

2) Try contacting the nice webmaster of www.evula.org. He hosts multiple sites for people, free of charge, and also gives each site the ability to have forums on his forum page, forums.evula.com.
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game 10 Steps to Designing a Game
10 Steps to Designing a Game
10 Steps to Designing a Game
 
10 Steps to Designing a Game
10 Steps to Designing a Game
 
-->