So I decided to use a Process queue for this little game as well, instead of a large case/select list. The queue is pretty much just an index list, to a jump table. Up to 127 entries. The high bit for the index (8bit) is for ‘sleep’ mode of the process (when they need to be temporarily disabled). Processes can remove themselves from the queue, if they’re non infinite types (either by completed tasks or by frame #/counter). Certain higher level Processes can put low priority Processes into sleep mode (like disabling controls for scripted movement, loading a next area/dungeon/etc). There’s also a frame counter to delay the start of a Process once it’s put into the queue.

The overhead is pretty tiny. And reordering the index list and using an early terminator value helps speed up parsing and working with the index. I can prioritize which order the processes get executed simply by the order they are in the index/list, which is also nice.

For instance, I initialized the first area of the game with these macs

AddProcess #READ_IO.process
AddProcess #SEGMOVE.process
AddProcess #FRAMEUPDATE.process
AddProcess #SHOWPLAYER.process

SEGMOVE.process handles the sprite movement and collision detection. When I want to scroll to the next screen (Neutopia style), I add DOSCROLL.process to the queue and put SEGMOVE.process into sleep. Same with WARP.process (stairs/doors/etc).

Maybe it’s overkill, but it just feels more structured and is easier to follow along. I dunno. In debugging, I can see what processes are on the list too – rather than stepping through a large and/or multiple case/select lists.

I’m still trying to stick to my deadline of releasing ~something~ by the end of August (even if just a demo or single level), so I have to worry about feature creep. Right now, the character moves in 16×16 grid movement (and it’s action based, but like Arkista’s Ring). If I have time, I’ll refine the game logic for 1×1 pixel movement. Steps like these take longer in the long run, but helps against feature creep in the short run. Having a moveable character, enemies, and a map/area is top priority. If it’s crude, then it’s crude. But crude is better than nothing. Feature creep has pretty much killed a lot of my previous game projects. I’ve used up two days to add this Process queue system, so not too bad. I have an overworld I can walk around in, along with screens (neutopia style), warps (doors/stairs/etc), map collision, and a few other things. Next to work on is player weapon (projectile), life, and enemy collision and AI.

Of course, I have no pixel art or music/sfx. I have to make sure I have time to whip up some crude graphics (rather than the place holders I using now).

If you guys know of any pixel artists that could whip up something quick, send them my way. I thinking something 8bit in design (16×16 segmented look), but with some 16bit color. I.e. keeping it simple. Characters are similar; 16×16 players/enemies 8bit style (Zelda-ish/Arkista’s Ring-ish). I have a music driver that I’m gonna reuse from a demo thingy.

Advertisements

3 Responses to “”

  1. Why you don’t ask to fragmare for some quick pixels ???

    • I figured he was busy. I’m pretty sure he’s working on quite a few projects (all PCE?). I didn’t want to take him away from those. My art requirements are pretty low, so it’s not like I need Frag’s awesome skills. I’d do it myself, but then it takes time away from coding :/

  2. Man yes is a little bit overkill,but what is made,it will not to be make later .

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: