Hi Guys,
this is my first post.
I am basically experienced game developer and have worked on 3d games like racing and fps. Not used to making shumps.
I am currently making a shump game and have a prototype ready and working on level events system.
I love shumps and grown all along with it. Life Force series / salamander is my favorite. I also still love the music and listen to it.
Question:
I am currently working solo on a shooter game, and am stuck in using a method to handle events in the game.
How are the sequence of events like group of ships coming into the game one after another done? Are they triggered with respect to timestamps ?
Thanks,
Do3D
Level events in shumps
-
Temia Eszteri
- Posts: 43
- Joined: Mon Dec 24, 2012 10:45 pm
- Location: Rainy Seattle
- Contact:
Re: Level events in shumps
My current design for handling level events involves callbacks and appropriate parameters packed into an ordered array of, indeed, timestamped entries. With this layout, I have an index marker that executes and then advances every time the relevant stage timer is equal or greater to the indexed event. Since it's as simple as a set of callbacks, it can handle enemy creation, background-shifting, executing a music fade, etc. etc.
Of course, the problem with this is that the events will have to be presorted, and while you can load new arrays in, it is most decidedly static in design - adding in dynamic events would cause a considerable amount of delay if the array was resorted per a priority queue algorithm, on top of the index marker suddenly pointing to an inappropriate location unless you reset it or used a linked list... which in turn would make resorting still awkward unless using a different algorithm. (Frankly, by the end of the day I prefer to have dynamic events dropped in their own queue so an event list switch won't erase them.)
Also, in a language without dynamic typing, it gets much harder to package the callbacks and their parameters (I'm using my design in Python, and it is convenient - abuse of anonymous functions to pre-pack the callback and its parameters).
What language are you writing this in?
(Pardon me if that was hard to follow - I've never been a good teacher, and moreover it's 1 in the morning for me. I can try again later with diagrams and other helpful material if you would like.)
Of course, the problem with this is that the events will have to be presorted, and while you can load new arrays in, it is most decidedly static in design - adding in dynamic events would cause a considerable amount of delay if the array was resorted per a priority queue algorithm, on top of the index marker suddenly pointing to an inappropriate location unless you reset it or used a linked list... which in turn would make resorting still awkward unless using a different algorithm. (Frankly, by the end of the day I prefer to have dynamic events dropped in their own queue so an event list switch won't erase them.)
Also, in a language without dynamic typing, it gets much harder to package the callbacks and their parameters (I'm using my design in Python, and it is convenient - abuse of anonymous functions to pre-pack the callback and its parameters).
What language are you writing this in?
(Pardon me if that was hard to follow - I've never been a good teacher, and moreover it's 1 in the morning for me. I can try again later with diagrams and other helpful material if you would like.)
Re: Level events in shumps
Yes, I do.Do3D wrote:How are the sequence of events like group of ships coming into the game one after another done? Are they triggered with respect to timestamps ?
Also, I combine that with world-position events. A group of internally-timed ships is being triggered at specific world positions.
Good for placements of ground-based enemies.
-
nasty_wolverine
- Posts: 1371
- Joined: Sun Oct 09, 2011 11:44 pm
Re: Level events in shumps
you have two options, based on how your engine is designed:
Fixed timestep engine -> you can always maintain a queue of inactive enemies that when their defined time occurs become active. you want them active a little outside the screen space or animated them in the scene as if appearing from the background. for ground enemies give them the same velocity as the background. with this method your sequencing has to be done by hand and positioning ground enemies is a bit trickier. i use this method because its relatively simple to implement.
variable timestep engine -> sequencing enemies by time doesnt make sense here. so inactive enemies stored in a queue will have a assigned activation box, and when the active box comes on screen you activate the enemy. this method is very friendly with editors if your building one. its harder to implement but pays off in the long run.
Fixed timestep engine -> you can always maintain a queue of inactive enemies that when their defined time occurs become active. you want them active a little outside the screen space or animated them in the scene as if appearing from the background. for ground enemies give them the same velocity as the background. with this method your sequencing has to be done by hand and positioning ground enemies is a bit trickier. i use this method because its relatively simple to implement.
variable timestep engine -> sequencing enemies by time doesnt make sense here. so inactive enemies stored in a queue will have a assigned activation box, and when the active box comes on screen you activate the enemy. this method is very friendly with editors if your building one. its harder to implement but pays off in the long run.
Elysian Door - Naraka (my WIP PC STG) in development hell for the moment
Re: Level events in shumps
Yeah, it really depends how much you prioritize enemy placement matching up with the level's background map. Personally, I put a much higher premium on having more flexible enemy arrangements, so I prefer simple time/step methods. The advantage to this is that the level can subtly change depending on the player's actions or special stage/enemy events; but still maintain the correct 'flow.' It's also much easier to find that flow when you have consistently spaced spawning intervals that can be tweaked by simply changing a numeric value.
My most recent project actually uses uniform spacing throughout, it just very gradually tightens the time interval variable as the game progresses. Behavior and 'wave' generation (which simplifies things greatly IMO) for individual enemy types has to accommodate for the precise spacing, of course though.
For those enemy types that must have matching background parts, I kind of cheat and might spawn a decorative bg element along with them. For instance: a static base with multiple gun turrets or a road that has tanks driving along it. It might not look quite as good; but that way, you can put them wherever (or whenever) the hell you want and not worry about precision map placement.
Backgrounds by themselves are a whole other issue on their own; but for just stretching out time to accommodate a boss or specific enemy barrage, etc., things like simple looping tricks have worked well enough for me.
That said, if you want your game to have a truly authentic arcade experience, you might have to go the more difficult route. I just wouldn't see any need to yet, personally.
My most recent project actually uses uniform spacing throughout, it just very gradually tightens the time interval variable as the game progresses. Behavior and 'wave' generation (which simplifies things greatly IMO) for individual enemy types has to accommodate for the precise spacing, of course though.
For those enemy types that must have matching background parts, I kind of cheat and might spawn a decorative bg element along with them. For instance: a static base with multiple gun turrets or a road that has tanks driving along it. It might not look quite as good; but that way, you can put them wherever (or whenever) the hell you want and not worry about precision map placement.
Backgrounds by themselves are a whole other issue on their own; but for just stretching out time to accommodate a boss or specific enemy barrage, etc., things like simple looping tricks have worked well enough for me.
That said, if you want your game to have a truly authentic arcade experience, you might have to go the more difficult route. I just wouldn't see any need to yet, personally.