• Advertisement
Sign in to follow this  

Of sprites and scripts

This topic is 4181 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm toying around with writing a 2D action game, and would like to hear from somebody who has done scripted sequences in these kinds of games. Basically, I'm not sure how the script is called (triggers or once-per-frame background scripts, with conditions?), and how the script interfaces with the various screen objects. My plan was to separate the modelled entities (collision, interface methods such as jump(), shoot(), die(), etc) and the sprites (which are merely the graphical representation of the entities), and a bridge class would exist between these to play the appropriate animations. What would the scripts act on, the entities bound by physics and collisions, or just the graphical sprites? Perhaps I should just keep them as one class... One problem I foresee is when you want to move about the objects in ways that aren't really part of the gameplay. For instance, walking slowly, making a little special animation, things the players usually can't do. I recall NWN or some similar game would keep functions for NPC actions as well as playing pure animations (wave, bow, cheer) that generated no real in-game event. Also, I wouldn't want a lowly henchman enemy to be walking in and gobbling up my protagonist, disrupting my EPIC CINEMATIC. Common solutions seem to be removing all enemies, just freezing them or their AI for the duration of the cutscene, or simply keeping cutscenes in clean rooms where there's nothing to interfere. Anyway, there's no real question here, I'm just interested in hearing from your own experiences, what systems you used. :) If you know any handy articles or books on the subject, do give me a link, or just comment on the above ramblings. ;) I'm kinda stuck on the subject at the moment.

Share this post


Link to post
Share on other sites
Advertisement
I don't know if this is of use to you, but the last time I was writing a 2D game with DirectDraw (yes, it's been that long [smile]), I implemented a very very small animation scripting system.

The level file contained strings representing the animation script that looked a bit like:

"[1,2]:[2,3][3,2]<"

that would translate as - show frame one for two cycles, then frame two for three cycles, then frame 3 for two cycles, then loop back to the ':'.

I then had a system where these were loaded and "compiled" into byte code for a very very simple virtual engine thing that would contain a pointer to the compiled bytecode (if that is not too strong a term for something so simple) that consisted of little instructions like:

show [frame],[cycles]
jump [position]

and so on, just in an int array as I recall. Each compiled script was given an ID number and objects that required animation had a class that could index into one of these bytecode arrays with a Tick() member that would execute one cycle of the bytecode, and an int Frame() member that would return the current frame.

It meant that, say, when my character jumped, I could just do something like:

Character.Anim.Assign(CHARACTER_JUMPING_ID);

and forget about it for the purposes of jumping physics and so on. Any character with an Anim object then just called Anim.Tick() once per frame and its virtual GetFrame() function would call the Anim.GetFrame(), rather than just return a frame like the static block objects and so on would.

It was implemented so multiple Anim objects could point to the same bytecode but had their own position pointer and so on and, for my simple purposes, worked okay.

Anyway, I agree that mixing animation code up with other code is a nightmare and this was my solution.

HTH Paul

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement