The World's Hardest Game

[Darl181]

Direct download of latest version: http://www.omnimaga.org/index.php?action=dlattach;topic=4938.0;attach=4410
a hard level http://www.omnimaga.org/index.php?action=dlattach;topic=4938.0;attach=4416
some more levels http://www.omnimaga.org/index.php?topic=4938.msg86015#msg86015

Since sometime in July, I've been working on porting The World's Hardest Game to Axe.  Finally, I've finished it.
In this game, you pick up 'coins' while avoiding enemies and then try to reach the finish.  Some levels may be easy, while others may be harder.
I went further than the flash version goes, however, and made a level editor.  The levels are created as appvars, but you can export them to linking-program-friendly programs and back again.
 

The game is compatible with the 83+BE, yet it contains a Full Speed Mode option.
More screenies.
 

Known bugs

Using teacher key (DEL), sometimes the location of the player sprite is shifted around, specifically from the very top to the very bottom.

Also, full speed is not reactivated on continue.  It's probably more of an asset than a bug to the person playing it, though.

Sometimes, an enemy seems to get corrupted and is displayed something like a pair of parenthesis while moving twice as fast.



Compile the level editor as an app.  The game can be a program.  The sample level needs to be imported before it can be played.  Just do it at the level select screen.
Also I feel that I should inform you that this program may cause you to lose the game...

EDIT: Current version here (link goes to the post)

[DJ Omnimaga]

Wow I loved that game in Flash despite most levels being very hard, I'm glad it's ported to calcs. When it is finished you should upload it in the download section and ticalc.org. I wouldn't be surprised if this was featured. I'm gonna try it as soon as I can . It looks pretty nice too, by the way . Good luck fixing the bugs!

[Scipi]

I loved this game!

[Darl181]

Oh and another bug--the app randomly deletes itself, so it would be wise to not delete the source.
I think it has to do with it not being signed.

Edit.
I'll try to upload more sample levels tomorrow.  You could easily make your own though...

[DJ Omnimaga]

Oh it's normal. An unsigned APP is like a trial app for the calc. Back in the days, there were paid apps on TI website. After 16 runs these apps delete themselves.

[Darl181]

Ah, that explains it.
I have an idea for how to fix the DEL bug, but the parenthesis bug just baffles me

[Runer112]

I see that you posted the source for all this Darl, want me to try to help optimize it?

[Darl181]

Go ahead
Right now, it's anything but optimized
I was trying to do this.

[Quigibo]

The parenthesis is 2 ball sprites xored on top of each-other with one slightly shifted.  You likely initialized 2 sprites there by mistake instead of 1.  Cool game by the way

[Ranman]

That is amazing! What a great idea!

[Darl181]

The parenthesis is 2 ball sprites xored on top of each-other with one slightly shifted.  You likely initialized 2 sprites there by mistake instead of 1.  Cool game by the way

xor?  What is that?
In any case, I didn't use that.

Maybe I should explain how the appvar is structured.
The first 96 bytes are the static map. That's the walls, start, finish, coins, and respawn points.
The rest of it is the enemies.  Each enemy has three bytes.
1st byte: destination
2nd byte: direction
3rd byte: current location
The starting location is determined by its placement in the appvar.  They are moved one pixel in the direction (2nd byte) until the current location (3rd byte) is equal to the destination (1st byte).  Then, it reverses until it reaches the starting position, again determined by its location in the appvar.
My guess is that I somehow messed up the equation that references the enemies and it refers--and moves and draws--the same enemy twice or something.

Oh and another thing.  Sometimes, when I add another enemy before the faulty enemy, it suddenly starts behaving or another one might turn into a pair of parenthesis and go twice as fast.

[Madskillz]

It does indeed look like the sprites have been XORed.
Basically XOR means that all the black pixels when placed over the top of another black pixel they become white. (All the 1 and 1s become zeros)

So a an 8x8 image of your enemy over laid with an image shifted one row up and placed over the top gives you your parenthesis:
00000000         00000000        00000000
00000000         00011000        00011000
00011000        00111100        00100100
00111100        00111100        00000000
00111100        00011000        00100100
00011000         00000000        00011000
00000000         00000000        00000000
00000000         00000000        00000000

If you watch the enemies when they cross paths with each other they show this effect.

[Darl181]

That makes sense.  The way I have the sprites display is Pt-Change( .

[Madskillz]

Pt-Change( does in fact XOR the pixels

I don't know why it only happens with that one set of enemies though and not the rest.

[Darl181]

My guess is that I somehow messed up the equation that references the enemies and it refers--and moves and draws--the same enemy twice or something.

I think I may have done something wrong in an optimization that I tried to do.  They're doing the exact same thing, the duplicate being one pixel behind.