Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: LincolnB on July 08, 2011, 08:07:47 pm
-
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:
(http://www.ticalc.org/archives/files/ss/821/82140.gif)
Not much, but I accomplished what I hoped to with this game. Look for a sequel that's going to be way better.
-
Wow! Sounds like a great project! :)
Do you have a level editor planned?
-
This sounds pretty awesome. Good luck! :D
-
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.
-
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 - 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://ourl.ca/4129/104983
http://ourl.ca/4129/103313
-
How many tiles do you have? If you have 15 or less you can use nibbles. or half bytes.
-
@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.
-
@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. :)
-
Okay. Nibbles work like this, a normal tilemap would look something like this:
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:
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.
-
@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?
-
No it isn't. They are two different things. Nibbles are just half bytes. RLE actually compresses it.
-
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?
-
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.
-
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.
-
Ah runer112, that is true. I forgot about that.
edit, which my game will have tons of tiles in a row, but this isn't my game. but this game appears to have same tiles in a row as well. think of the ground.
-
nib{V*8+H+(GDB0*2)}
* ZTrumpet eats the parenthesis
nib{V*4+GDB0*2+H}
There ya' go. ;)
-
Helpful link: http://en.wikipedia.org/wiki/Run-length_encoding
With nibbles you could simply make each run-length pair one byte, or two complimentary nibbles instead of one byte and then another. For now though, stick with what you're comfortable using.
-
Question: for the Axe Parser contest, are we allowed to use appvars? Kind of a silly question, but you can never be too sure. I would probably cry if I had to hard-code the levels in.
-
Question: for the Axe Parser contest, are we allowed to use appvars? Kind of a silly question, but you can never be too sure. I would probably cry if I had to hard-code the levels in.
Yup. :) There's no harm in using appvars. :)
-
Thank you :)
-
Really? I would kill myself if I had to use appvars. Tricky little blighters.
Also, check the title of the thread, i think it's "Spanky" instead of "Spacky?" Kind of a disturbing name, but w/e ^^
-
@leafiness0 - No, I did that on purpose. You'll see why if you play the game (when it comes out, that is)
-
Game Complete. Check out the first page of this post for screenshots.
-
You are aware that it is against contest rules to provide a download link to your contest entry prior to the deadline of 1 AM on July 16th, correct?
-
Oops! Forgot about that, it's going down until tommorrow.
-
Thank you kindly, buttsfredkin. :)/me gives buttsfredkin a cookie.
Erm..... This may pose a secondary problem, friend? http://www.ticalc.org/archives/files/fileinfo/440/44082.html (http://www.ticalc.org/archives/files/fileinfo/440/44082.html)
-
Oops again.
*buttsfredkin gives himself a spanking
I'll pm you about it, because I'm newb to ti-calc.org (and am not entirely sure how to take links from there)
-
Spacky Emprise is now available for download in the Omnimaga downloads section. The levels are now half the size that they were, 12000 bytes total instead of 24000, but other than that, it’s exactly the same as before.
-
By the way this was pretty nice, although pretty hard with the enemies falling. I will check out the 2nd game soon. *hopes it has better jumping physics :P*
-
Unfortunately, if it's better jumping physics you're looking for, you won't find it in Spacky 2, but you will probably be interested in my next platform game, Fantastic Sam (working title, subject to change)
-
Aaah ok. By the way I'm kinda fine if jumping physics aren't complex, although it would be fun since it would be closer to mario style than Ys III style :P