Progress Thread - Isshokuta

I usually work on several projects at a time 'cause I easily get bored and need to switch back and forth to keep the interest flowing, so I have several ideas (some of them in a pretty advanced state) for this compo. I'd like to share one of them 'cause it's me getting out of my comfort area to try new things and 'cause I have developed (probably reinvented a few wheel) a method to drive AIs which may be of interest of somebody, or maybe is something we could discuss.

The project is nothing original, just a side scrolling beat'em'up in the spirit of Spartan or Dragon Ninja (simple as Spartan, but with two height levels just like Dragon Ninja). The idea came to me after I discovered (late, I know) the good ol' Hokuto No Ken in a chinese multicart, and because I felt like pixeling some animations. I had to enhance my custom converter program to handle big metasprites properly, and designed them to take as few different patterns as possible. Thankfully, my converter tool knows how to reuse patterns as much as possible.

The first thing I put together, in some spare time a couple of weekends ago, was a nice finite state machine to control the player movement and animation. Drawing the big diagram on paper I could design all state changes so coding was a piece of cake. Right now, the main player can walk, jump, crouch, change level, punch, perform a low kick and a flying kick. Connecting cells of animation seems to work nicely and the controls feel responsibe and tight. I also managed to cram the scrolling routines to run in the first 32 raster lines, before the sprite-0 split point.

But then it came the need of having quite a number of different enemy AIs, and for some reason I am aiming for pure NROM on this one (well, maybe CNROM for the looks). I'm a C coder and C has a bigger footprint than ASM so I couldn't just throw a bunch of hardcoded behaviours, so I designed a simple language to drive enemy behaviours, and a sort of bytecode interpreter which runs on each enemy, parsing its own "program".

The language allows for loops, checks (about the player and "self"), and some basic actions. Enemies can do almost everything the player does plus throw projectiles, and have a very simmilar FSM to drive them. The interpreter consumes an instruction every frame (or a check and the next instruction in some cases) and modifies the FSM state accordingly. It seems to work great, and I was wondering if this is the method which is generally used, 'cause I have the habit of reinventing wheels.

The programs which drive enemies look like this, for example:


I have written a small compiler which produces a tight bytecode which is easy to interpret. In fact, the bytecode is even simpler than the languages, as some structures can be expressed with a number of simpler opcodes, making the interpreter smaller and simpler:



With this, I only need one function to control every type of enemies, and I can design really complex patterns, which will be great if I have enough space to add bosses.

This works great, I'm having three active enemies and I still have lots of frame time to do collision checks. I'm happy 'cause I haven't come around to optimizing so maybe I can still get better results. We'll see, lots of stuff to add, specially when I introduce projectiles at arbitrary angles.

What do you think of the approach?

P.S. this is how this game looks. The background is temporal. I know the perspective is off, but it somewhat looks nice and retro-looking, from those times back then when nobody gave a crap about perspective

Even though the artwork is temporary I think it looks nice. I like those kind of games so I will be looking for your entry.

Sorry for not giving comment about your aproach, I have been out of nes coding for a long time.

That's actually pretty neat, but if you're aiming for speed and the AI agents don't have too much complexity to them it might be worth to write direct 6502 instructions for them?

I like the art style of the game, good luck!

I code in C, using 6502 to define gameplay is still a far reach for me.

It works great right now. After all, only 1-2 bytes of each script are consumed each update. I even had to add some random skips (frames in which no state changes are done) to make the baddies look more "human", as they took some fractions of a second to react, making enemies with the same program work slightly different, and it seems to works nice. I've already added collisions and projectiles and I still have lots of frame to spare, but just let's see how this all evolves.

As for collision, I'm using a somewhat crude box to box collision and it seems to work. There's a 8x32 (standing) or 8x24 rectangle centered in each actor, plus a 8x8 rectangle in the fist / foot when any actor is hitting. I know this isn't very accurate, but by now it seems to work right. Might refine it in the future. Of course if you just slightly hit one opponent's foot while it passes by it doesn't get registered, but that feels right.

Now I have to work in the way I'll be spawning the enemies. I have several ideas, but can't be decided. My first approach was having an ordered list of spawns (with info about where to spawn -left or right, upper or lower level-, which graphics to use, and which behaviour) so enemies were created automaticly as the player advanced, but I find that would be easily exploitable, as somebody advancing slowly would be able to just spawn an enemy at a time, stop, wait for it, kill it, then repeat. That would kill gameplay, so I must find another approach.

Another idea was stopping the ability to keep progressing in the level from time to time, spawn some baddies, wait for all of them to be gone / defeated, then ket the player keep advancing, like in more modern games like Double Dragon or Final Fight.

I really can't be decided.

Looks pretty good! It's exciting to see so many Compo entry threads popping up. May I ask, which one is the player character?

Personally, I feel like this is better suited in a certain game style. Spartan and Dragon Ninja are both timed. It seems to be a little mixed on whether or not beat 'em ups with this mechanic are timed. Konami beat 'em ups don't seemed to be timed, and I can think of at least one example (Double Dragon for SMS) which removes the timer for the console port. I'd be concerned that the combination of a time limit and movement stopping could annoy some gamers.

You are right, I'm aware of that. I think I should try and play some games of this style to get ideas, and to examine how enemies are spawned and what would be my favourite solution.

Those are the main problems:

- Enough enemies should be on at the same time, and the player shouldn't be able to advance carefully to make them spawn scarcely making the game a walk in the park.
- The amount of on-screen enemies that the engine can handle is not infinite. With three + player + some projectiles flickering is almost unexistent and the engine can manage them with 1/3 of the frame time still free in the worst case, I haven't tried more.
- I'd like to control what kind of enemies are thrown at the player and in which combination.

Old games just threw plain enemies at you continuously (spartan) with the occasional different / tougher / special one. I could do this, and change the kind of enemies spawned based upon the progress in the level, perhaps dividing it in zones, but I'm not sure if this will be fun to play or just a burden.

In sum, I need to play more games Thanks for the insight.

This is the main player:

Timed levels where numerous enemies must be defeated one after another on the same timer certainly annoyed James Rolfe. See the second half of AVGN's review of Street Fighter 2010.

I think I've settled with this implementation:

- Level is subdivided in zones.
- In each zone, a list of possible groups of enemies is defined. A group of enemy is just a list of enemy definitions.
- As per zone, it can be configured if groups come out at once, or there's a delay after each baddie appears.
- As per zone, you can also configure that enemies are respawn as soon as they are killed, after a delay, or not respawned until the whole group has fallen / escaped.
- When defining each single enemy, you can especify where it appears, how it looks, and which program AI will it execute.
- You exit a zone just by advancing, but I'm planning to make the level able to prevent you for doing so, so (if space allows) bosses and sub-bosses are possible.

This way you can plan you level having really frantic areas, less crowded ones, deserted zones where you can focus on jumping gaps, etc.

Let's see how this turns out.

The engine can handle 4 enemies on screen right now plus projectiles. There's still frame time for more, but I'm running out of sprites and I haven't modified neslib yet to stop allowing sprite definitions when the limit is hit. My enemies are sent to the OAM copy shuffled already. May consider this in the future. I find that 4 simultaneous baddies is more than enough.

SF 2010 is so close to being an amazing game. It has so many things going for it, but its flaws weed out 90% of gamers, I'd say. I loved my playthrough of it, but wouldn't even bother it without save states.

I've been working on and off in this project. The main engine is complete (of course, minor and some major tweaks will have to be done, but all the basic bits are there).

I've added dogs which run and jump and do nasty stuff. They are in fact driven by the same FSM and interpreter but have a different size. What I've really done is adding support for different sized and shaped baddies. Regular enemies have two sprite cells per animation frame: one for the top, and one for the legs. Dogs have an empty sprite for the "top" and the dog shape for the "legs". They look fine.

The animation is not mine, I've taken as a reference an animation which I found on the internet and which seems to be free to use and widely used and available. It originates from the work of Dreya Cira. I've just taken 4 of the 10 original frames, resized to fit, and painted over them. They look fine.


I'm also working on new levels. This is a very early WIP. Pools will be wider, I just needed to have all the possible tile combinations in place.

I like the wolf.

Just wanted to stop by and say that I'm still working on this. Lots of tweaks and changes to make this a nice to play simple spartan-X clone. Still have tons of stuff to fix and polish, but I've been working on level 1

This will end up being a CNROM game. I think I can fit everything I want in 32+32K.

We are also working on a very nifty platformer I may show you soon, so stay tuned.

Your work looks great!.