create simple game engine

Hi all.

I'm new to the newsgroup and wanted to introduce myself. My name is Justin
and I've
been programming in visual basic for 7 + years and in DirectX for visual
basic 8 for a few years now having completed several games. Small ones such
as
50 to 100 subs and a few thousand lines of code all in modules/forms etc.

Like most new game programmers, I jump in amd never really understand the
concept of a game engine. I now realize that I need to create a game engine
and
need some help on getting started.

However, there is a twist, in my engine, I only need to keep track of these
components: input devices, moving, timing, and sound. I do not have to deal
with graphics at all. Graphics aren't my job at all. So, this game engine
will
be quite easy to do since I don't need to bother with graphics.

In college, all my training was in c++ and advanced object oriented concepts
such as classes, inheritance, polymorphism, etc. so I am quite familiar with
these concepts. Most game engine tutorials I've read online are dealing with
c++ which I don't use. I chose Visual Basic over c++ to develop in since I
really enjoy the VB syntax/language.
I am using visual basic 6 professional and dx 8 and have no plans to move to
vb.net any time soon. With this in mind, how should I construct my classes
in vb 6 and develop this simple model of a game engine?

In other words, I have
all the knowledge and know the syntax but don't know how to write a game
engine. If someone could guide me a long a little in outlining an approach
to developing this game engine, regardless of what language you use, I know
I could flush it out. I just need some direction and basic concepts to keep
in mind.

kind regards,
Justin

"Justin Daubenmire" <justind@cboss.com> wrote in message news:<vlun5bok0gpae2@corp.supernews.com>...
> However, there is a twist, in my engine, I only need to keep track of these
> components: input devices, moving, timing, and sound. I do not have to deal
> with graphics at all. Graphics aren't my job at all. So, this game engine
> will be quite easy to do since I don't need to bother with graphics.

Well, it definately will be EASIER, but I don't think it'll be a walk
in the park. :-)

> In college, all my training was in c++ and advanced object oriented concepts
> such as classes, inheritance, polymorphism, etc. so I am quite familiar with
> these concepts. Most game engine tutorials I've read online are dealing with
> c++ which I don't use. I chose Visual Basic over c++ to develop in since I
> really enjoy the VB syntax/language.

Well, I think you like it more because you are accustomed to it, but
it really hampers you when it comes to development. See below.

> I am using visual basic 6 professional and dx 8 and have no plans to move to
> vb.net any time soon. With this in mind, how should I construct my classes
> in vb 6 and develop this simple model of a game engine?

Since you are using VB6 and not VB.NET you're really limited in what
you can do. DirectX only provides a subset of features via COM for VB6
development. I know this isn't what you want to hear, but I'd
recommend you abandon VB and move to C++. Since you said you learned
it in college, it won't be totally foreign to you AND you'll have
access to the entire DirectX API. No matter what you do, you won't
have that in VB6 (there are ways, actually, but it would require
writing some C++ code, which would pretty much nullify the benefit of
sticking with VB6).

> In other words, I have
> all the knowledge and know the syntax but don't know how to write a game
> engine. If someone could guide me a long a little in outlining an approach
> to developing this game engine, regardless of what language you use, I know
> I could flush it out. I just need some direction and basic concepts to keep
> in mind.

Well, it sounds like you are working on disparate parts of the engine.
Input and sound can be developed independant of the rest of the engine
(to some extent; that is, they'll have loose coupling with the rest of
the engine). But when it comes to moving and timing, each subsystem
usually handles this stuff itself. Look at the pseudo-code below:

GameLoop()
while( user hasn't quit )
query input
play sounds
process movement & collision
process enemy AI
...more junk...
draw graphics

Under "process movement", for example, it has to know how much time
has elapsed since the last update so it can determine how far things
have moved. In C++, this usually involves just calling something like
GetTickCount() and comparing it with the last update (or, conversely,
you can pass in the elapsed time). Under "query input," the input may
have to know how long a user has held down a certain key so it can
know the start auto-firing (or whatever). The "process enemy AI" might
only allow itself to "think" for a few milliseconds before returning
control to the loop. All these things require timing and the
components usually just determine what to do based on the elapsed
time. So I don't really know how you'd develop a timing component, as
this is usually handled by each component itself. Of course, you may
be doing something that makes a timing system make sense, such as a
universal game clock.

The collision is usually tightly coupled with the location of objects
in the world, so you'll probably also have to handle that along with
movement. Collision is no easy task, so you could have your hands full
with that alone. Additionally, you might want to determine what is
visible and what is not, so you can ignore updating collision on
non-visible AI's (but you may have to, to determine if they move into
the visible frustrom). So you'll have some coupling with the graphics
system as well.

Since you said you've developed games before, you should know the
basic concepts, such as games run continuosly in a loop, so plan for
that. Other than switching to C++, I can't think of what else to say
without knowing more about the type of game you're targetting your
engine for (for example, will it be for an FPS or a turn-based
strategy game?). If you have more specifics, please give them. :-)

Good luck! :^)

Hi.

First of all, thank you so much for your reply.

---snip---
without knowing more about the type of game you're targeting your
engine for (for example, will it be for an FPS or a turn-based
strategy game?). If you have more specifics, please give them. :-)
---snip---

You had mentioned visual basic only having a sub-set of directX and you are
entirely correct. The sub set of components that DirectX provides visual
basic 6, however, is all I need. To explain... I create audio based games
for the blind computer user. So the only DirectX component I need is really
DirectSound since I only use sound buffers, some of them 3d sound, and
DirectInput for external devices such as joysticks/keyboards etc. Other than
that, I don't need to much from dx. Perhaps DirectPlay down the road but not
immediately.

Think of my job like this... programming the exact style of games you
program: collision detection, reaction times, enemy attack rates, maps,
quests, etc. minus the graphics. It's not that difficult when you really
think about it... your portraying the concepts via sound to the blind user
rather than graphics. Whether you see yourself walking in a swamp, or hear
it, you know your in a swamp and the programmer knows your at x5,y3 etc.

Any how, I am wanting to develop a game engine that will help me create FPS
games and RPG games. This may be asking for the world but if possible,
perhaps strategy games as well. If not, definitely FPS and RPGs. I would
like to read in everything from files, meaning, level creation,
monsters/objects and their properties, and any other object I can do via a
file. I have never done this but have read online that as much as you can
read in from files, do it. Don't hard code in stuff in your code. The
reason, from what I read, is so you can easily adjust the game difficulty
etc.

So, I am following your pseudo code, which is exactly the type of help I
need (thank you) =), so if you can help me understand how to use simple
files to construct objects in the game: levels, monsters, weapons, etc., via
pseudo code I would be indebted =).

kind regards,
Justin

That is really interesting...writing games for the blind. I don't have
anything to add to frecklefoot's comments, but I think it's really neat what
your doing.

regards,
dn


> You had mentioned visual basic only having a sub-set of directX and you
are
> entirely correct. The sub set of components that DirectX provides visual
> basic 6, however, is all I need. To explain... I create audio based games
> for the blind computer user. So the only DirectX component I need is
really
> DirectSound since I only use sound buffers, some of them 3d sound, and
> DirectInput for external devices such as joysticks/keyboards etc. Other
than
> that, I don't need to much from dx. Perhaps DirectPlay down the road but
not
> immediately.
>

Hi.

Thanks. It's a hobby I have and blind folks love the games I write. Most are
just traditional arcade style games such as a galaxian style game, a lay
pipes that drip water game, a hunter game, etc. All are arcade style games,
how be it, are quite top notch. I do have my own sound design team, content
writers, adn 2 programmers -- myself and another coder. However, I want to
take the company a step furhter/notch up adn get into FPS and RPG style
games. This requires me to stop makign kiddie games like arcade style LOL I
need to write an actual full blown game engine with level editor etc. which
will mean some hefty work, even if it is audio games, but I need some
direction by providing pseudo code examples of how the major companies do it
for the sighted and anyone that can help me out please do so =).
frecklefoot's has done a great job in helping me understand the main loop
of a game and some other interesting concepts he shared in a prev post. His
help inspired a few more questions. I had asked in a reply...


Any how, I am wanting to develop a game engine that will help me create FPS
games and RPG games. This may be asking for the world but if possible,
perhaps strategy games as well. If not, definitely FPS and RPGs. I would
like to read in everything from files, meaning, level creation,
monsters/objects and their properties, and any other object I can do via a
file. I have never done this but have read online that as much as you can
read in from files, do it. Don't hard code in stuff in your code. The
reason, from what I read, is so you can easily adjust the game difficulty
etc.

So, I am following your pseudo code, which is exactly the type of help I
need (thank you) =), so if you can help me understand how to use simple
files to construct objects in the game: levels, monsters, weapons, etc., via
pseudo code I would be indebted =).

kind regards,
Justin

> That is really interesting...writing games for the blind.

You have 2 options in your object/monster/player attribute mechanisms

static structures (called records in basic??)
or
dynamic structures (usually implemented via pointers to optional structures or
a link list of attribute nodes)
(inventory for example is usually a link list of 'inventory' objects)

example structure

monster
{
String Name[32];
Float Xpos, Ypos, Zpos; // movement data
Float Facing, Velocity;
Interger Hitpoints, Strength; // object attributes (static)
Integer BehaviorState, Target;
Integer ModelShape;
Integer CurrentAction, CurrentSound;
Integer Inventory[10]; // index into
Inventory object array -- -1 = Nil/Empty slot
}


Frequently arrays of each structure type are used and and index can be used in
place of pointers
(does Basic have a true pointer yet -- maybe a handle type could be used
the same way)

For file storage of a games objects could simply be a record read/write (easy
if static records used)
(file is an array of records)
For a simple game you simply load all the objects in a file at the start and
save them all on 'Save'

If you create new objects you find an empty array slot (using some inuse
flag) and fill in the appropriate
data. Removing objects is similar -- just make the inuse flag as EMPTY , and
the running program
test this flag when running (ignoring records marked as not inuse).

You will have several different records, so its easiest to have seperate files
for each record/structure type.
All the files together form a game instance database (files data is
interdependant)
If this was C++ it wouldnt be too hard to have all record types put in the
same file. If you really want
to do that, you could make the file a text file and use print/write/read to
writeout and readin record data in
a comma quote format

M,1,"MonsterX",10.333,12.334,0.000,0.000,1.000,100 ,45,7,33,2,3,0,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

^^^ the first M signifies the following data is a Monster record (and should be
inserted into that array...)
the first number is the array index (preserving the array slot the data
resides in)
the rest of the data matches the example structure/record seen above


Since you are using Basic it should be simple to build 'Visual' programs to
edit the database files - just remember the
data is interdependant between the different records (like monster has pointers
to inventory objects in their own array..)


Since all data is located in simple arrays, its just a matter of using
subscripts to access -- example gettinga list of inventory items belonging to
a monster M :


for I=1 to 10 // loop all inventory slots
begin
index = MonsterArray[M].Inventory[i];
if index <> -1 then // if not empty slot
begin
print InventoryArray[index].Name
// do other stuff with inventory here....
end
end




You are lucky that you are creating a game with limited expansion as you can
make use of
fixed arrays (which still can be quite large) and the files shouldnt be too
large (not take too long to
load even if they are text)



BTW if you are looking for sound effects/ sounds a good source may be the
free/shareware/sample games
that you can find onliine (If this is a commercial project then you have to
purchase/ license sounds...)
Games you have purchase also frequently have nice directories full of useful
..wav .mid .ogg .mpg files






Justin Daubenmire wrote:

> Hi.
>
> Thanks. It's a hobby I have and blind folks love the games I write. Most are
> just traditional arcade style games such as a galaxian style game, a lay
> pipes that drip water game, a hunter game, etc. All are arcade style games,
> how be it, are quite top notch. I do have my own sound design team, content
> writers, adn 2 programmers -- myself and another coder. However, I want to
> take the company a step furhter/notch up adn get into FPS and RPG style
> games. This requires me to stop makign kiddie games like arcade style LOL I
> need to write an actual full blown game engine with level editor etc. which
> will mean some hefty work, even if it is audio games, but I need some
> direction by providing pseudo code examples of how the major companies do it
> for the sighted and anyone that can help me out please do so =).
> frecklefoot's has done a great job in helping me understand the main loop
> of a game and some other interesting concepts he shared in a prev post. His
> help inspired a few more questions. I had asked in a reply...
>
> Any how, I am wanting to develop a game engine that will help me create FPS
> games and RPG games. This may be asking for the world but if possible,
> perhaps strategy games as well. If not, definitely FPS and RPGs. I would
> like to read in everything from files, meaning, level creation,
> monsters/objects and their properties, and any other object I can do via a
> file. I have never done this but have read online that as much as you can
> read in from files, do it. Don't hard code in stuff in your code. The
> reason, from what I read, is so you can easily adjust the game difficulty
> etc.
>
> So, I am following your pseudo code, which is exactly the type of help I
> need (thank you) =), so if you can help me understand how to use simple
> files to construct objects in the game: levels, monsters, weapons, etc., via
> pseudo code I would be indebted =).
>
> kind regards,
> Justin
>
> > That is really interesting...writing games for the blind.

"Justin Daubenmire" <justind@cboss.com> wrote in message news:<vm2b3da09i7n54@corp.supernews.com>...
> Any how, I am wanting to develop a game engine that will help me create FPS
> games and RPG games. This may be asking for the world but if possible,
> perhaps strategy games as well. If not, definitely FPS and RPGs. I would
> like to read in everything from files, meaning, level creation,
> monsters/objects and their properties, and any other object I can do via a
> file. I have never done this but have read online that as much as you can
> read in from files, do it. Don't hard code in stuff in your code. The
> reason, from what I read, is so you can easily adjust the game difficulty
> etc.

I am not sure how a sightless user would control an FPS, but I assume
you know how. :-) They are usually very visual games. An RPG would be
very workable, however.

> So, I am following your pseudo code, which is exactly the type of help I
> need (thank you) =), so if you can help me understand how to use simple
> files to construct objects in the game: levels, monsters, weapons, etc., via
> pseudo code I would be indebted =).

I think the best thing you can do right now (early development) is to
see what others have done and how. For RPG's, buy copies of
NeverWinter Nights and Baldur's Gate (though it's fairly old). NWN has
a scenario editor where you can create your own adventures, and you
can even write custom code using a C-like script. BG allows you to
specify AI for characters (and I think monsters). Seeing how they do
it from the user standpoint in those games should give you loads of
ideas of how and what you want to do in your game.

After that, you should ask yourself what type of things do you want in
files and why. For example, do you want the AI behavior stored in
files? Why? (So a level editor or game designer can change them
without the help of a programmer). Why not? (So users can't "hack" the
game). Here's a short list of things you could potentionally store in
text files:
o AI behavior on a per-character basis
o Character description (what Eternal Vigilance discussed)
o Level description (though this would probably be better represented
in a binary file for complex levels)

Things better suited for binary files:
o Graphic files (though you said you won't have any, perhaps sighted
users might find them useful, for just even a splash screen of some
sort)
o Sound files
o Levels
o Save game files

I think the best thing you can do is hard-code things in code _first_
as a "proof of concept" just to get things working. Then, before you
get too far, determine which things you'd like to have in files so
they are easily modified without programmer intervention. This will
probably involve creating a custom parser or using an existing one (I
hear Lua is excellent).

This is where things get tricky. As your programmers add features to
the game, they will also have to add features to the script language
(or commands to parse if it is just a text file with attributes). At
this point you'll have two or more branches of development that must
be kept in sync--letting them fall out of sync may result in some
behaviors that cannot be scripted--they can only be hard-coded. The
pertinent members of your team will have to be kept up to date on
features and how they are specified. For example, "The 'fozz' command
no longer works with floats. All numbers must be integers or else your
monitor will implode." Email is a good way to keep people up to date,
but all changes should be recorded in a doc of some kind so new
members can get up to speed quickly.

Tip: use tags in your scripts--it'll make them much easier to debug.
The tags can work even in binary files (they are actually ESPECIALLY
useful in binary files). For example:

[Name]Kyle
[Class]Fighter
[Hobby]Knee-carving

As opposed to:

Kyle
Fighter
Knee-carving

Using the tags makes the file bigger, but allows the data to be input
in any order. Without the tags, attributes can only be specified by
position in the file, which is very error-prone. The version with
tags could be represented this way:

[Class]Fighter
[Hobby]Knee-carving
[Name]Kyle

And still work. Some things may still be position-dependant, but the
fewer the better. The version without tags would HAVE to stay in the
order expected or wind up in parse hell.

Tags are especially useful in binary code, such as save-game files,
where you are reading in large chunks of numerical data that only
makes sense to the code. If you are reading in an enemy AI, for
example:

-1, -1, 5, 52.3, 997.2, 222

it is just a stream of numbers. If something comes in wrong or a
buffer is overloaded, you'll have little idea where the problem is.
But if you use tags:

[Guard]-1, -1, 5, 52.3, 997.2, 222

And the next AI comes in as this:

ard]-1, -1, 5, 52.3, 997.2, 222

You know you have an error in the save of the previous AI (in reality,
you'd probably just see the "ard]" part first and realize you have an
error, but whatever...).

So, to recap, I recommend this plan of attack:
o Use NWN and BG and see how and what they store in files
o Modify NWN and BG games to get a feel for how the files are used
o Hard-code a basic set of features
o Determine what you want in files
o Break features out to files
o Use tags in your files

As to WHAT you put in your files, it all depends on what kind of
feature it is. For example, a level file would have a description of
the level (layout of buildings, walls, placement of enemies, character
enter point). And it depends on what features you have (for example,
your characters may have an optional "shimmer" effect). I think once
you and your team decide on what features you want, it'll be easy to
come up with file formats.

If you have any questions about how to implement a specific entity in
a file, please post again (or better yet, just hire me). :-)

Good luck! :-)

Hi.

Thank you so much for your reply eternal vigilance smile. Structures in VB
are called types such as:

Public Type Monster()
Name as String *30
AttackRate As Integer
....
End Type

then you can declare a dynamic array of that type such as

Public AllMonsters() as Monster

and populate it at runtime. All arrays in VB can be created dynamically at
runtime so there is no need to have a static length array for any object in
the game. As you explained, a person can use a
pointer/index to the various monsters in that array to kill them/remove them
or create them/add them.
*** questions ***

1. Do most game
programmers keep Structures, such as the monster example, static or
dynamic? Is it just a personal preference?

2. Would you suggest that most game developers use an actual database, such
as
an MS Access db, to store all character/monster/ object relationships
instead of a flat file? I.E monster1 has an inventory of a gun. So, in the
db tblMonster has a record of Monster1 with a MonsterID of 3 which is linked
to tblInventory which has a record called Gun which has a field/foreign key
called MonsterID pointing to MonsterID 3 in tblMonster etc. keeping track of
the monster and his inventory etc.

3. One thing I am trying to keep in mind, is developing tools that I will
use such as a level editor to help construct and edit the difficulty of the
game. Can you illistrate how I might use a level editor to construct a level
in the game and the monsters/inventory you can find etc. and how I would
read those saved settings into the game and construct it via pseudo code and
just with a simple example?

4. I am having difficulty keeping separate the concept of the game engine
and the code that actually develops the game. Can you explain to me some
logic to help me isolate the difference between the two? In other words, if
I make a game engine, I want to be able to use a level editor to construct
new games without changing much of my code. Is this an ideal that just isn't
fact in game programming? Is it more involved than that? You have a game
engine but have to change lots of your code for a new game and you just
can't use a level editor to create a new game using your existing game
engine? Does the engine change with each game? How much of the code is
changed to make a new game? 10%? 80%? etc.


kind regards and thanks for the help,

Justin

You have 2 options in your object/monster/player attribute mechanisms

static structures (called records in basic??)
or
dynamic structures (usually implemented via pointers to optional
structures or
a link list of attribute nodes)

"Frecklefoot" <chris@bucketobits.com> wrote in message
news:dfd57bb5.0309120635.5d4ebe3f@posting.google.c om...
> "Justin Daubenmire" <justind@cboss.com> wrote in message
news:<vm2b3da09i7n54@corp.supernews.com>...


I am not sure how a sightless user would control an FPS, but I assume
you know how. :-) They are usually very visual games.

LOL all games are very visual =) FPS is no prob via sound again, you just
portray the exact data via sounds that you portray via graphics. It's that
simple believe it or not.

I think the best thing you can do right now (early development) is to
see what others have done and how. For RPG's, buy copies of
NeverWinter Nights and Baldur's Gate (though it's fairly old).

Not to be an idiot here but... Am blind so that probably won't work if you
are asking me to view some sighted games. However, your not to fault if that
is the case I haven't stated I'm blind prior to this if recalling correctly.
Basic pseudo code/concepts via email is the best source of learning for me,
text -- a blind mans best friend =), Like what you showed me with the tags,
that is 100% exactly the type of info I need =).



I think the best thing you can do is hard-code things in code _first_
as a "proof of concept" just to get things working.

hmmm. sounds like a great teaching tool/idea. thanks!

Then, before you
get too far, determine which things you'd like to have in files so
they are easily modified without programmer intervention.
again, great advice, thanks!

This will
probably involve creating a custom parser or using an existing one (I
hear Lua is excellent).

Lua? Is it some sort of free tool/script editor or something? Have a website
to it?

This is where things get tricky. As your programmers add features to
the game, they will also have to add features to the script language
(or commands to parse if it is just a text file with attributes). At
this point you'll have two or more branches of development that must
be kept in sync--letting them fall out of sync may result in some
behaviors that cannot be scripted--they can only be hard-coded. The
pertinent members of your team will have to be kept up to date on
features and how they are specified. For example, "The 'fozz' command
no longer works with floats. All numbers must be integers or else your
monitor will implode." Email is a good way to keep people up to date,
but all changes should be recorded in a doc of some kind so new
members can get up to speed quickly.

thanks for the heads up and all the tag info below (snipped most out)...
very useful information. Thanks!

So, to recap, I recommend this plan of attack:
o Use NWN and BG and see how and what they store in files
o Modify NWN and BG games to get a feel for how the files are used
o Hard-code a basic set of features
o Determine what you want in files
o Break features out to files
o Use tags in your files

excellent! thanks!

If you have any questions about how to implement a specific entity in
a file, please post again (or better yet, just hire me). :-)

My only question is... see my prev post on how i am having trouble keeping
the concept of a game engine separate from code for the actual game and
reusing the game engine to make new games. If you are serious about being
hired, contact me off list and we'll chat since I do contract sighted game
developers to help write games.

kind regards,
Justin

"Justin Daubenmire" <justind@cboss.com> wrote in message news:<vm3p1iadvtt346@corp.supernews.com>...

First off, sorry for assuming you were sighted. It was just an
irrational assumption on my part. Do you have any sighted staff
(you mentioned running a company)? They might be able to get the
needed info from the games I mentioned. Sorry, I am not really up on
games for sightless users, so I don't know of any you could look at
for examples...

> 1. Do most game programmers keep Structures, such as the monster example,
> static or dynamic? Is it just a personal preference?

It probably depends on the situation. If you have a game where you
need a constant number of enemies (for example, Pac-Man), keeping the
container of monsters static makes sense. Otherwise, dynamic works
better since enemies probably keep showing up and getting (hopefully)
blown away.

I assume that personal preference might also have something to do with
it--doesn't most programming? If a programmer isn't comfortable with
dynamic containers, he'd probably use a static even though the number
of enemy AI's keeps fluctuating.

> 2. Would you suggest that most game developers use an actual database, such
> as an MS Access db, to store all character/monster/ object relationships
> instead of a flat file? <snip>

No, even if you have a fairly complex system, most game developers
keep all the data in flat files. Though using a commercial DB sounds
like a good idea, in most cases it just adds headaches to development.
And thin of support--would you want to provide support for problems
that are not the fault of your game, but of the database you used?

For MMORPG's, I'm sure they do use commercial DB's such as Oracle or
another high-end system. But they are dealing with 100,000's of
users--not just one or a couple which is, if I understand correctly,
what you are doing. Keeping track of data in a game is not really all
that hard once you actually start doing it. I'm not saying it's easy,
but remember you start out small and grow it little by little. The
complexity creaps up, but since you started from the very beginning,
you should be able to keep a grasp on it all.

But this is all just MHO. Though I've worked on many commercial games,
I've never created an RPG, though some of the games were as complex as
RPG's. Flat files were the way all data was stored, though sometimes
we had a heirarchy of files, which I guess in some ways was like a
proprietary database... Even if your data does get that complex, I
still suggest just using regular files instead of a commercial DB.

> 3. One thing I am trying to keep in mind, is developing tools that I will
> use such as a level editor to help construct and edit the difficulty of the
> game. Can you illistrate how I might use a level editor to construct a level
> in the game and the monsters/inventory you can find etc. and how I would
> read those saved settings into the game and construct it via pseudo code and
> just with a simple example?

Ug, that's a big request! The reason being is that level editors are
tailored to support the features you support in your game. For
example, do you provide more monsters for higher difficulty? Then your
might have several different types of monster locations: one for
"easy" another for "medium" and another for "hard" (the easy location
would also probably be active in medium and ditto for hard).

But, as an overview, a level editor usually has a representation of a
level. It usually gives the dimensions and locations of rooms and
hallways. For inventory, it's as simple as saying, conceptually, "at
(15,10) there is a chest. Chest contains a cherry Slurpee." For
monsters, it is similar, "there is a Flying Toadstool at (20,20)." The
level editor is just a front end for a file generator. All the data
entered in the level editor is saved to a file that the game reads in
at run-time. This is yet another branch of development that must be
kept in sync with the others. Again, email and a text doc with the
latest implementation of the features would be most helpful in keeping
everyone up to date.

I can't really provide pseudo code since a level editor is a tool with
a palette of options that a user can choose to use in any order. But
for the reading in of a level to edit, it might go something like
this:

Open level file
Read in dimensions (rooms, hallways, terrain)
Generate appropriate structures (code)
Read in monster data
Generate appropriate structures (code)
Read in pickups
Generate appropriate structures (code)
Display level

All the data could be spread out among many files, however. For
example, you could say that there is a Raging Hormone at (15,10), but
the data for what a Raging Hormone actually IS, is in a seperate file
(e.g. RHormone.mnstr or monsters.dat). Whether or not your level
editor actually needs to read that file in depends on whether your
editor allows modification of specific instances of monsters or not.

Speaking of which, you may want seperate editors for monsters and
pickups (to associate sounds with attributes) or you could just slap
all the editors into one. Both approaches have their advantages and
drawbacks (for example, each seperate editor would be more lightweight
and independant from changes in another, but there would be more
developmant paths to update).

> 4. I am having difficulty keeping separate the concept of the game engine
> and the code that actually develops the game. Can you explain to me some
> logic to help me isolate the difference between the two? In other words, if
> I make a game engine, I want to be able to use a level editor to construct
> new games without changing much of my code. Is this an ideal that just isn't
> fact in game programming?

It can be done, but rarely is. What usually happens is a game is
developed with no thought given to re-usability until late into
development. At that point, "engine" stuff is kept in code and
game-specific stuff is broken out into files, though by this time a
lot of it already is in files.

By the time the game ships, you may have a game engine that is more or
less re-usable for a different game, that is similar in type (for
example, you won't repurpose a puzzle engine for an FPS). If the game
"engine" isn't totally seperate from the game, some time is taken
after shipping to de-couple data from engine so it can be re-used on a
subsequent game. However, engines rarely go unmodified from game to
game--programmers think of better ways of doing things, programmers
"hack" in code for a specific feature.

Having a level editor that works for one game to another is harder
since your new game may have new types, but this can be accounted for
by having it read everything in from files. However, even it will
probably need some modifications from game to game.

In truth, engines are rarely used without modifications from game to
game. The reasons are (1) MOST game developers are pretty lousy at
building re-usable components and (2) technology progresses so fast
that making things re-usable for subsequent games doesn't make sense.
And the reasons for (1) are that game development cycles are so short
that devoting time to thinking about re-usability doesn't make sense,
or isn't possible AND the "hack" culture of game development doesn't
include re-usability as a tenant AND coding components for specific
instances may provide some advantages in terms of speed than generic
implementations. Some game developers are very good at building
re-usable engines, such as id, who obtain a lot of their income from
selling engines.

It is possible to design a game engine to be re-usable from the ground
up. However, it will significantly increase your develop time. It may
be more efficient to code your game just as your game, period. Give
little thought to re-usability and just try to get it working. Some
things you will store as seperate data early in development, such as
monster descriptions and levels. Then, near completion, split
game-specific features (monsters, pickups, weapons) out into files one
by one, testing each one to ensure that it still works as before. This
will add to your load time, but it will be worht it by giving you a
re-usable engine (tip: use as few string compares as possible with
reading-in data). This is usually how game engines are created, simply
because it's hard to account for features that don't exist yet. Once
you have your specific implemntation coded, you can start thinking
about how they can be made generic.

> Is it more involved than that? You have a game
> engine but have to change lots of your code for a new game and you just
> can't use a level editor to create a new game using your existing game
> engine? Does the engine change with each game? How much of the code is
> changed to make a new game? 10%? 80%? etc.

It depends, some will require a lot of re-coding, some little. A well
implemented re-usable engine will require little re-coding, a poor one
will require a lot. It also depends on how closely your new game
matches the old one. For example, if your first one was fantasy based
and the new one is sci-fi, it might require more re-coding than going
from fantasy to fantasy.

Some things you may want to consider while you re-purpose your game
for re-usability (that is, as an engine) is file naming conventions.
For example, you can specify that all files ending in ".mstr" are
monster or enemy data files. All pickups end in ".pck" and all level
files end in ".lvl". This is preferable over having a hard-coded list
of filenames. Adding new types and content is much easier when the
engine knows implicity what it needs.

I hope this helps! Good luck! :^)