Jump to content
  • entries
    334
  • comments
    900
  • views
    258,336

Leprechaun to-do list


Guest

526 views

Now that Christmas is over and I'm not trying to turn 700 slides into a DVD, I need to get back to working on Leprechaun.One item which is working (although I'm not going to post it since it doesn't affect gameplay) is the change to a reflected kernel. I wanted to get that working before the level editor sees the light of day. Kirk Israel has been working on the level editor, but the next challenge is implementing the save & load capability.My next update should include the corresponding level loader so people will be able to play their creations. I'm thinking that future WIPs will include two binaries - one which will play a built-in level, and a "developer edition" which will auto-load a created level.However, I'm thinking I should also give the player speedup / fractional positioning a shot in short order because that will shake up ZP RAM usage a fair bit, which also affects the level data.I also need to go back and do some code cleanup / optimization on stuff that's not likely to change. And I haven't even started to contemplate making some of the suggested radical changes to the kernel away from using BLITs to SC RAM for player bitmaps to a more traditional (ZP),Y ROM lookup.Then there's the stuff on my previous to-do list:Other major to-dos (not necessarily in this order):1. Add the dig/fill logic. (DONE!)2. Scoring w/ score & life display3. Restarting the current level (reset gold)4. Loading the next level5. Enemy+Enemy collision detection. (Hmm, maybe bounce away?)6. Multi-color sprites (depends mostly on cycles in the kernel) (nope, not enough cycles in the right places.7. Title / end screens, music & periphrial support like the AtariVox and Glenn's joy2serial auto-load fob.[EDIT] #6

7 Comments


Recommended Comments

In spite of my intentions, I spent last night banging at a complete rework of the kernel to replace the BLIT code with (ZP),Y lookups. I had a scare for a moment when I realized the range of Y was 0-159 and thus there could be page crossings, which would royally screw up any timings. But then I remembered that if the sprites were after the background bitmaps, that this couldn't happen. (However, it does mean I can't put all of the sprites on one page.)

 

I am happy to say that it looks like it will work. Plus I squeezed in the REFPn so I won't have to store separate left & right sprites. However, I now need to replace the BLIT code before I can test everything out.

Link to comment

:) Sounds like good work with the kernel, Eric!

 

Rewriting the kernel, though often scary and mostly fraught with deadends (for me, anyway), can dramatically improve a game, IMO. With Reindeer Rescue, a bunch of rewrites, to accomodate some of Nathan's ideas, really took the game to the next level, both in gameplay and in how it looked.

 

And is it really necessary for enemies to bump into each other? Do they in Lode Runner? At first thought it doesn't seem necessary except in order to prevent multiple enemies from falling into the same hole.

 

I'm glad you decided to at least take a hack at fractional positioning for the sprites; I think it will make a better game. Well, and for some selfish reasons: I think I will enjoy the game more if everything moves a little bit faster. :D

Link to comment
And is it really necessary for enemies to bump into each other?  Do they in Lode Runner?  At first thought it doesn't seem necessary except in order to prevent multiple enemies from falling into the same hole.

Because the game is deterministic and multiple enemies can fall in the same hole, you can end up with two enemies which overlap forever.

 

I'm glad you decided to at least take a hack at fractional positioning for the sprites; I think it will make a better game.  Well, and for some selfish reasons: I think I will enjoy the game more if everything moves a little bit faster.  :)

Sigh... I already use fractional positioning for the enemies. The difference will be changing the player to use fractional positioning (and the enemies to use non-fractional).

Link to comment
Rewriting the kernel, though often scary and mostly fraught with deadends (for me, anyway), can dramatically improve a game, IMO.  With Reindeer Rescue, a bunch of rewrites, to accomodate some of Nathan's ideas, really took the game to the next level, both in gameplay and in how it looked.

 

I'm working on a kernel for Wormy (another game I started in 1994 but abandoned). Didn't get as far on that one as on Col (Strat-O-Gems) but I've managed a proof-of-concept kernel demo that shows the basic idea is sound. The question is what to do with it.

 

Currently, the kernel supports a 32x16 playfield bitmap for the snake, plus up to 128 objects that can either be mines or goodies (shown using a striped playfield). I've got all this stuff working in a kernel that uses a missile to show the head of the snake; at present, the snake is limited to motion in playfield-sized steps but I've got oodles of cycles to work with. I could also use the ball to move the tail smoothly. My biggest problem is that memory is going to be extremely tight (try fitting a 32x16 bitmap plus 128 objects plus 64 'clicks' of snake tail all within 128 bytes of RAM!) so I don't want to use any more than I must in the kernel.

 

My guess is I'll probably do a few kernel rewrites before the thing is done, making different RAM/time/versatility tradeoffs. Still, even what it does now is sorta neat.

Link to comment
I'm glad you decided to at least take a hack at fractional positioning for the sprites; I think it will make a better game.  Well, and for some selfish reasons: I think I will enjoy the game more if everything moves a little bit faster.  :)

Sigh... I already use fractional positioning for the enemies. The difference will be changing the player to use fractional positioning (and the enemies to use non-fractional).

I guess I misunderstood. :D

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...