Spacky Emprise Series - Contest Entry - Release

[LincolnB]

I've started a new project, called Spacky Emprise for the TI-83 plus series of calculators, written in Axe Parser. It's a platformer series of games, so far we're looking at about three games featuring our character, Spacky. It's a run-and-jump style game with a racing objective; pretty much beat your enemy to the end of the level or you melt. Development is about 60% finished on the first game, and some concept stuff has been done on the second and third games in the series. Basically each game is going to be an improvement on the last, with all new levels and added features, expansions and stuff like that; power-ups, different types of enemies, constantly improving graphics and animations, etc. Release date for Spacky Emprise (the name of the first game) is late July, 2011 obviously. Screenshots and whatnot to come.


EDIT: Game's finished. Check it out from my website, buttsfredkin.co.nr, or search it on ticalc.org.

Screenshot:



Not much, but I accomplished what I hoped to with this game. Look for a sequel that's going to be way better.

[ralphdspam]

Wow!  Sounds like a great project! 
Do you have a level editor planned?

[ztrumpet]

This sounds pretty awesome.  Good luck!

[t0xic_kitt3n]

Sounds cool!
It's too bad the contest wasn't half a month later, you could have entered it. Though if you really work hard, I'm sure you can finish it.

[LincolnB]

Thanks, I'm pleasantly surprised at how responsive/supportive the community around here is.

@ralphdspam - Yeah, I'm planning on releasing a level editor, but adding support for external levels will take some re-coding, because right now the 50 levels I'm using are all but hard-coded into the program itself, seeing as I can't really think of a way to scan through the appvars on the calc and determine which ones are levels/worlds and which aren't (a world is 10 levels, btw).

I'm totally open to any community suggestions / techniques / tips or whatever else you guys have up your sleeves, tricks you've learned over the years and stuff.

@t0xic_kitt3n - Thanks. Right now I don't really have anything better to do so I've been coding this game up to like 5 hours a day. I'm hoping to be able to submit it to the contest, we'll see what turns out.

Right now I kind of a have a problem, a pretty minor problem, but it's there nonetheless. Anyways, the problem is that all 50 levels put together take up about 60,000 bytes of archive. To me that seems like a lot. What do you guys think? All the levels are packaged into 5 appvars of 12,000 bytes each, one appvar per each world. It's not so bad because the appvars can stay in Archive, I'm utilizing the File access ability of Axe (using Y1 and such), but to me it seems like most other games don't have level files that big. I'd be very interested to know how that Sam Heald guy made his Super Mario levels, if anyone knows anything.

[ralphdspam]

@ralphdspam - Yeah, I'm planning on releasing a level editor, but adding support for external levels will take some re-coding, because right now the 50 levels I'm using are all but hard-coded into the program itself, seeing as I can't really think of a way to scan through the appvars on the calc and determine which ones are levels/worlds and which aren't (a world is 10 levels, btw).

You can have a string at the beginning of the file and have your program check it.

For example, each of your level packs (or what you would like to call them) can start with [31415926] or something.  Then you would have your program scan through all of the appvars and list those that match up.

Right now I kind of a have a problem, a pretty minor problem, but it's there nonetheless. Anyways, the problem is that all 50 levels put together take up about 60,000 bytes of archive. To me that seems like a lot. What do you guys think? All the levels are packaged into 5 appvars of 12,000 bytes each, one appvar per each world. It's not so bad because the appvars can stay in Archive, I'm utilizing the File access ability of Axe (using Y1 and such), but to me it seems like most other games don't have level files that big. I'd be very interested to know how that Sam Heald guy made his Super Mario levels, if anyone knows anything.

(I'm assuming your levels are tilemapped.)  I have no idea how Sam Heald made his Mario Levels, but Run Length Encoding is an effective and easy-to-implement compression technique. 
http://www.omnimaga.org/index.php?topic=1532.msg50859#msg50859
http://www.omnimaga.org/index.php?topic=1532.msg49189#msg49189

[XVicarious]

How many tiles do you have? If you have 15 or less you can use nibbles. or half bytes.

[LincolnB]

@jkag - that's a pretty good idea. how do you edit nibbles in axe parser?

@ralphdspam - Just double checking, tilemapping levels means doing it like this, right?:
appvarWORLD1: (first 160 bytes)
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 1 0 0 1 1 0 0 0 0 0 1 0 0 0
0 0 0 0 1 1 1 0 0 1 1 0 0 1 0 0 1 0 0 1
1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 1 1
where '1' corresponds to a pic100 or something, represented here by




                   
                  
                                 
   
I'll be sure to check out those routines as soon as I can.

[ralphdspam]

@jkag - that's a pretty good idea. how do you edit nibbles in axe parser?

@ralphdspam - Just double checking, tilemapping levels means doing it like this, right?:

                    
                  
                                  
   
I'll be sure to check out those routines as soon as I can.

Yep, that's tilemapping.  

[XVicarious]

Okay. Nibbles work like this, a normal tilemap would look something like this:

Code: Select All | Copy To Clipboard

1 2 3 4

010101 010001 010101

01 and 00 are tiles. Each is a byte.
A nibble is a half byte. The same map would look like this:

Code: Select All | Copy To Clipboard

1 2 3 4

111 101 111

That is half the size of the other map.

When reading from the GDB with nibbles you use nib{} instead of {} and you need to multiply GDB by 2, but just GDB so do it like this nib{V*8+H+(GDB0*2)}, or however you have your tilemapper set up with the variables.

[LincolnB]

@jkag - that's cool. I didn't know about the nib{} command.

@ralphdspam - is RLE compression basically just this nibble thing we've been talking about?

[XVicarious]

No it isn't. They are two different things. Nibbles are just half bytes. RLE actually compresses it.

[LincolnB]

Well, I know, but what I meant was does the RLE compression subroutine do this exact thing, go through the variable and shorten all the bytes into nibbles, and the decompression subroutine goes back through the variable and inflates all the nibbles?

[XVicarious]

No it shortens it into hex. Really I think it would be over kill to employ both methods. I'm not quite sure with RLE on nibbles though. I have really never used RLE.

[leafy]

Remember that RLE only compresses if you don't have too many changes in tiles. If you have rows and rows of the same tile at a time, then it's worth it - otherwise, no.