| View previous topic - View next topic |
| Author |
Message |
tcaudilllg
Dragonmaster
Joined: 20 Jun 2002
Posts: 1731
Location: Cedar Bluff, VA
|
 Posted: Tue Jul 06, 2010 9:55 am Post subject: |
[quote] |
|
To create the illusion of simultaneous movement, I am splitting off the event scripts from the action execution system. Basically, the event scripts change data and order the system to take specific actions. These orders are kept in a queue system and are executed with each phase of the actor loop.
Here is the pseudocode for the actor loop:
| Code: |
If loop is active
* For each actor
** If actor is active
*** process events
* do actions
|
The actions are executed indiscriminantly: the order of their execution has nothing to do with the order of the actors in the cast roster. First come, first serve. The idea is to make them seem as simultaneous as possible.
Another thing I'm working to do is make it so each map has its own distinct set of actors. The actor designated as the player has the special ability to change maps by walking between them. Goals for the current edition are pixel-by-pixel and tile-by-tile movement. Tile-by-tile movement is already implemented, and pixel-by-pixel is underway.
One of my goals for making a system capable of keeping several maps in memory at once, is to make background effects and menu maps possible. I think the best way to make menus is to make them tile maps, plain and simple. When you go to a menu, suspend the main game action and activate the menu map. Unite the worlds by making variables common to all maps.
One potential matter of concern: my system for computing collisions checks every tile of the map at every tick of the game clock. For small maps of just a few hundred tiles, this isn't a problem... but I don't think it can scale that well, certainly not with the scripting overhead. Additionally my method, although memory efficient, is not performance efficient. It keeps a record of each actor currently on the tile: when actors move onto the tile, their index in the roster is clamped onto the end of this record. The record is itself a string that is exploded at the beginning of every cycle. This must be done for every tile. I'm trying to think of a way to keep a record of the records, that will remember which tiles have sprites on them and which don't. Assuming 20 cycles/sec, that means 64k * 20 = ~1,280,000 checks per second on a 256x256 map; which, I think, would make Javascript choke.
|
|
| Back to top |
|
 |
  |
Page 4 of 4 |
All times are GMT
Goto page Previous 1, 2, 3, 4
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
