Map Exploration Design

A discussion area for general design issues that staff would like detailed feedback on.

Moderator: Staff

User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Map Exploration Design

Postby Roots » Sat Dec 30, 2006 6:28 am

Having the experience of the past design under my belt and taking in everyone's feedback and comments about what they want to see, I'm finally at the point where I am ready to re-design the map engine from the ground up to make us all happy. :angel: I've been slowing piecing together a design document for this part of the game on this wiki page, so keep an eye on it and let me know if you see any red flags.


So, first let me say what will remain the same:

- The view area dimensions of the map (32x24 tiles)

- The number and types of tile and object layers

- The dialogue system, but it will have a few noticeable improvements


Now here are the major things that will be changed:

- Movement will no longer be tile-based (like FFVI) but rather more freely based (like Chrono Trigger).

- Walkability properties will be divided into 16x16 regions, meaning that each tile can be declared walkable or not in each of its 4 16x16 corners.

- Tiles will have a sound property, so that walking sounds may be played when a sprite walks over a tile

- We're moving from a rudimentary "altitude" to a "context" based system for objects. While this system wasn't observed in the demo, basically what this means is that each map has a series of contexts, and when you switch from one context to another the properties of a map may change and objects/sprites which are visible will also change. (As an example: walking into a house swaps the "exterior" house tiles with "interior" tiles, and sprites inside the house can now be seen while sprites outside the house can not)

- Collision detection will be improved to take advantage of the new walkability schemata and context system

- It will be made easier to speak with sprites than it was in the demo (I admit it was annoying)

- Sprites will be allowed to come in all shapes and sizes, and additionally collision rectangles will be defined separately of the sprite's visible dimensions.



That's for starters anyway. I have some more ideas I want to implement and test, but I've said a mouthful for now. If any of you have strong feelings about what features I am planning to put in, or requests for other things that you feel are necessary that I have not yet mentioned, speak up now. I'm working on the code at this very minute and the sooner I get your :approve: or :disapprove:s, the easier it will be for me to integrate any necessary changes. :hack:
Image
User avatar
Jetryl
Artist
Posts: 1485
Joined: Fri Aug 26, 2005 7:35 am
Location: Southern Minnesota, USA

Postby Jetryl » Sat Dec 30, 2006 7:29 am

Awesome in a great many ways. :approve:
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Sat Dec 30, 2006 7:41 pm

Continuing on new features in this design:

- No more random encounters. I've heard people whine about it enough now that we clearly need another system to visually show monsters on the screen. I'm not sure what this system is going to be yet (there are many different examples in prior work), so I'm open for ideas here. Preferably ideas that don't require a lot of new artwork nor that are extremely difficult to program. :angel:

One thing I want to make sure we do in this system is to be able to differentiate between stronger and weaker monsters on the field (probably through the use of color). That way the player can choose to either avoid the tougher battles and instead only pick fights with the small fry, or if they are trying to earn a lot of XP/dorrun then they can go after the big guys that are worth more. :)

- Puzzle solving. This has always been a planned feature, but we haven't gotten this far yet. I want dungeons to contain puzzles, not just be another "walk around and fight the bad guys" game. Lufia 2 is an excellent example. What I haven't figured out yet is what mechanisms the puzzles will be solved with. I've been thinking that maybe each character can have a different ability (swing a sword to clear away dense bushes, fire an arrow to hit a distant target, etc.) and that the player can simply hit the swap key to change the active character on the map screen, and hence the action that may be performed. But I'm not certain if this would be a good or bad idea. :scratch:
Image
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Postby eleazar » Sat Dec 30, 2006 8:09 pm

i'm trying to get a handle on how the map layers work so i can understand how to make tiles for it.
I don't see how we can get the proper layered results if for instance there are 2 trees, one in front of another. A character could walk in front of both, behind both, or in-between. I don't see how the proposal considers a relative layering (in-front or behind) for tall objects. How do you do a roof that characters can walk on or go behind?
Perhaps this is covered under context, but i haven't seen much explanation of how that works.
User avatar
Jetryl
Artist
Posts: 1485
Joined: Fri Aug 26, 2005 7:35 am
Location: Southern Minnesota, USA

Postby Jetryl » Sat Dec 30, 2006 8:28 pm

Roots wrote:Continuing on new features in this design:

- No more random encounters. I've heard people whine about it enough now that we clearly need another system to visually show monsters on the screen. I'm not sure what this system is going to be yet (there are many different examples in prior work), so I'm open for ideas here. Preferably ideas that don't require a lot of new artwork nor that are extremely difficult to program. :angel:


Ordered by difficulty of implementation:

Idea 1:
Have big, red, floating exclamation points signifying "walk here and a fight occurs". Preferably undulating, which could be done in OpenGL with just a single image modifying it's size according to a sine function.

E.g. size=40px+5px*sin(timeSomething)


Idea 2:
Have stationary icons of the monsters on the map. This would make it obvious to the player as to what they are.


Idea 3:
Make "evil NPCs"; NPCs no different than the current ones, but which are represented by images of the monsters, and which when they get close to the player, initiate a battle instead of dialogue (and are removed after being beaten). Possibly also with slightly different movement behaviour, but the regular NPCs will need that too, sooner or later.


The big scary issue with this is the obvious question of "but where would we get the art?" Believe it or not, another OSS game (theManaWorld, yuck) happens to have a set of images for most of the monsters we have, which are animated in exactly the way Allacrost animates NPCs, and are even the perfect size for us. Most of these were made by Neoriceisgood, and really don't feel at home in that POS game (since they have basically zero decent tile art).

They have good versions of:
• Bats
• Scorpions (!) (not suitable for the Allacrost boss, but suitable for its children)
• Snakes (!)
• Slimes (!)
• Maggots, rat-sized
• Maggots, horse-sized
• Ambulatory Mushrooms

http://wiki.themanaworld.org/images/7/7a/Monster1.png


With the understanding that some "monster-NPCs" would actually never move, and could get away with a single, stationary image (like bosses), this should actually be rather easy to make art for; I for one could churn out frames for things like skeletons very easily.

Actually, looking at Allacrost's list, all we'd need made are: Skeletons, spiders, and a generic daemon image. All of which could be done in a matter of a few days.
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Sat Dec 30, 2006 8:37 pm

eleazar wrote:i'm trying to get a handle on how the map layers work so i can understand how to make tiles for it.


Okay, well there are three tile layers and three object layers:

* Lower Tile Layer: represents the ground or floor.
* Middle Tile Layer: used for variations in the lower tile layer, such as placing rocks or shrubbery.
* Upper Tile Layer: used to represent smoke, the roofs of houses, or other things high in the air.

* Ground Object Layer: objects that are attached to the ground
* Pass Object Layer: objects in the ground object layer can both walk under or walk over these objects (bridges)
* Sky Object Layer: clouds, birds, etc.


The layers are drawn in the following order.

1. Lower Tile Layer
2. Middle Tile Layer
3. Ground Object Layer
4. Pass Object Layer
5. Ground Object Layer (again)
6. Upper Tile Layer
7. Sky Object Layer

So first, lower tiles (floors, etc) and middle tiles (variations in the lower tiles, rocks, etc) are drawn. On top of those tiles, most of the sprites, etc. are drawn in the ground layer (ignore for now steps 4 and 5). Then the upper tile layer is drawn, and any tiles drawn in this layer cover all of the sprites, etc. that were drawn previously. This is usually used for cave ceilings and the upper parts of walls, for instance. Finally, sky objects are used for things like clouds or birds or what have you.

eleazar wrote:I don't see how we can get the proper layered results if for instance there are 2 trees, one in front of another. A character could walk in front of both, behind both, or in-between.


Look at the images at the bottom of this page: http://allacrost.sourceforge.net/wiki/i ... xploration

See how in the left-most image there are two sprites, one standing in front of the other? When objects are drawn on the map, the objects on the screen are drawn from top to bottom. In that picture, because the male sprite is located below the female sprite, the female sprite is drawn first and then the male sprite is drawn partially over her. Make sense?


eleazar wrote:I don't see how the proposal considers a relative layering (in-front or behind) for tall objects. How do you do a roof that characters can walk on or go behind? Perhaps this is covered under context, but i haven't seen much explanation of how that works.


This situation is a little tricky, but it is taken care of by the way that ground objects and pass objects interact. So lets take your example of a roof that we want characters to walk on or go behind. We'd have to make the roof an object and put it in the pass layer. There is a feature in the video engine to convert a section of tiles to an object, so you can still design the roof as if they were just normal map tiles and the code converts it to an object.

There's a special condition variable for map sprites that says either "draw me before the pass object layer" -or- "draw me after the pass object layer". If we want the sprite to be under the roof or on top of the roof, we just have to change that condition variable and its taken care of. So we can have multiple sprites walking under the roof and multiple sprites above the roof as well.
Image
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Postby eleazar » Sat Dec 30, 2006 9:39 pm

I've read the wiki page.

Roots wrote:
eleazar wrote:I don't see how we can get the proper layered results if for instance there are 2 trees, one in front of another. A character could walk in front of both, behind both, or in-between.


Look at the images at the bottom of this page: http://allacrost.sourceforge.net/wiki/i ... xploration

See how in the left-most image there are two sprites, one standing in front of the other? When objects are drawn on the map, the objects on the screen are drawn from top to bottom. In that picture, because the male sprite is located below the female sprite, the female sprite is drawn first and then the male sprite is drawn partially over her. Make sense?

I wasn't asking how sprites could layer properly. Since they are a single unit it makes sense that they can be layered from the bottom. But i don't understand how a tile in the middle of a tree trunk knows it needs to layer the same with with the root tile below.

I'll try to pose the quandary i see in a more concrete manner. Consider this example. I don't see how it could be done with a single pass object layer:
[img:96:159]http://www.jwbjerk.com/dl/allacrost/quandry.png[/img]
The red boxes indicate the collision detection or the unwalkable areas.

Notice how in tile B2 there are 4 non-ground or sky layers present. There could be more, but that would make things too cluttered to understand in a still frame.
Part of the complexity is caused by the possibility of free movement and proposed ability to set walkability according to quadrants of a tile. I'm not against these things, but i don't think all the implications have been considered.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Sat Dec 30, 2006 10:09 pm

eleazar wrote:I've read the wiki page.
I wasn't asking how sprites could layer properly. Since they are a single unit it makes sense that they can be layered from the bottom. But i don't understand how a tile in the middle of a tree trunk knows it needs to layer the same with with the root tile below.

Consider this example. I don't see how it could be done with a single pass object layer:
[img:96:159]http://www.jwbjerk.com/dl/allacrost/quandry.png[/img]
The red boxes indicate the collision detection or the unwalkable areas.

Part of the complexity is caused by the free movement and proposed ability to set walkability according to quadrants of a tile. I'm not against these things, but i don't think all the implications have been considered.


If those sprites, the cactus, and the dead tree were all objects, then this is how they would be drawn by the engine and everything would be fine. Converting these map tiles into map objects through the editor & video engine would be an easy solution to this problem.

So the issue becomes when the tree and the root are not objects, but are tiled. Then we would have to handle this a little more carefully. Basically, the solution is to place the bottom tiles in the lower or middle tile layer, and place the top tiles in the upper tile layer. And of course, you have to properly set the collision areas. I'll go through this example picture from bottom to top with comments on it:


- Laila sprite
Nothing wrong in the bottom row of tiles in this picture. The top half of her sprite looks fine as well. In this picture, we're going to assume that the bottom tile of the dead tree is in the lower or middle tile layer, since sprites can be drawn over it.

- Dead tree + woman sprite

There's a problem here, and its with the collision rectangles. You only specified the bottom quadrant of the tree to have a collision area. That area needs to be increased so that it is twice as tall, since the lower tile of the tree is in the lower/middle tile layer and we don't want to allow any sprites to walk over it (since they would cover it up). This means that the woman sprite would have to be moved a bit towards the left so the collision areas do not overlap.

The top half of the woman and the top tiles of the tree are fine: no problems there. The top tiles of the tree would go on the upper tile layer, meaning no sprite can be drawn over those tiles.


- Cactus + claudius sprite

The cactus image begins on the third tile row from the bottom, so we'll assume its in the lower or middle tile layer. However, there's a problem with the row above that. Claudius is behind the cactus on this tile row, while the woman is above it. This is wrong. If the cactus image on the fourth tile row is in the lower layer, claudius would be drawn over it. If its in the upper layer, the woman's head would be cut off. The solution here is the same to the last problem: the collision area needs to be modified.

However, if the Cactus was an object instead of a tiled image, this image would be correct.



Okay, thanks for the example. Now I think I see what question you were really asking, and what answer I should give: for a given map tile, it is not possible for one sprite to be drawn over a tile image and another to be drawn under a tile image, UNLESS the tiled image in question has been converted into an object, in which case this is acceptable.

So there's your answer. Yes: this image is possible, but both the tree and the cactus would have to be converted to objects by the code. If the tree and cactus were left as tile images, the collision areas would have to be expanded, and the position of some of the sprites would have to be moved for the image to be legal.
Image
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Postby eleazar » Sat Dec 30, 2006 11:01 pm

Roots wrote:.....
- Dead tree + woman sprite

There's a problem here, and its with the collision rectangles. You only specified the bottom quadrant of the tree to have a collision area. That area needs to be increased so that it is twice as tall, since the lower tile of the tree is in the lower/middle tile layer and we don't want to allow any sprites to walk over it (since they would cover it up). This means that the woman sprite would have to be moved a bit towards the left so the collision areas do not overlap.


Now here are the major things that will be changed:
...

- Walkability properties will be divided into 16x16 regions, meaning that each tile can be declared walkable or not in each of its 4 16x16 corners.

i don't see how these 2 statements mesh.

• Even if the collision areas were modified similar problems could be created if sprites are ever allowed to be bigger than 1x2 tiles. Which seems necessary in a world that contains giant dogs and scorpions.

• Even if we ignore the old woman i don't see how both the cactus and dead tree can both be drawn as tiles in tile B2. Unless you allow multiple graphics to be drawn in the same tile, on the same tile layer. Then how is it determined which goes on top?
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Sat Dec 30, 2006 11:17 pm

eleazar wrote:• Even if the collision areas were modified similar problems could be created if sprites are ever allowed to be bigger than 1x2 tiles. Which seems necessary in a world that contains giant dogs and scorpions.


This is true. We'll just have to be careful about how we design maps with large sprites is all. I mean, this design is the best solution that we've come up that allows us the most flexibility without requiring a lot of memory or processor resources. :shrug:

eleazar wrote:• Even if we ignore the old woman i don't see how both the cactus and dead tree can both be drawn as tiles in tile B2. Unless you allow multiple graphics to be drawn in the same tile, on the same tile layer. Then how is it determined which goes on top?


Oh okay, I didn't even think of that. Yeah, then in this case you'd either have to explicitly create the overlapping tile images for the map, or you could just convert them to objects and the problem is solved.
Image
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Postby eleazar » Sun Dec 31, 2006 1:03 am

Roots wrote:
eleazar wrote:• Even if the collision areas were modified similar problems could be created if sprites are ever allowed to be bigger than 1x2 tiles. Which seems necessary in a world that contains giant dogs and scorpions.


This is true. We'll just have to be careful about how we design maps with large sprites is all. I mean, this design is the best solution that we've come up that allows us the most flexibility without requiring a lot of memory or processor resources. :shrug:

I realize any design has trade-offs between flexibility, usability, and code-ablity. I'm not trying to say that any limitations are bad, but that limitations need to be understood & recognized, otherwise it's going to be very frustrating creating graphics for this game that either cannot be used, that cause glitches, or else are very painful to assemble in the map editor.

Roots wrote:
eleazar wrote:• Even if we ignore the old woman i don't see how both the cactus and dead tree can both be drawn as tiles in tile B2. Unless you allow multiple graphics to be drawn in the same tile, on the same tile layer. Then how is it determined which goes on top?


Oh okay, I didn't even think of that. Yeah, then in this case you'd either have to explicitly create the overlapping tile images for the map, or you could just convert them to objects and the problem is solved.

Are there limitations/costs/trade-off in turning chunks of graphics into objects rather than tiles?

It seems relatively simple to turn tree/bushes/cacti into objects, in fact that would be easier in most cases for the map-maker, since trees can't be assembled from tiles in very many legitimate ways.

But houses like the mountain home would tend to have overhangs, eves, awnings and so forth, which could probably cause similar overlap problems to the tree + cactus as tiles. I don't claim to have the answers, but i was hoping for more simplicity than the necessity of building most houses out of pieces scattered throughout all the layers.

I haven't wrapped my mind totally around this. i'm not entirely sure the mountain-home graphic are exactly compatible with the system as outlined.
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Re: Map Exploration Design

Postby eleazar » Sun Dec 31, 2006 1:19 am

Roots wrote:- Walkability properties will be divided into 16x16 regions, meaning that each tile can be declared walkable or not in each of its 4 16x16 corners.

- Tiles will have a sound property, so that walking sounds may be played when a sprite walks over a tile

Other Ideas:
It would be very convenient if the text files that define how tiles show up in the map editor could also have default values for walkability and sound. Grass would almost always be walkable, and lava would nearly never be. A little cactus would be unwalkable in just one quadrant of the tile. That loose floor-board would almost always squeek. The map designer might want to change these properties but 99% of the time a default value is what he wants. It would be simplest to assign these properties from a default when the tile is placed on the map, and let the designer tweak it if he wants.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Re: Map Exploration Design

Postby Roots » Sun Dec 31, 2006 1:27 am

eleazar wrote:Other Ideas:
It would be very convenient if the text files that define how tiles show up in the map editor could also have default values for walkability and sound. Grass would almost always be walkable, and lava would nearly never be. A little cactus would be unwalkable in just one quadrant of the tile. That loose floor-board would almost always squeek. The map designer might want to change these properties but 99% of the time a default value is what he wants. It would be simplest to assign these properties from a default when the tile is placed on the map, and let the designer tweak it if he wants.


This is already supported by the map editor, IIRC. :)
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Thu Jan 04, 2007 8:04 pm

I have two ideas to bring forth with sprite animation.


Idea #1 "Still walking"
When the player's sprite (or any other NPC) is walking along and runs into an obstacle that stops them in their tracks, should the sprite:

A) Continue its walking animation, even though its not going anywhere?

B) Have its walking animation force-stopped so that the sprite is in the standing position?


We've seen examples of both used in games. The advantage to (B) is that its more natural/expected. The advantage to (A) is that it might be more obvious to the player that they can't walk that direction (if it stopped still, the player might first think that they aren't holding the direction button enough). I'm working on the code for this right now and I'm not quite sure which scheme to implement (neither is difficult).


Idea #2: Running animations

I was wondering if we should create running animations in addition to walking animations for the main character sprites. Since we can toggle walk/run in maps, it just makes sense. :shrug: Note that I'm only suggesting this for the main, playable characters, not every single sprite. When other sprites wish to "run", we'll just use their standard walking animation at 2x speed. Note that this is what Chrono Trigger did as well. :)

Can I have an artist's opinion on this matter?
Image
User avatar
gorzuate
Developer
Posts: 2575
Joined: Thu Jun 17, 2004 3:03 am
Location: Hermosa Beach, CA
Contact:

Postby gorzuate » Thu Jan 04, 2007 9:03 pm

I vote for idea #1a and disapprove of idea #2 (too much more artwork for an art department that is severely stressed).
Image
User avatar
EmreBFG
Team Manager
Posts: 294
Joined: Thu Apr 06, 2006 3:24 am
Location: Chicago, IL
Contact:

Postby EmreBFG » Thu Jan 04, 2007 9:28 pm

gorzuate wrote:I vote for idea #1a and disapprove of idea #2 (too much more artwork for an art department that is severely stressed).


I agree with Gorz on #1a. #2 would add a lot of character to the gameplay but I think we should pursue it only if we get a generous helping of artists sometime down the line -- if that happens :heh:
User avatar
Jetryl
Artist
Posts: 1485
Joined: Fri Aug 26, 2005 7:35 am
Location: Southern Minnesota, USA

Postby Jetryl » Fri Jan 05, 2007 6:30 am

EmreBFG wrote:
gorzuate wrote:I vote for idea #1a and disapprove of idea #2 (too much more artwork for an art department that is severely stressed).


1 - I agree with Gorz on #1a. #2 would add a lot of character to the gameplay but I think we should pursue it only if we get a generous helping of artists sometime down the line -- if that happens :heh:


I agree with #1a, with one caveat; though the actual map code will make any "mOb (moveable object/creature)" keep cycling their walking animation if they're trying to walk into the wall, the NPC AI should be smart enough not to do that. E.g, though the NPCs would cycle their walking animation if they did walk into the wall, they won't actually ever do that.

This keeps the code free of having to have "special cases" for PCs and NPCs (which is good, because they're evil bug magnets), but also makes it so that only the PC actually ends up doing that, because only the PC's movement controller is dumb enough to walk into walls. :uhoh:


2 - I think you should add code support for number 2, and just reference the current walking animations as the running animations. This means that when any artist wants to make those, they can have it working immediately; as soon as they make the images, and they can test the minutiae of how it blends with the rest of the animations (something basically impossible to do outside of the actual game).


On a somewhat off-topic note, one of the big things we've gotta clear up is getting it so that artists can actually test animations and images in their own copy of allacrost. After we get 0.2.0 out, we should make some big posts in the artwork forum (which can be duplicated on the wiki, but have to be on the forum), detailing how to add the following into a release copy of the game:
• an NPC
• a new tileset
• a map
User avatar
eleazar
Senior Member
Posts: 110
Joined: Mon Sep 18, 2006 7:56 pm
Location: USA

Postby eleazar » Fri Jan 05, 2007 8:02 pm

EmreBFG wrote:
gorzuate wrote:I vote for idea #1a and disapprove of idea #2 (too much more artwork for an art department that is severely stressed).


I agree with Gorz on #1a. #2 would add a lot of character to the gameplay but I think we should pursue it only if we get a generous helping of artists sometime down the line -- if that happens :heh:


If this is the right time to implement a different run cycle in the code, go ahead and do it. Having the capacity for a type of useful animation is good. Artists are much more likely to do things that the engine already supports (if there's documentation) than to do work in hopes that a coder will eventually add support.
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Fri Jan 05, 2007 9:23 pm

Adding support for a running animation would be a piece of cake the way I'm designing this engine. It can always be added later very easily. :approve:
Image
User avatar
Roots
Dictator
Posts: 8662
Joined: Wed Jun 16, 2004 6:07 pm
Location: Austin TX
Contact:

Postby Roots » Thu Jan 11, 2007 12:12 am

Two ideas:


#1: Initiating conversations with sprites

This was a problem in our first demo release, so I want to make sure it gets done right this time. What should be the conditions for the player to be able to initiate a conversation with a NPC? I'm thinking the following:

- The player can only initiate conversations in the direction that the player's sprite is facing (north, south, east, west). They *can not* speak with a sprite that is at a diagonal distance from them, even though the sprites are allowed to move diagonally.

- To check if a conversation can take place, the player has to be within a certain distance of the target. Should the distance calculation take into account the collision rectangles of the two sprites, or the image rectangles of the two sprites? :huh: Either way its really easy for me to switch the code. I think I'm going to do collision rectangles for now since this environment is supposed to be an emulated 3D one.

- What should the maximum distance between two rectangles be to initiate a conversation? I'm thinking either 32 pixels (one tile) or maybe 48 pixels (1.5 tiles). I'll go with 32 pixels for starters.


#2: Enemy encounters

I just had an idea on how to do this so I wanted to jot it down.

0. When the player first returns to the dungeon screen from a battle, for the first few seconds there are no enemies present.

1. Enemy sprites on the map are generally silhouette images of various colors, with lighter colors indicating easier enemy parties and darker colors indicating harder enemy parties. The sprites may also be of various sizes

2. Enemy sprite images gradually "fade in" from the edges of the screen as the player is walking (or standing still). The fade in process takes about 1-3 seconds, and during the fade in, the enemy sprite is in a stationary position

3. Once the enemy sprite is fully faded in and visible, it begins to walk around the map in a semi-random pattern. However, the destination of the enemy is the current position of the player's sprite, although it may take a somewhat round-about route to get there.

4. At first, easier enemies appear on the screen and move toward the player slowly. As time passes (the player keeps trying to dodge the enemies), the enemies that appear begin to get stronger, and stronger enemies also move faster than weaker enemies. They also begin to appear closer to the player.

5. Over time, more and more enemies will be appearing on the screen. They will appear faster, they will be stronger, and they will be quicker to try and approach the player. Inevitably, the player will not be able to dodge all the enemies on the screen and once the player's sprite collides with an enemy sprite, a battle occurs.



I think this is a good first serious stab at an encounters scheme. It will actually cause the player to take the active situation to consideration, and they have to choose a number of strategies:

- Avoid enemies for as long as possible to make the furthest distance, and risk the chance of encountering a very strong group of foes.

- Walk a moderate distance and once strong enemies start to become too numerous, intentionally run into a weaker enemy to avoid a tough battle

- If the dungeon has very strong foes, always attempt to run into the weakest foes that are available.


The fact that these are colored silhouettes also have a great advantage of not requiring a lot of artwork to be made for enemy map sprites, being able to use the video engine to auto-color the silhouettes to reflect their strength, etc. This algorithm may be a little tough for me to implement and it may take a lot of tweaking/balancing to get the encounters system "just right", but I think I can do it. What do you guys think?
Image

Return to “Design”

Who is online

Users browsing this forum: No registered users and 4 guests