| |
Mapping code & battle systems Displaying 1-7 of 7 total.
1
locke
|
While I suspect someone is about to tell me that this has been done, I was wondering... will the map code be extensible enough to use as the underpinnings for a battle system?
After spending... what... like 3-4 weeks on a grid-based battle system (which works, suprisingly), I realized that with sufficiently open-ended mapping code, I could achieve the same effect with much less work. Rather than trying to hand-write a tile-based movement system, like I did, I could just use the map code to handle the grid, etc.
So the root of my question comes down to this: will I be able to wrap a turn-based battle system around a map. Example: I have a large overworld map, which works as "normal". Entities wandering around, player controlling a character who wanders around at will. But.. when a battle starts, the player is moved to a "battle" map, and some turn-based code controls the action, rather than the open-ended "wander around the map" state.
Was that clear-ish? I assume that I could just have the battle move the player to the map, and have the map's "main" function (what is it referred to here? the "autoexec" function?) immediately go into a turn-based mode.
Hmm. This would require VC access to map data and state... like coordinate (tile) data, and it would be great if the animation loops could keep cycling in the background.
Possible?
Thanks.
-l
Posted on 2004-03-11 20:42:16
|
vecna
|
Yeah this is pretty much doable. Its not how we're doing the battles in Sully 1 but its pretty much the best way to do any 'tactics' type something where the entities are going to be moving around and stuff. And v3 makes it easier than ever to have VC in control of the main game loop without having to redo everything the engine can normally do for you like timing and entity movements.
Posted on 2004-03-11 20:51:15
|
mcgrue
|
In hero rancher's Shining-Force battle system, I recursivly built the movescript using a modification of the same function I used to figure out where it was legal to move.
It worked very well and on the first try. It pleased me.
So, if v2 can do it, v3'll be able to do it...
Posted on 2004-03-11 21:15:20
|
grenideer
|
Yeh. Diver Down's battlesytem wasn't tactics-based at all, but the party was represented by chrs on tile positions, that could be moved and all.
What you're talking about doing would be really easy to do, even in v1.
Posted on 2004-03-11 21:37:03
|
locke
|
Fantastic.
I've become hooked on "Tactics"-style combat systems, and it's definitely something I'm looking forward to designing for. Being able to use the already built display code, chrs, entity movement, and the like, will greatly enhance the quality and reduce the development time.
Can you effect the main game loop without effecting the tile animation routines? A small point, but I'm just curious. On a side note, I'd love to learn a little more about how the mapping code is implemented. Like, is the map display code below the rest of the display code (the functions we are all mucking with right now)? Meaning, do we (designers) have to draw the map in our own loop, or do we release control to the map code which has it's own rendering loop, and use triggers to spawn functionality? Clearly I have no idea how this all works. But I am definitely curious in what's going on under the kilt.
Might you be willing to release some (basic) documentation of the mapping-code API? Maybe just a list of functions to whet our appetite?
;)
-l
Posted on 2004-03-11 21:56:25
|
vecna
|
Releasing the 'mapping code api' would be pretty underwhelming, becase I've intentionally tried to keep it as simple as possible, so its even smaller than in V2.
For instance, two functions in V2 that we've gotten rid of are UpdateControls and ProcessEntities(). UpdateControls still exists but really you never need to call it. UpdateControls now happens automatically when ShowPage() is called (its been like that in the past V3 releases) - and ProcessEntities was the source of many problems in V2 because it depended on the vc programmer getting the timing right - eg, its supposed to be called 100 times per second. So instead, ProcessEntities happens every time you call Render() and its automatically called at the correct rate. And yes, tile animations are taken care of when you call Render, regardless of whether its a VC main loop or if the engine is controlling the main loop. Another timing issue was simplified, in V2 games you frequently ran into the problem of being in say a text box, and if you held down when the textbox ended, you'd shoot down like 30 tiles. That won't ever happen in V3 either. All of these were due to people misunderstanding how timing in V2 worked, but to be fair, it even confused me sometimes, so, this time it's all much simpler.
As far as access to map data... there's a pretty standard set of tools that have been in since V1. Get/Set tile index, Get/Set zone index, Get/Set obstruction [tile index], and also theres a GetObsPixel() routine which returns the pixel accurate obstruction value for a coordinate, but there is no matching Set routine for that. And yes, there is a BlitTile function to give you access to the tileset (I think Omni was asking about that).
Anyway, the beta version with maps, entities, tools and a limited Sully demo is not too far off, because it'll be at least a month before we can polish everything we want to take care of before the first 'official' release and I don't want to wait that long - plus, stuff is again, usable right now, so theres no reason to not let people get started working on things, reporting bugs, etc.
Posted on 2004-03-11 22:42:29
|
locke
|
Excellent! Thanks for the info. The timing issues you mentioned are the source of my inquiry. What you do behind the curtain is clearly black magic, and I'm glad to hear you are making efforts to simplify the whole process. Keeping the cauldron and lighting bolts away from us designer-types helps us make better games. :)
Thanks again.
-l
Posted on 2004-03-11 22:55:12
|
Displaying 1-7 of 7 total.
1
|
|
