obstructions
Displaying 1-14 of 14 total.
1
RageCage
|
I got a question about V3. Will obstructions turn out the same size as the tiles, like all the other current engines, or will the obstruction system is independant of the tile system?
Posted on 2004-02-18 01:53:05
|
Overkill
|
I'm pretty sure they're opting for pixel-accurate and not tile-accurate obstructions now. At least, I think I read that a while back.
Posted on 2004-02-18 02:05:50
|
Tatzen
|
This is one of the things still in discussion, and will be decided on very soon. We've thus far considered using a number of different obstruction systems. One idea is to give the developers a "set" of obstruction types.. hard-coded presets that cover almost all the obstruction needs. Another idea has been line-based obstructions, which I'm not for. The last considered idea is a obstruction "VSP"; a monochrome spriteset used to check against obstructions... white=Obstructed, Black=not.
It's all up for grabs at this point. However, I can say that the days of Single Tile Obstructions are over, and something better will definitely be used instead.
Posted on 2004-02-18 03:09:56
|
Rayner
|
Why aren't you for line-based? Seems like a simple obstruction layer that a person can draw obstructing lines onto is all that's needed. Simple and functional.
Speaking of layers: How will they work? Will there be a limit to the amount that you can create?
Posted on 2004-02-18 08:01:55
|
Tatzen
|
Unlimited layers. Parallaxing has been updated to use 'double's instead of the old Mult/Div integers. Layers can now have names.
Posted on 2004-02-18 08:42:07
|
Overkill
|
I say the '.vsp method' sounds ideal, but I suggest a seperate file type for the obstructions, like '.obs'.
Maybe even make a file called 'maped.obs', that stores the standard types (the full box, half, triangular slope types, maybe circular obstructions...)
Come to think of it, you'd only ever need one obstruction set file... Just some ideas, since it's still in the thought phase.
Posted on 2004-02-18 23:16:58
|
andy
|
aen wrote up a good little rant thing about why vector obstructions are a good idea. He brings up some very good points.
Posted on 2004-02-18 23:38:51 (last edited on 2004-02-18 23:39:19)
|
Omni
|
Aren't vector obstructions and line-based obstructions pretty much the same thing? Granted, vector obstructions don't require a graphics layer of drawn wires, and are probably more memory efficicient, but isn't the outcome basically the same thing?
I personally think line-based obstructions (we are talking what is similar to Zeux and 4Four's method, right?) are ideal because even though they take up space, they are versatile. If the graphics layer is exposed to the player, they could drawn and erase lines as they see fit--in fact, they could create realtime obstructions like tilting platforms or circles simply by drawing them using the appropriate commands to the line obstruction layer in real time.
In addition, if you're working in a OOP environment, there could simply be a giant sequence of obstruction objects--perhaps of different hardcoded types (fixed-line, circle, rotating line) that could be iterated through and blitted fresh to the obstruction buffer, perhaps with an obsobject.Draw() method during each loop of the game logic. This isn't going to work for V3, mind you, unless perhaps obstructions were managed by a similar structure to the versatile array that handles entities. It is still intriguing, however.
Slow, maybe, but versatile.
Posted on 2004-02-19 00:02:50
|
Overkill
|
That actually isn't a bad idea. It be really cool if that allowed for 'curving' of movement, so it would be possible to make side-ways stairs because you follow the obstruction line (like FF3's stairs, if you can imagine that possible).
Posted on 2004-02-19 00:06:12
|
andy
|
errr.... 'line' and 'vector' are equivalent in this context.
Posted on 2004-02-19 00:09:51
|
Omni
|
My mistake. I thought "line" used a pre-concieved bitmap that contained lines drawn for obstructions while vector obstructions were simply managed only by code.
I guess what I was really trying to compare was how the information for the obstruction should be stored (in bitmap or code), not the actual type of obstruction (of which I personally now prefer line/vector).
Posted on 2004-02-19 01:25:12
|
Tatzen
|
Well, like I said, it's in discussion. All of the methods have their own benefits over each other, and a decision will probably be made soon. The input is useful, however. Thanks.
Posted on 2004-02-19 02:58:30
|
Omni
|
Hey, no problem.
Posted on 2004-02-19 04:38:37
|
vecna
|
Obstruction format will be finalized this weekend. I will post more about it afterwards. It will probably be pretty close to the entity system constructed for the original V3. Because then I wont have to change much ^_^ I think its a pretty flexible compromise.
Posted on 2004-02-19 04:59:01
|
