Crypt!
<delurk />
> You could start by creating World class containing an ArrayList
> grid[][]=new ArrayList[100][100]
A slightly better approach would be:
1. create interface MapObject for map objects that includes support for
linking multiple objects together (getNext(), setNext() and stuff) - this
saves memory over using additional list containers and will be useful
later when you're implementing inventories
2. create interfaces FloorTile, Item, Monster that extend MapObject
3. MapObject[][] map = new MapObject[100][100] - this array will take
slightly more than 40k of memory with all entries being null initially.
(supersede next sentence only) Use another array of the same type and size
for objects and monsters in the level.
4. implement floor tiles and other types of MapObjects that don't maintain
state as singletons. Note that some floor tiles apparently change state
but really don't - e.g. trap doors might get _replaced_ by a hole, closed
doors might get _replaced_ by an open door, etc. This way, setting the
first square to a floor tile will use memory for the first instance of
that tile but any additional square set to the same tile won't. So if your
game has 200 different background tiles, you'll use memory for 200 tiles
throughout the whole game instead of creating 100x100 per level.
In the unlikely event that you should need a floor tile that maintains
state, you can individually implement it so that it doesn't always return
the same instance and still save memory on all other floor tiles, but I
wouldn't recommend it. For example, a floor tile that needs to maintain
state with three valid states is easily replaced by three separate
implementations.
You will likely not be able to do step 4 with monsters and items as both
probably have properties that are different between instances (hit points,
inventory, etc.); however, that's just the price for maintaining state and
you'll have to live with it. Monsters will very likely be garbage
collected soon after meeting the player, anyway. Many items will be
destroyed when they're used, e.g. potions, scrolls,... make sure to have
some way of getting rid of unused items on the dungeon floor, like e.g.
decay -especially for corpses if your monsters leave any-, or regular
clean-up of items that haven't been touched by the player...
As for the inventory, interfaces that represent objects that can contain
other objects should just have an additional pointer to the first
inventory item. This applies to both Monster (they carry stuff) and Item
(bags may contain other Items - or even Monsters). Add a
getFirstInventory() method to MapObject and implement it as an empty
method in floor tiles - they don't need an inventory. Implement it as an
accessor method of a reference in classes that represent objects that can
contain other objects. Use the next pointer included in MapObject to link
multiple Items together.
As an example, for doing damage, add a doDamage() method to MapObject.
(Those of you that don't like extending classes please skip this
paragraph.) Make it take the type and intensity of damage as parameters,
e.g. a simple implementation might be doDamage(int coldDamage, int
fireDamage, [...]) or doDamage(int type, int intensity) and a less trivial
one might take a complex type representing multiple types of damage. The
simple one should suffice for a 'my first roguelike', there's not much
that requires more sophisticated design. Implement doDamage() as an empty
method in base classes for floor tiles and items -this will use no extra
memory except once per class loaded- and make it reduce a hp counter in a
monster base class -this will use additional memory for a hp counter in
monsters- and so on. Implement a potion class that reacts to cold and fire
damage by exploding or shattering. Now you can e.g. implement a wand class
that just calls doDamage() in every object in the direction the wand was
used, monsters will lose life energy and potions will shatter with no
additional work.
Any suggestions? Is there any existing quick-start design guide for
roguelikes? The above works the same in almost all languages, including
non-object oriented, should you choose to use an object-oriented design in
C or the like.
Daniel
>> Stay informed about: Building your first Roguelike 
FAQ
Profile
Private Messages
Log in
