TILE based game w/C++ question
Yves Dufournaud
David A. Hernandez wrote:
>
> I'm starting to meddle with C++ and I'm considering doing a complete
> rewrite of my game system in that language (it's currently in C).
>
> My "object classes" seem to be:
>
> (x -> y means class y is derived from class x)
> (x <- y means class x contains an object of class y)
>
> tile
> -> landscape
> -> furniture
> -> object
> -> character
> -> npc
> -> player
I do currently quite the same things ( sometimes it's rassuring
to heard that others do the same mistake ;-)).
Except that I don't understant why a player is a tile ?
> Is this a good set of classes for a tile based game system? I'm
> concerned that I'll start coding and find that the interaction between
> these "objects" doesn't work quite as clean as I thought. For
> example, is the viewport an OBJECT/CLASS or a METHOD of the WORLD
> class? If it were a method of the world class, then the WORLD class
> would be the "main" handler, since all interaction would go through
> that class to affect the game. That is not nescesarily a bad idea,
> but it would have major implications for implementation.
>
Well, personnaly I prefer to distinguish the 'world' which managed
object, from the 'view' of this world. Because you can imagine
that you can have many different representation (views) of your world.
And I find more easier to have separate file too look in ( since
usualy class are a single .hh .cc file). More over, if you
want to do multiplatform, in that case you'll have the world class
completly portable, and let the viewport class be os specific.
my 0.00002 $c
--
Yves Dufournaud Email Yves.Du...@imag.fr equipe MOVI laboratoire
GRAVIR
--
Sometimes I think the surest sign that intelligent life
exists elsewhere in the universe is that none of it has
tried to contact us. -- Calvin & Hobbes
David A. Hernandez
I'm starting to meddle with C++ and I'm considering doing a complete
rewrite of my game system in that language (it's currently in C).
My "object classes" seem to be:
(x -> y means class y is derived from class x)
(x <- y means class x contains an object of class y)
tile
-> landscape
-> furniture
-> object
-> character
-> npc
-> player
So far so good. Now, to represent a world:
world
<- array of landscape
<- list of furniture
<- list of objects
<- list of npcs
party
<- list of players
viewport
<- world (current world)
<- party
Is this a good set of classes for a tile based game system? I'm
concerned that I'll start coding and find that the interaction between
these "objects" doesn't work quite as clean as I thought. For
example, is the viewport an OBJECT/CLASS or a METHOD of the WORLD
class? If it were a method of the world class, then the WORLD class
would be the "main" handler, since all interaction would go through
that class to affect the game. That is not nescesarily a bad idea,
but it would have major implications for implementation.
The system will run under a windows environment, but hopefully I will
write clean enough code to run it under Win95 and X-Win based systems.
Any comments or opinions would be appreciated,
Dave
David A. Hernandez
Yves Dufournaud <yves.du...@imag.fr> wrote:
>David A. Hernandez wrote:
>>
>> I'm starting to meddle with C++ and I'm considering doing a complete
>> rewrite of my game system in that language (it's currently in C).
>>
>> My "object classes" seem to be:
>>
>> (x -> y means class y is derived from class x)
>> (x <- y means class x contains an object of class y)
>>
>> tile
>> -> landscape
>> -> furniture
>> -> object
>> -> character
>> -> npc
>> -> player
>I do currently quite the same things ( sometimes it's rassuring
>to heard that others do the same mistake ;-)).
>Except that I don't understant why a player is a tile ?
My base TILE class would include the following: BITMAP, TYPE, CLASS,
and NAME. An OBJECT tile adds things like weight, value, attributes,
scripts, etc. A character adds a body to wear objects, a backpack,
statistics (level, experience, aim, dexerity, etc.). The only
difference between an NPC and a PLAYER is that the NPC is controlled
by the game driver and scripts while the PLAYER is controlled by the
player itself. When an NPC "joins" the party, the NPC becomes a
player until such a time as he/she/it leaves the party.
From this perspective, my tiles are "tiles" for landscaping and
"sprites" for objects and characters, but the implementation of the
bitmaps doesn't need to diferentiate until display time.
>> Is this a good set of classes for a tile based game system? I'm
>> concerned that I'll start coding and find that the interaction between
>> these "objects" doesn't work quite as clean as I thought. For
>> example, is the viewport an OBJECT/CLASS or a METHOD of the WORLD
>> class? If it were a method of the world class, then the WORLD class
>> would be the "main" handler, since all interaction would go through
>> that class to affect the game. That is not nescesarily a bad idea,
>> but it would have major implications for implementation.
>>
>Well, personnaly I prefer to distinguish the 'world' which managed
>object, from the 'view' of this world. Because you can imagine
>that you can have many different representation (views) of your world.
My VIEW here is the Window, so I guess my question is: Does the WORLD
class have a METHOD to display the world in a window, or does the
VIEW_WINDOW class (derived from CWIN most likely) have an WORLD object
and as well as it's METHOD for displaying it.
>And I find more easier to have separate file too look in ( since
>usualy class are a single .hh .cc file). More over, if you
>want to do multiplatform, in that case you'll have the world class
>completly portable, and let the viewport class be os specific.
>my 0.00002 $c
Thanks for the feedback. Any one else care to elaborate?
Dave
Amit Patel
David A. Hernandez <dav...@iadfw.net> wrote:
>I'm starting to meddle with C++ and I'm considering doing a complete
>rewrite of my game system in that language (it's currently in C).
>
>My "object classes" seem to be:
>
> (x -> y means class y is derived from class x)
> (x <- y means class x contains an object of class y)
>
> tile
> -> landscape
> -> furniture
> -> object
> -> character
> -> npc
> -> player
I agree with Yves -- separate the "world" from the "view". That way,
you can add multiple view formats later, like zoom levels. The stuff
you save to disk would be just the world; the view is a way of looking
at the world information.
With a separate world/view system, you'd have:
object
-> thing
-> furniture
-> character
-> player
-> npc
Also, you need to display them.
tile
-> thing tile
-> furniture tile
-> character tile
Note that this lets you use the same character tiles for both players
and NPCs.
> world
> <- array of landscape
> <- list of furniture
> <- list of objects
> <- list of npcs
If you separate the world and view, your world would be arrays and
lists of objects, but not tiles. A View would be a display of things
in the world. For example, landscape might be represented by a byte.
Then you can have an array of tiles (landscape_tiles[256]). The view
would go through each position in the world, find its landscape
number, and then use that as an index into the tile array. It then
displays that tile. Similarly, a `thing' object would contain a one
or two byte index into a tile array for things. A person object would
contain an index into a tile array of people. (An NPC would have an
index into that same array.)
> party
> <- list of players
>
> viewport
> <- world (current world)
> <- party
>
>Is this a good set of classes for a tile based game system? I'm
>concerned that I'll start coding and find that the interaction between
>these "objects" doesn't work quite as clean as I thought. For
>example, is the viewport an OBJECT/CLASS or a METHOD of the WORLD
>class? If it were a method of the world class, then the WORLD class
>would be the "main" handler, since all interaction would go through
>that class to affect the game. That is not nescesarily a bad idea,
>but it would have major implications for implementation.
Does it help to separate viewport and world? At first, I thought that
you might be able to put different players on the same world, but if
players can modify the environment by picking things up, then the new
players might not be able to find everything they need. The other
possibility is that you can put different worlds with the same set of
players. This also has some problems -- how do you make sure that the
items carried by the players from one world are still useful or not
too powerful in the new world?
What does the viewport represent?
- Amit
Ron Whittle
dav...@iadfw.net (David A. Hernandez) wrote:
-My VIEW here is the Window, so I guess my question is: Does the WORLD
-class have a METHOD to display the world in a window, or does the
-VIEW_WINDOW class (derived from CWIN most likely) have an WORLD object
-and as well as it's METHOD for displaying it.
WORLD has a method to display in a window.
--
Ron Whittle
r...@netrail.net
Frank Pitt
NOT the best way of doing it.
That implies that WORLD needs to know about all the different types
of VIEWs. NOT very extensible.
A better way is to allow VIEW access to WORLD data, and to have VIEW
control how it appears.
An illustration. You are obviously thinking of VIEW as being the major
graphical window that displays the tiles for the player.
But a perfectly valid VIEW would be one that displayed only continually
updating bar graphs of various intersting statistics in the WORLD.
Or how about a VIEW containing a complete picture of the whole WORLD
(continent map) and another displaying only about ten square feet.
You could just scale the original VIEW but that would be inefficiemt
and time consuming,
Each VIEW mentioned here could be added after the entire WORLD class
was written, perhaps even in the next release.
Look up the Model/View/Controller design pattern.
Frankie
--
Frankie
==========================================================================
Software Designer| < Frank...@tait.co.nz > |(064)(03)358-0411 (Bus)
Trunked Networks | Christchurch, New Zealand |(064)(03)358-4493 (A/H)
Tait Electronics |<fra...@mundens.southern.co.nz>|(064)(03)358-0146 (BBS)
==========================================================================
Frank Pitt
>My VIEW here is the Window, so I guess my question is: Does the WORLD
>class have a METHOD to display the world in a window, or does the
>VIEW_WINDOW class (derived from CWIN most likely) have an WORLD object
>and as well as it's METHOD for displaying it.
No, the WORLD and VIEW are seperate objects on the same hierarchial level,
both being subordinate to the CONTROLLER.
You need to research the Model/View/Controller design pattern,
in this case your WORLD is the Model, the identity of the Controller
depends on the hierarchy of the rest of your application.
Frankie
Frank Pitt
>Does it help to separate viewport and world?
Yes.
>At first, I thought that
>you might be able to put different players on the same world, but if
>players can modify the environment by picking things up, then the new
>players might not be able to find everything they need.
That's a scenario or game design problem, not a coding one.
You either decide that only one person can succeed, allow them to
co-operate, or leave multiple copies of neccesary items (different
places or re-spawn, whatever)
>The other
>possibility is that you can put different worlds with the same set of
>players. This also has some problems -- how do you make sure that the
>items carried by the players from one world are still useful or not
>too powerful in the new world?
By just doing so. Keep the power level constant, or if you're doing
a continuing series keep it growing steadily but prevent people from
going "backwards" in the series.
Or you could explicitly bar particular items, powers, power levels in
particular worlds, i.e: in this world your ring of fire can torch
a village, but when you enter another it can barely light a candle.
(fire magic is weak here)
>What does the viewport represent?
A window on a VIEW, the place on the screen where your VIEW gets displayed.
(Not all VIEWS need to be displayed, and a single VIEW could theoretically
be displayed in multiple screens/places on the screen)
Frankie