Re: A new RL engine
- From: Brendan Guild <dont@xxxxxxx>
- Date: Sun, 23 Oct 2005 03:21:04 GMT
Michal Brzozowski wrote in
news:1129987856.914939.158370@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
> Here's my semi-developped RL engine with
> a demo content:
>
> http://rainbow.mimuw.edu.pl/~mb219407/zagadka-221005.tar.bz2
>
> Right now it loads a single map and lets the player
> pick up/use items, kill a monster and walk around sightseeing.
>
> The reason why I'm uploading this is because I want to hear
> your comments about the design, especially from all those
> OO-design gurus.
I haven't read everything yet, but it seems as if you haven't
implemented game saving yet. It's important to have a plan for that
because it can get quite complicated if you aren't prepared. I'd
recommend that you create an abstract game saving system that you can
use to write out and read in all of your game state objects, even if
that system starts out as only stubs and abstract classes.
Is the xml_serial class going to be for saving the game?
I've been having fun with the recursive saving technique that Java
serialization has made famous, but I have a dream that something more
structured would be better. Wouldn't it be nice to keep the objects in
the savefile sorted by type? The problem is that some objects might not
have been read before they are needed by other objects. So we end up
writing them out in the order that they will need to be read in, which
is what I recommend for you.
I notice that your TSquare class seems rather bloated, especially since
your maps are stored as a TSquare array. Clearly the map has to be an
array of something, but I would cringe as making that thing any bigger
than one or two fields. I'm especially looking at the string that you
are storing in every square.
I would recommend making that array an array of pointers to TSquare
objects and giving the TSquare a full object-oriented treatment with
private fields and virtual member functions for implementing special
effects in derived classes. You lose nothing and you gain at least the
hope that some of those squares could be sharing a single instance of
TSquare.
It seems like restricting all maps to be 100 by 100 is rather arbitrary
and boring for the player. I imagine it also makes map generation more
difficult. It would be nice to have the option of an algorithm that
generates sprawling maps and when it's done whatever space it has used
up is the size of the level.
I'd recommend that even if 100 by 100 is the best possible level size
for your game, you should avoid referring to the height and width as if
they were static consts. Really, height and width are properties of
each map. Every time you say TMap::max_w in your code, you are locking
yourself into never ever having max_w vary between maps. I'd recommend
that you drop max_w entirely and have your map array be dynamically
allocated.
Something like: TSquare ***pole, perhaps?
Another important point is that people are often pondering what the
best map representation might be. Lists of creatures? Storing creatures
with each square? Hashtables? So I would highly recommend making your
map implementation hidden under a layer of abstraction. You should have
an abstract class that allows you to play with the map without knowing
how it works, especially hiding max_w and max_h and your various lists.
This is especially important for generation! There should be no need to
even recompile your map generation code when your map class changes.
It would be nice to have a simplified interface for map generation so
that your generator is more or less pointing and grunting to make the
level. I like to think of a map generator as more of a caveman smashing
out a map with a big club than a watchmaker looking through a
magnifier.
It goes without saying that you should be passing a map generator
object to the map constructor rather than the enum you are using now.
Then the generator can be given an object which lets the generator
grunt about where it wants the walls, where it wants to monsters, where
it wants the objects of ultimate power, but what exactly gets put to
the map and how is left for more sophisticated minds to customize
elsewhere.
Imagine a level with living walls that attack you if you get too close.
Wouldn't it be nice to be able to make that with any of your old
generators? No copy and paste, not even a recompile. You can increase
the game difficulty at the map generation level without actually
modifying that tricky map generation code. You could even send those
grunts to Lua scripts to allow map customization.
At the very least it would mean that you won't have to recompile your
map generator every time you modify your TSquare class.
I'll keep reading and let you know of I come up with anything else.
It's looking good so far!
.
- Follow-Ups:
- Re: A new RL engine
- From: Michal Brzozowski
- Re: A new RL engine
- References:
- A new RL engine
- From: Michal Brzozowski
- A new RL engine
- Prev by Date: Re: Where to put interface?
- Next by Date: Re: Where to put interface?
- Previous by thread: Re: A new RL engine
- Next by thread: Re: A new RL engine
- Index(es):
Relevant Pages
|
