New 32k XB Game:ZOMBi (work in progress)

[Sinphaltimus]

Thanks for that the zombies getting stuck at holes I noticed last night. I think it had to do with me skipping coinc checks during a player jump/fall. Still have to confirm. I also have disappearing zombies on the known issues list.

V0.51 reduces the performance drop with more zombies but I'm currently working on that at this time.

And I'm using a very primitive loot balance system with RANDOMIZE. That's going to be a challenge since I don't really understand the other "random number methods" other folks use to get better results.

I think I'll have to scrap the random number thing and use a more mathematically precise method to balance loot spawn. I treat zombie spawn as loot when creating levels (see _LDS in the source code)

It's great that you are play testing and posting your results. I really appreciate it. So thank you.

My goal now is to finish up these things ( and then get the new zombie in. Once I'm there, I'll go beta and focus strictly on optimizing everything. Then the final touches.

 

 

EDIT: Updated OP with new Known Issues and To do next steps.

Edited December 13, 2016 by Sinphaltimus

[Sinphaltimus]

Oh bother.

I guess I'll have to address this tomorrow on a more serious tone.



In the meantime, this is what I've been up to...

V0.51 changes:

More optimized collision detection checks.

zombi max speed and health increased at level 50.

Alternate between _ZEDAI and _ZCD for better performance.

Needs a lot of testing - May need to do COINC regardless of MZ= if C<>0 for all **fix mz=**

KNOWN ISSUES:

OUT OF MEMORY!

NOT ALL FUNCTIONALITY OR GAME MECHANICS HAVE BEEN DEVELOPED AS OF THIS VERSION.

Loot balance zombie distribution.

Need to save zedstepr to fix all animation glitches where zed legs slide.

NO ZED MOVEMENT DURING PLAYER JUMP?

When a lot of zombies on screen:

one of two on the same level = 1 Zombi will walk over holes.

Super slow performance during COINC ALL checks. Not so bad otherwise.

I noticed a glitch with multiple zombies.

The last one is disappearing. I think it happens with 3 or 4 zombies

To Do Next:

***test***FIND WAY TO BYPASS ZED COINC WEAPONS DETECTED BY COINC ALL and also ZED vs ZED coinc (make turn around).

Remove sprites for weapons and COINC x,y instead. **CHANGE ZED DIR***

CHECK PERFORMANCE WITH 14 ZEDS, WITH 14 ZEDS FOLLOWING, WITH 14 ZEDS FALLING.

change delay in title screens (checkl Sr. Falcons coments around v048-050)

Mitigate known issues as they arise

Continue to add more comments to source code

[Sinphaltimus]

So I spent the morning compiling all the way through EA5 just so I could test.
It sure is getting tight in here.

Good news is. I still have an undetermined amount of ram remaining for me to compile then test if I had to.

Fortunately, I also trimmed some fat.
Whoa, not much there. LOL

At least I can continue using XB245 to test without having to compile just a little longer....



Probably going to have to cut it short and wrap it up soon. I might have enough room for some music. I dunno yet.

Edited December 16, 2016 by Sinphaltimus

[Sinphaltimus]

I have to say, it's going excruciatingly well today.

That is to say, the few times I get to sit and churn out more fixes, optimizing and adjustments, it has gone pretty freaking smooth being on low ram.

I am able to test in XB256 at speeds that aren't unplayable, they are slow, but not unplayable.

I am hitting some errors like "bad value" but that's just the by-product of so much recoding. Each one gets fixed pretty quickly, then another pops up. That's the excruciating part of going well.

 

That is all. I fully expect an especially optimized and smooth version release sometime tomorrow.

 

I think it will be beta.

 

I'm locking in the features I've already built in. Not enough memory to introduce another zed type.

Maybe not enough memory for music.

Maybe not enough memory for special loot every 10th level.

Maybe not enough memory for a credits screens.

 

Dunno, won't know until I start hitting those limits again.

 

Right now I'm ironing out the bugs created during the last overhaul.....

 

Edit: too many bugs. No release any time soon.

Edited December 18, 2016 by Sinphaltimus

[Sinphaltimus]

pst.... v0.51beta >>>>HERE<<<<

 

 

V0.51 changes:

Continued over-all code optimization. Optimize variables - reduce & reuse - focus on reducing ram requirements.

New optimized collision detection checks.

Zombi max speed and health increased at level 50.

Alternate between Zombie movement and Zombie collision detection for better performance.

Gutted out LO0T array and recoded combat coincs to conserve ram.

Zeds now turn around with loot collision instead of walking over weapons for better performance.

Bonus level every 10 levels (not tested)

90 - all zeds

80 - all zeds

70 - all hearts

60 - all ranged

50 - all melee

40 - all zeds

30 - all hearts

20 - all ranged

10 - all melee

FIXED* zed va ranged loot no good. glitch with heartz bug reproducible.

FIXED* Bullet Issues - visibility & collision issue.

FIXED* NO ZED MOVEMENT DURING PLAYER JUMP?

FIXED* No zed coinc during player fall.

FIXED* Random loot throughout game will give multiple times.

FIXED* When a lot of zombies on screen:

FIXED* one of two on the same level = 1 Zombi will walk over holes.

FIXED* Super slow performance during COINC checks and not turning around. Not so bad otherwise.

FIXED* zed self collide get teleported to top level again. This darn glitch is back. Need to figure it out again.

CHANGED - Zombies will not be able to change levels and there will be no crawler zombie due to 4 sprite per line limit. Maybe I'll make an f18a version.

Edited December 28, 2016 by Sinphaltimus

[sometimes99er]

Good to see that development hasn't stopped.

I like the speed of running. But unfortunately I just run through the levels and don't have to care about much else.

Especially the fall seems to have a few and sometimes rather many hiccups.

At level 93 my running came almost to a standstill and even though on the lowest floor, the screen suddenly cleared as if I had reached the exit. After the score, the next screen shows level 92, but it's empty and nothing happens, though joystick up and down make attack sounds.



Shortly after a Classic99 Cold Reset, I was able to replicate the problem on the first level. No score screen and moving the joystick up and down only made one attack sound, then nothing.

Edited December 28, 2016 by sometimes99er

[Sinphaltimus]

Especially the fall seems to have a few and sometimes rather many hiccups.

 

\Yes - known issue - it's the COINC checks that are killing performance I just narrowed them down to a single instance. Basically, the game suffers from a major performance drop every single time a zombie is coinc with something. That's going to take time to resolve if I can.

At level 93 my running came almost to a standstill and even though on the lowest floor, the screen suddenly cleared as if I had reached the exit. After the score, the next screen shows level 92, but it's empty and nothing happens, though joystick up and down make attack sounds.

 

Shortly after a Classic99 Cold Reset, I was able to replicate the problem on the first level. No score screen and moving the joystick up and down only made one attack sound, then nothing.

 

 

OK, I was able to reproduce this at random it seems. I don't know exactly the criteria that makes it happen. This is going to be fun trying to track down. I have to reduce my code again because I'm nearly out of ram. I wonder if that is what's causing it. But I don't have much room left for code. I'm in a situation where I have to spend hours coding just to free up a hand ful of bytes. I think I'm getting to the point where ZOMBI might not progress past a technical demo. OR I may have to code ti in something besides XB that can compile to FR99 OR give up on FR99 as the final and keep it a disk based game and use RXB.

 

Insane amounts of gratitude for testing each version....

 

 

EDIT: Well, I'm now able to run in XB256 again (freed up some ram) and thank goodness. Finally seeing some XB errors I can work with.

 

 

Edited December 28, 2016 by Sinphaltimus

[Sinphaltimus]

New Version 0.52 beta available >>>HERE<<<

V0.52 changes:

FIXED* Weapons not working against zombies on bottom level of board.

FIXED* There is a glitch where graphics are lost and all sprites disappear.

FIXED* Bonus level every 10 levels starting at 90.

KNOWN ISSUES:

NOT ALL FUNCTIONALITY HAS BEEN DEVELOPED AS OF THIS VERSION.

On levels full of zombies, game is too slow to play. You can experience this on level 90.

Press B to skip to the next board. Need to optimize COINC further.

Highscore screen and you are dead screens need fixing to display score/highscore.

Running low on memory. Barely able to run in XB256 PC Overdrive via classic99.

Loot balance zombie distribution.

Need to save zedstepr to fix all animation glitches where zed legs slide.

[sometimes99er]

Still much the same.

 

 

[Sinphaltimus]

What the? OK, it's a jump, zombie collision, continue to jump thing. It was extremely difficult for me to replicate this time around and it happened on the third jump for me after a zombie coinc. Where for you it happened on the 2nd jump. So bizzare.

Very few places for something to go wrong there so I'm back at it now..

And I played it at least to level 80 without it happening once for me. Dodging zombies and all. I think it's when a Zombie hits you while you are crouched that triggers the inevitable.
I eliminated that making so that while you are squated, a zed can't hurt you.

I hope that fixes it. Going to test a hundred times before next upload.

Edited December 28, 2016 by Sinphaltimus

[Sinphaltimus]

I don't know what to do.

 

I removed the ability for a zed to do damage during a player jump/dodge.
I attempted to replicate the sprites disappearing again and I could not but I was able to corrupt all the sprites.
So instead of them becoming invisible (which is what I believe happens in 0.52) they change pattern (0.53 work in progress).

This is happening in emulation. I haven't tried on real iron as I'm having issues with my console at the moment and don't feel like pulling one out of the box just yet.

However; what in the world could cause this to happen? In classic99?

 

EDIT1:

I now have something to work with. Getting back to it and eliminating the call link in the jump routines to see if this fixes my sprite issues.

Hi.

I was reading up on the use of the assembly utilities for TI BASIC in the E/A manual, and there is mention that the information about the parameters passed with CALL LINK is stored in the stack in VDP RAM, but there is no mention of a location that I can see. How do I access that stack?

Vorticon, you may have touched on something huge for me. My zombi game. I'm stuck. Getting char pattern corruption. I know when running the game without corruption then breaking out and checking SIZE I get like 800 bytes of program free. The CHAR pattern corruption happens during multiple jump routines daisy chained. I am using a call link delay as part of the jump routines. This could be what's corrupting my char codes! And away I go!

Source:http://atariage.com/forums/topic/260519-vdp-stack-access/

 

EDIT2: awe shucks. I already got rid of THAT call link. But it did lead me to rethink a few things in that area of code. So about to compile and test a new version..

Edited December 31, 2016 by Sinphaltimus

[Sinphaltimus]

New Version 0.53 beta available >>>HERE<<<

 

V0.53 changes:

FIXED* There was a glitch where graphics are lost and all sprites disappear during jump routines. Changed _JUMP from a GOSUB to a GOTO and RETURN to a GOTO _SPIDLE effectively by-passing any chance of creating the condition that was causing this. I HOPE. all my tests conclude this is fixed.

Edited December 31, 2016 by Sinphaltimus

[Iwantgames:)]

Pretty cool concept, I haven't played too much yet but does it get harder? I went through about 5-6 levels and it's pretty easy. Anyways good work so far

[Sinphaltimus]

Yes. It progressively gets much harder but there's still a lot of work to do. Thank you for the compliment.

 

EDIT: Today I focus on increasing performance when there are 14 ZEDS on screen (see level 90).

This issue has plagued me ever since I gave the Zombi's the gift of motion.
I have some ideas that should dramatically increase performance while reducing code.

 

It's going to take a lot of planning first, then time to implement and test.

 

Maybe new version today...maybe not. We'll see how well I can mitigate distractions.

Edited January 1, 2017 by Sinphaltimus

[Sinphaltimus]

 

Still much the same.

 

 

 

 

I'm pretty excited to see you try v0.53 - please note, performance drops with lots of zeds is still a major issue. Working on that today. You can skip through levels with the "B"oard advance key (developer cheat).

[sometimes99er]

I'm pretty excited to see you try v0.53 - please note, performance drops with lots of zeds is still a major issue. Working on that today. You can skip through levels with the "B"oard advance key (developer cheat).

 

Well, didn't run into the game freezing (sprites disappearing).

 

Jumping has a rather long pause to begin with, - the player sits, patiently, taking no damage before doing the actual jump. So I run a lot and only jump when a zombie gets too close. Bottom line, no damage taken = game too easy.

 

Animation below is not frame by frame perfect but overall speed is more or less spot on.

 

 

 

 

 

 

[Sinphaltimus]

 

Well, didn't run into the game freezing (sprites disappearing).

 

Jumping has a rather long pause to begin with, - the player sits, patiently, taking no damage before doing the actual jump. So I run a lot and only jump when a zombie gets too close. Bottom line, no damage taken = game too easy.

 

Animation below is not frame by frame perfect but overall speed is more or less spot on.

 

 

 

 

 

Yeah, I'm still trying to figure out the squat pause jump damage thing.

Previously, you could jump all the time everywhere and it was the fastest and safest way to get around the board.

I added the pause to make jumping slower than running and I added damage while squatting so you'd have to really time your jumping if you need to dodge a zombie.

I was also calling the jump routine from many different places with a gosub/return.

Then the disappearing sprites became an issue.

 

I fixed that by eliminating the GOSUB and making them GOTO and replacing the RETURN with a GOTOI Sprite idle line number. And since I wanted to eliminate all possibilities, I removed damage while squatting. This got rid of the sprite disappearing issue.

 

So today I'm working on enhancing the COIN routines again to get better performance from the Zombi COINC calls. The Zombi COINC calls ARE EXACTLY the cause for the performance drops. So the better I can optimize thoise, the better overeall performance will be. All while attempting to squeeze some more program memory out of it. Fun Fun Fun.

 

Once I get this part done (About to compile now) I will add the squatting damage back if I can without reintroducing the sprite issue. If the sprite issue comes back then I really have to dig in to the damage while jumping path and figure out once and for all why this happens.

 

 

So glad you couldn't break it today.

[Sinphaltimus]

New version 0.54 is available >>>HERE<<<.

Nothing major new on front end, just a lot of code optimizations and fixing things that breaks as a result. I wanted to release a stable version of what I'm currently up to since I'll probably be taking a break for a bit. Returning in a week or so.

V0.54 changes:

On Going - Optimize variables - reduce & reuse - save ram. Was able to free up 200-300k program space. More to come.

Eliminated need for Melee and Ranged loot sprites. using call v/hChar instead. Reduces sprites per line in most cases and

gets rid of 2 coinc checks for zeds. This also requires weapons and floors and walls be the same color.

Going to play with the color and try out several different ones. Maybe give a new color every x levels..

[sometimes99er]

... since I'll probably be taking a break for a bit. Returning in a week or so.

Yep, don't let it drive you mad.

 

What can I say to help ? One master delay ?

[Sinphaltimus]

This weekend I hope to do some extensive code review. I have come to the realization that I had set my expectations too high and will be scaling back the scope as well as changing some fundamental game pay mechanics and lowering the number of levels to something manageable, probably around 30 boards. Lowering the boards from 99 to 30 or so will not do anything for performance. The decision is due to not having enough resources to keep a player entertained for 99 levels.

 

Otherwise, a new enthusiasm is taking root. Although, I'm starting a hardware project Dijon do it may delay the next version even further.

Edited January 11, 2017 by Sinphaltimus

[Sinphaltimus]

I just wanted to put this out there - been extremely busy. In looking for side work to get to FestWest I've discovered I can Repent, Quit my job and slack off. Well not really. I am leaving my job in the next couple of months and I am breaking out to do my own thing so as you can imagine, that'll keep a man busy. Zombi is not forgotten. it will be a while before I can pick up development again. In the meantime - I continue to scratch a little bit of progress every once in awhile making a 4 port cartridge extender for myself. You can follow that progress here - http://atariage.com/forums/topic/261105-personal-4-port-cartridge-expansion-project/ - it's actually easier for me to pick that up and put it down at random times than it is to do the same with coding. TTFN.

Edited February 3, 2017 by Sinphaltimus

[Bones-69]

I am digging the way the dude jumps.

[Sinphaltimus]

My biggest challenge with Zombi is making the later levels more difficult by adding more Zombies. This results is a severe performance hit with all the coinc calls that need to be made on moving targets (bot for the player and for the Zombies). I think my largest zombie count on screen is 4 at any given time before the game slows down way too much to be playable. 4 is a bit slower but 3 seems optimal so I'm thinking of Zombi spawn generators where a new zombi will appear after one is killed. i can simply give each generator a finite number of zombies is can spawn based on how far along the player is n the game hence at the higher levels, they will spawn more and more zombies making as opposed to the beginning levels where they may only spawn a few before they stop. The objective is to increase the difficulty as the player progresses. I'll probably also increase the speed of the zombies as the player progresses to add to that level of difficulty later on.

This will require a significant rewrite of some portions of my code but I think I'm getting close to picking this project up again.

[Airshack]

Where’s the latest version? Would love to try it out.

 

 

Sent from my iPhone using Tapatalk Pro

[Sinphaltimus]

Where’s the latest version? Would love to try it out.

 

 

Sent from my iPhone using Tapatalk Pro

It's in the first post of this topic - I Update whenever it's ready for release.