WIP: Wizard of Wor

[tschak909]

Damn, Kasumi...you might be right

-Thom

[tepples]

What I tend to do is take the next major task and then repeat the following iteration:

1. Find the first task on the list that I expect to take longer than 15 minutes.
2. If one exists, divide it up into smaller tasks.
3. If a task was split, and there are fewer than 12 tasks, go to step 1.

[tschak909]

if I could, I'd hug you guys. Thanks.

-Thom

[tschak909]

Am back on WoW, have been so busy lately, and health issues caused me to have to take a break.

Right now, I am refactoring the code, and splitting bits out into seperate files.

In the main .h, I have a set of variables defined in my zeropage bss segment. The problem seems to be when I try to use them in other files. It seems:

Code: Select all

#pragma bssseg (push,"ZEROPAGE")
extern unsigned char spr,i,frame_cnt;
#pragma bssseg (pop)

Produces an address mismatch:

Code: Select all

ld65.exe: Warning: Address size mismatch for `_frame_cnt': Exported from wow.o, wow.s(25) as `zeropage', import in attract_monsters.o, attract_monsters.s(31) as `absolute'
ld65.exe: Warning: Address size mismatch for `_i': Exported from wow.o, wow.s(18) as `zeropage', import in attract_monsters.o, attract_monsters.s(30) as `absolute'
ld65.exe: Warning: Address size mismatch for `_spr': Exported from wow.o, wow.s(24) as `zeropage', import in attract_monsters.o, attract_monsters.s(29) as `absolute'

For some reason, it's ignoring my #pragma and using .import instead of .importzp :/ wtf? I know I'm doing something silly...

What's going on?

-Thom

[tschak909]

err, turns out I literally had to do this:

Code: Select all

extern unsigned char spr;
#pragma zpsym("spr")
extern unsigned char i;
#pragma zpsym("i")
extern unsigned char frame_cnt;
#pragma zpsym("frame_cnt")

Which is....really fucking awkward...but okay.

-Thom

[tschak909]

Enough refactoring was done that I was able to start work on shooting the lasers for the player.

The logic has become quite complex, ensuring that all possible states are being taken care of (there are still a few stray state leaks that I need to plug up), resulting in very dense blocks of ternary conditionals...I will try to document these once they've stabilized.

I am currently using yellow's score to track his states (player left idle, player left, player left shooting, player left shooting idle, etc.), as well as his previous state, and whether the shooting latch is active.

There are still a ton of bugs, and I am working through them, but for now:



-Thom

[tschak909]

First pass of player shooting implemented, now implementing monster shooting.



Latest binary here:

wow.nes

(40.02 KiB) Downloaded 160 times

[tschak909]

I've now implemented the first pass of monster shooting.



I initially tried to be somewhat smart about monster shooting; only shooting if the monster sees a worrior in its field of vision. This wound up taking up too many cycles, slowing down the entire game, even if all I was doing was checking for the same X or Y box through wall boundaries, especially since I didn't want them to shoot continuously....so the implementation I wound up using was far more naive:

Code: Select all

void monster_shoot(void)
{
  // This is holy shit naive. The previous naive implementation took too much CPU time.
  if (rand8()>0xC0)
    {
      if (((rand8())<0x08) && lasers[LASER_SHOOTING(i)]==0 && monster_laser_count<4)
        {
          monster_laser_fire(i);
        }
    }

  if (lasers[LASER_SHOOTING(i)]==1)
    {
      get_current_laser_box();
      if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_RIGHT)
        {
          if (BOX_WALL_RIGHT(h) && lasers[LASER_X(i)]==PIXEL_BOX_X(e))
            monster_laser_stop(i);
          else
            lasers[LASER_X(i)]+=4;
        }
      else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_LEFT)
        {
          if (BOX_WALL_LEFT(h) && lasers[LASER_X(i)]==PIXEL_BOX_X(e))
            monster_laser_stop(i);
          else
            lasers[LASER_X(i)]-=4;
        }
      else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_DOWN)
        {
          if (BOX_WALL_DOWN(h) && lasers[LASER_Y(i)]==PIXEL_BOX_Y(f))
            monster_laser_stop(i);
          else
            lasers[LASER_Y(i)]+=4;
        }
      else if (lasers[LASER_DIRECTION(i)]==STATE_MONSTER_UP)
        {
          if (BOX_WALL_UP(h) && lasers[LASER_Y(i)]==PIXEL_BOX_Y(f))
            monster_laser_stop(i);
          else
            lasers[LASER_Y(i)]-=4;
        }
    }
}

I will definitely have to be careful with the blue worrior auto-move implementation (when playing 1 player), as it's clear that I am low on non-NMI cycles.

Latest ROM here:

wow-monsters-shooting.nes

(40.02 KiB) Downloaded 152 times

[lidnariq]

I'm curious about how you were losing so many cycles on just a bounds check ... maybe memory pointers ?

[tschak909]

I'm curious about how you were losing so many cycles on just a bounds check ... maybe memory pointers ?

I will revisit that later. I'm guessing that sometime soon I will need to do some significant code optimization. If you want to see where things are @ this point, the code as always is in github: http://github.com/tschak909/wow

Now i'm deliberating on whether to implement blue worrior ai logic or to implement the kill logic first.

-Thom

[tschak909]

Initial pass of Worrior AI logic implemented. However, I need to figure out why the blue worrior's laser isn't showing...

-Thom

[tschak909]

My 4yo daughter Nina helping me debug Wizard of Wor.



-Thom

[tschak909]

Ok, so first pass of blue AI is implemented. It's very naive at the moment, it simply picks a monster and starts walking toward it, shooting intermittently.

There was an odd situation where update_lasers() was short circuiting an over eager check to see if a laser should update, which was causing blue worrior's laser to not be visible. Fixed...

The random number seed is currently reset every 5 seconds and the player X position is used, to try and randomize player positions.

Currently, since no kill logic is implemented, once the blue worrior catches up to his enemy, he simply keeps chasing it, close behind, shooting intermittently.

Once kill logic is implemented, I will alter this to try and shoot any monster in path while traversing toward enemy...

There is also a very occasional intermittent slowdown when multiple lasers are visible from enemies...need to start optimizing soon.

And yes, I know, some sprite priority issues. I need to actually work on a sprite scheduler, as I don't think I have the bandwidth to put the phasors into vram updates.



Latest ROM attached:

wow-blue-ai.nes

(40.02 KiB) Downloaded 157 times

-Thom

[tschak909]

I've just drawn the explosion sprites. Am now implementing kill/explode logic:


I'm also fast running out of CHR ROM.



-Thom

[tschak909]

Ok, major milestone, player to monster laser collisions implemented, along with explosions, monster death, and points.



Still some weird little sprite bugs that I need to track down there, as well. I'm having to tiptoe very well to make sure I don't run out of cycles doing e.g. bounding box comparisons, but it seems to be working ok, so far...

I'm happy this is starting to resemble a game.

Latest ROM build attached, and as always, code is available on github in the original post.

wow-monster-splosions.nes

(40.02 KiB) Downloaded 153 times

Moving onward.
-Thom