next »

[supamanu]

Hello folks,

I am kicking off a two-month game project as part of my degree (time pressure, can't shift the end date)

It's my first game project. I'm going to be using the winning combination flashpunk and Ogmo for level design. Because of my inexperience (I have some very basic C# and AS3.0 experience) I wanted to share one of my concerns about how to set-up my level in Ogmo, because if I set off on the wrong foot I may not have enough time to backtrack and try again.

So if the more experienced developers can help me out, I will be greatly relieved.

About the game (abridged):
Game is a top-down view of the world, level will scroll, camera will follow the player.
The player will be moving along a path, and cannot move off the path.
There are three types of path. They intersect regularly so the player can change paths quite often.
The player's movement speed on each path will vary a lot, in real time. There's going to be some math working out the speed on each path depending on the player's distance traveled on each path.
(optional) the path will reveal itself slightly ahead of the player as he moves along (animated path)

What I have to keep track of
I need to know at all times which path the player is on
I need to keep track of the distance traveled on each path
I need to know how many times the player changes paths
I need to keep the player ON the paths.
(optional) I have to know WHERE the player is to draw the path in front of him.

How I'm thinking of setting up the level (i.e. what worries me)
I'll be using Ogmo  
For the paths, I have (at least) two options:

Option 1:
Use an <object> layer, and have three objects <object name="path1"...> each representing a single "tile" (i.e. a chunk or portion of) for each type of path. In the editor I will place these objects to basically draw each path. Once I import the level, I will assign to each object a flashpunk (fp) Entity with a property to distinguish each type of path. Shit, that's going to be a lot of Entities placed one next to each other to display the path...

Option 2:
Use three <tiles> layers, one for each type of path. Once I import them, create three Entities and assign the corresponding Tilemap with a type="pathType" so I can distinguish which Tilemap the player is on. I guess I will also need a <grid> for collisions.

How the hell am I going to handle intersections? Frankly I just don't know at this point. I do need to work out some kind of layer system so I know, where two paths meet, which one is on top (that's the one the player will be on).

For keeping the player ON the path, I could either create a <grid> that borders each path and check collision against it, or maybe just make sure that I'm always colliding with the path, which would save me from drawing that grid.

Well, that's kind of where my mind is right now, but I have so many blind spots given my inexperience that I thought I'd put this out there in case someone spots a gaping hole in my logic.

Thanks for your time and dedication to the cause.
ps: I originally posted this on the flashpunk forum, and Chevy convinced me to post it here...

[Triplefox]

If I understand correctly, the problem you're having is a "wrong data structure" problem.

From everything you've described, the space in between intersections and corners is irrelevant, so in this case your editing format could be a list of points(or a list of lists, one list per path), possibly containing some metadata. Lists are easy to code with, so this is nearly ideal. You would probably want the runtime structure to be a node graph instead - then intersections are just nodes with 3+ connections. Your player can pretty much ignore other forms of collision for movement purposes - it can just stay locked on a "node A to node B" connection, which is super-simple to interpolate, get distance for, etc.

Then figure out how you could draw the path data in a way that won't leave you crying by the end of the project after doing 100 levels or whatever. I would lean towards "in-game editor" if I were implementing, because:

 * It's really easy to do a point placement or tile picking algorithm.
 * The UI needed is simplistic: "Start path type A/B/C", "Place point on path", "End path", "Delete path at point", "Save." Assign them to hotkeys and mouse clicks and you have your editor.
 * You won't have to do an elaborate source format transformation if you start from the list-of-points format. To go from list to graph is just a matter of an exhaustive comparison of every point for overlap.

My estimate for doing it this way is "weekend project."

A second option would be to place entities or tiles in Ogmo that only contain intersection and corner information. Then you do raycasts to generate the full graph from the entities. This would require entities to be grid-aligned, I don't know if that's the default in Ogmo; tiles could coexist on one layer, you'd just need lots of tiles to cover all intersection types. One thing that's kind of ugly about this is that you'd have to run raycasts for every corner and intersection, get doubles, and then filter them.

[supamanu]

Wow, you made me realize that I forgot a crucial bit of information: you control the player with the keyboard (up, down, right, left), but I won't allow him to leave the paths he's moving on. 

Also, the paths will be set in the level, I don't actually have to programmatically (if that word even exists) generate them from the intersections. And there's only one level, so not a ton of work to build them. Ogmo aligns things really nicely.

I guess I'm trying to figure out, given my objectives, how best to combine Entities (representing individual objects or Tilemaps) to give me the flexibility I need for all the collision detection and calculation required for my game. And because how I lay out my level in Ogmo -i.e. what layers I use - also influences my choice of Entities (since I will parse the xml and convert all the various elements to Entities), I need to make the right choices upfront.