Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: aeTIos on August 14, 2013, 04:39:16 am
-
Okay, so it's about time that I make a new calculator game. this time, I'm trying to create motherload. Yes, that game you played for hours on miniclip is now coming to a calculator near you.
So, I have calculated that a 140(w)x280(depth) map will take up almost 20000 bytes. Is that okay with you, or is that too much? Please vote so I can know. Thanks :D
-
Nice project. I don't know how much is available on the calc, but I think it sounds reasonable since the game definitely needs an aspect of exploration. Then again I don't know available space, so maybe a bit smaller say 100 x 200.
Nontheless good luck.
-
Maybe you could find some source code or tiles here (http://ourl.ca/7121) that you could re-use, but I don't know how you would ask the permission.
Anyways, nice project idea. How many tiles are there in the game ? I guess you already use nibbles but if there are less than 4 tiles (which I doubt a bit), you can use two-bits per tile and divide the size of the map by two again.
Also, you could do like I do in TinyCraft: let the user choose the size of the map so people with a regular 83+ can choose a small one and people with a 84+SE can choose a large one (so I voted for "other").
-
There are 12 tiles in the game. And yeah I think I might reduce the map size to say 70x140 and let the user choose the depth (in multiples of 140)
-
It would be awesome.
suggestion for the map data: put it in an appvar.
-
Of course I will put the map data in an appvar, the map will be
randomly procedurally generated (from a random value
-
And yeah I think I might reduce the map size to say 70x140 and let the user choose the depth (in multiples of 140)
Why does it have to be multiples of 140 ?? I could have understood a fixed value for the width, but the depth can be anything, can't it ?
-
well, yeah you are of course right. It could technically be anything, but... yeah I actually dunno, it just feels better to me, and I think it makes the random map generator easier to code.
-
If you want to make it generate levels, can't you generate them at runtime and only save the things that change during gameplay (like positions of enemies)? I wouldn't mind having loading areas when you move to an other part of the map.
-
Mnh... If the pseudo random generator gets his seed changed ingame, it could add some abrupt changes...
-
You can save the seed in the save file.
-
Would it be possible to have "chunks" of the map that load on the fly, so you'll always have 3 chunks - 1 above and one below, and when you move into the upper or lower chunks it archives the furthest chunk and unarchives (or creates) a new chunk. The chunk need only be as big as the screen, and since it's not all created at once, it's also easier on memory and checks for whether or not the memory is being filled up. This was the approach I took a while back when I was trying to create a randomly generated scrolling terrain, and it seemed to work out okay (aside from thrashing the archive :P)
-
GLHF to avoif Garbage Collection. Is GC possible without the TI-OS menu? I'd see a loading screen with GC ibcluded
-
Responding to the poll, 20 KB of map data is acceptable to me, as long as they're not overly repetitive or something.
Good luck for this project by the way!
GLHF to avoif Garbage Collection. Is GC possible without the TI-OS menu? I'd see a loading screen with GC ibcluded
I think Doors CS does (or did) it.
-
I think the best solution would be to do something like the following. First you will need some sort of deterministic random number generator (not axe's). By using a random seed as a map key, combined with using the coordinated of a tile as a secondary seed, you would be able to generate the entire map from a single seed key. More importantly, you could generate any tile in constant time, independent of any other tiles, and would not be restricted to having only 16 possible tile values. Then it is only necessary to store a single bit of information for each tile, whether or not it has been dug or not. With a map 128x256 you would only need 4096 bytes to store the entire state (plus the map key). This is small enough that you could easily store it in an appvar. When scrolling, you (assuming 8x8 tile size) can only see a maximum of 117 tiles at once, which is plenty small to fit into a small RAM area. This 13x9 map area would be constantly updated as the screen scrolls by generating the new tiles using the map key and tile position as seed, and then setting the tile state to filled or dug based on the bit you read from the appvar.
-
Oh I always loved playing Motherload all those years ago.
20kb for maps could be too much, it depends on whether you have enough space for the other functions of the game (moving, digging etc)
Also on a side note, Super Motherload has been in development in the last few years.
http://supermotherload.com/
Good luck with this! It'll be a great project!
-
I should suggest RLE encoding for storing maps. It's quite easy, but if your level looks like swiss cheese, you'll risk space loss. You could calculate how much a compressed and a non-compressed map take place, and take the lightest one.
-
I don't think size is a big deal honestly. On another note, nice to see you still lurking builderboy. :D You should try to post a bit moar, if you have time that is. ;)
-
I should suggest RLE encoding for storing maps. It's quite easy, but if your level looks like swiss cheese, you'll risk space loss. You could calculate how much a compressed and a non-compressed map take place, and take the lightest one.
With the method deeph and chickendude taught me, you don't risk any loss. The problem is that it uses one bit per tile, and if aeTIos uses nibbles and has 12 tiles, it can't apply. So aeTIos, what are the tiles you need ? Maybe you could split them in two parts, above_surface/under_ground and so we could still apply that compression (assuming there are less than 7 above_surface tiles and less than 7 under_ground tiles).
I don't think size is a big deal honestly.
On a regular 83+ it is. Not only it is hard to fit "big" things in it, but it is also annoying to get "Garbage Collect ?" everytime you quit a single game.
-
I think I'm going with builderboys method. Now I only need to write a map algorithm.
Also Hayleia I will be using separate maps for above and underground.
-
Also Hayleia I will be using separate maps for above and underground.
Ah, well then maybe you could use the deeph-chickendude method for RLE compression.
Basically, when you have more than one tile, you do that: number_of_tiles,type_of_tile
And when you have one tile, you do that: type_of_tile_with_first_bit_set_at_one
This way, you don't waste space when you have a single tile and you save space when you have more than one.
-
And when you have one tile, you do that: type_of_tile_with_first_bit_set_at_one
This way, you don't waste space when you have a single tile and you save space when you have more than one.
I just wanted to point out that you do indeed waste space when you have a single tile. You waste exactly 1 bit of space :P That may not seem like a lot, but it can add up depending on your data, you can't every get compression for free.
-
What about instead of storing the ores themselves in the map data, simply storing a 1-bit dirt or no dirt map? Then, you have a function that determines what's there based on a formula. (row * column * seed value, truncated to 256, where 0x10, 0x20, 0x30, 0x40 etc. are ores, and everything else is dirt, for example)
in other words, the map never changes, but you don't need to store 16 tiles for 14 ores, air, dirt.
-
What about instead of storing the ores themselves in the map data, simply storing a 1-bit dirt or no dirt map? Then, you have a function that determines what's there based on a formula. (row * column * seed value, truncated to 256, where 0x10, 0x20, 0x30, 0x40 etc. are ores, and everything else is dirt, for example)
in other words, the map never changes, but you don't need to store 16 tiles for 14 ores, air, dirt.
I believe this is quite similar to the method Builderboy suggested. The method sounds like a good way to go.
-
It's similar to the method Pitfall for the Atari 2600 used. End result in that case: 56 bytes for a 256-byte map.
-
It kinda reminds me one of my early Axe game, where to generate the falling lobsters pattern, all I did was reading through the RAM. :P. By the way, for Pitall, is there any doc available online that explains how maps are generated?
-
This video is a little scant on the details, but it gives a vague idea on lots of stuff relating to it.
This blog post goes into detail on how the polynomial counter works, including the atari assembly.
http://www.samiam.org/blog/20130606.html