Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: adrusi on June 04, 2013, 08:54:12 pm
-
I'm planning on making a roguelike heavily inspired by The Binding Of Isaac.
There's going to be a lot fewer items, which will be mostly limited to stat upgrades. There will also be a lot fewer enemies, bosses, etc. There just isn't enough memory, and even if there were I'm not willing to implement anywhere near as many as the original game has.
I think I have a decent scheme for representing the map, where I can store each room in only 2 bytes. However, I'm not quite sure how to approach generating the map in a way that resembles the labyrinthine nature of the original game. Any suggestions?
Here's a picture of the interface as it currently stands.
Edit: This is for the z80 series calcs.
-
Maybe you could have preset rooms, but selected via a random number...
So, if you have 13 room layouts, then each room could be assigned to a number? Not sure what calculator you're programming it for though.
Also, have a number stored to memory, and after, say, 3 rooms or so, it would put the entry to the next level in a room that you have not entered.
That eliminates the fact that you could just go into 1 room and find the way to the next level. Still though, not sure what calc your using.
-
Maybe you could have preset rooms, but selected via a random number...
So, if you have 13 room layouts, then each room could be assigned to a number? Not sure what calculator you're programming it for though.
Also, have a number stored to memory, and after, say, 3 rooms or so, it would put the entry to the next level in a room that you have not entered.
That eliminates the fact that you could just go into 1 room and find the way to the next level. Still though, not sure what calc your using.
Yeah, it will have 16 or 32 room presets, just like the original game has preset room configurations, but what I'm concerned about is arranging the rooms on the map of the floor.
Every room has to be reachable, each floor has to have certain types of special rooms (item room, boss room, shop, maybe secret room). Some rooms also need to be placed specially on the map. The boss and item room have to share exactly one side with another room, secret rooms (if I implement them) can't block the way to the rest of the floor (there has to be a way to get from one side of the floor to the next without breaking into a secret room).
-
Still haven't told me what platform...
All I can think of is to generate an x by y map, where x and y are how many rooms wide and high the map will be, and instead of pre-set rooms, have it detect if a room is beside it, then it can place a door there. Then, if the room has no rooms beside it, it removes itself!
-
I'm not familiar with that game, but your mockup looks quite nice. ^^
-
Still haven't told me what platform...
Edit: This is for the z80 series calcs.
:P
Somebody should move the thread.
-
:o I'd looove to play the Binding of Isaac on-calc :D good luck with it, hope you'll finish it.
-
I love the interface so far. It reminds me a TI-86 RPG I played once. I forgot if it was Banchor the Hellspawn, although it wasn't rogue-like.
Good luck!
-
The Binding of Isaac is a game with an incredible amount of complexity; you should probably figure out each and every detail before you actually start working on the project. As for your mockups, you might do with making the hearts smaller, but it looks fine to me.
-
^agreed on the hearts. if you could find some way to squeeze health into the sidebar instead of taking up a whole section like that, it would be helpful.
as for room placement, just lay out all the normal rooms first, placing each room at random on another, with greater weight given to rooms with fewer connections, and then place the boss, item, and secret rooms afterwards at randomly chosen places that work. you can always do checks to prevent there being too many crossroads etc as well, if you want.
-
Still haven't told me what platform...
Edit: This is for the z80 series calcs.
:P
Somebody should move the thread.
It could still be more specific, as there are quite a few z80 calcs that are all a bit different. I'd assume its for the 83+/84+ series. Anyhow, moving topic regardless. :)
-
The Binding of Isaac is a game with an incredible amount of complexity; you should probably figure out each and every detail before you actually start working on the project. As for your mockups, you might do with making the hearts smaller, but it looks fine to me.
I'm thinking of writing it in C on computer first where it's a lot easier to make changes, then porting it to axe.
As for the hearts, I'm a bit concerned that the playing area is too small. I initially wasn't showing the coin, bomb and key counts, figuring that I'd display them when some key is pressed.
I ended up opting to reduce the size vertically too for the sake of odd-numbered sides. Otherwise it's harder to center the doors and make interesting room designs. If anyone has any other suggestions, it'd be great to have a better solution.
-
I'm thinking of writing it in C on computer first where it's a lot easier to make changes, then porting it to axe.
Lolwut ? This prolly isn't a good idea because Axe is way different than C.
-
I'm thinking of writing it in C on computer first where it's a lot easier to make changes, then porting it to axe.
Lolwut ? This prolly isn't a good idea because Axe is way different than C.
Axe is missing a lot of higher-level features that C has, like types and structures, but the low-level features of C and Axe like program flow, arithmetic, and memory access make them quite similar. C is probably the most similar major programming language to Axe.
If you want to write something in C and later port it to Axe, just be careful not to rely too heavily on features that Axe doesn't support or that you can't easily enough mimic with your own code.
-
The only rogue-like game i've played is Chambers (http://www.ticalc.org/archives/files/fileinfo/452/45229.html), also written in Axe for the 84+. It sounds like you want to make something a bit more complicated, but Chambers is fun (though really hard) and perhaps worth checking out if you haven't seen it yet.
-
I'm thinking of writing it in C on computer first where it's a lot easier to make changes, then porting it to axe.
Lolwut ? This prolly isn't a good idea because Axe is way different than C.
Axe is missing a lot of higher-level features that C has, like types and structures, but the low-level features of C and Axe like program flow, arithmetic, and memory access make them quite similar. C is probably the most similar major programming language to Axe.
If you want to write something in C and later port it to Axe, just be careful not to rely too heavily on features that Axe doesn't support or that you can't easily enough mimic with your own code.
right, I'm thinking in axe, but writing in C. I'm not using stuff like malloc which don't exist in axe. It's all fixed length arrays and such. C just helps keep it organized, so I don't have to think about name conflicts at the same time as I think about algorithms and such (and I can see more of the code at once).
I'm hosting the code on github in case anyone's interested. I'm trying to simulate the environment on calc as realistically as practical without using an emulator or something. Maybe some of the functions I write will be handy for others approaching an axe or asm project similarly. https://github.com/adrusi/Isaac (https://github.com/adrusi/Isaac)
-
In Axe you have getCalc which is equivalent to malloc.
-
In Axe you have getCalc which is equivalent to malloc.
but you can't use getCalc without providing a name for an OS var, right? That's not really practical for anything other than global arrays, and besides, it's best to avoid dynamic memory allocation if possible, I'm sure it's quite expensive on the calculators.
-
That is looking awesome, good luck with it! :D
-
In Axe you have getCalc which is equivalent to malloc.
but you can't use getCalc without providing a name for an OS var, right? That's not really practical for anything other than global arrays, and besides, it's best to avoid dynamic memory allocation if possible, I'm sure it's quite expensive on the calculators.
It's must unless you use extra ram pages. A lot of Axe program use it due to too few space in safe ram (and its non contiguous nature).
-
Using an appvar (or any other variable but appvars are best since you can name them as you want and have them the size you want) is not really processor demanding. And you only need to provide its name once in the program since then it is repered by a pointer and no longer by its name (except if you lost that pointer and need to find it back). Here (http://ourl.ca/8294/152571) is an excellent tutorial about appvars (and external vars in general). Also, as StreetWalker said, when you need a lot of RAM, you don't really have the choice, you have to use those if you don't want you array to be in parts.
-
Yeah for example tilemaps and sprite data use a lot of ram.
-
Using an appvar (or any other variable but appvars are best since you can name them as you want and have them the size you want) is not really processor demanding. And you only need to provide its name once in the program since then it is repered by a pointer and no longer by its name (except if you lost that pointer and need to find it back). Here (http://ourl.ca/8294/152571) is an excellent tutorial about appvars (and external vars in general). Also, as StreetWalker said, when you need a lot of RAM, you don't really have the choice, you have to use those if you don't want you array to be in parts.
what I mean is that you can't really use GetCalc as malloc in situations like these:
entity **collision(entity e) {
entity **es = malloc(sizeof(entity *) * 16);
int cursor = 0;
for (int i = 0; i < num_entities; i++)
if (collision_exists(entities[i], e)) {
es[cursor++] = &entities[i];
}
return es;
}
Which is the primary use of malloc in modern C.
GetCalc is mainly used if you need persistant data (I don't), or if you need more ram than you can get away with statically allocating with Buff (I do).
I suppose it's possible to use a hack and dynamically generate names for appvars, store the name somewhere in the pointed memory block, and free it with DelVar using that name, but that's inefficient and unrealistic.
This is an off-topic discussion, and I feel like this isn't really the place for it.
-
Oh right. Buff is not really recommended though because it makes your executable bigger and triggers writeback with shells.
-
If you write it in C on the computer, will you try to update the Axe version simultaneously too so we don't have to wait until the C version is completed before the calc version even starts being worked on? :P
Else, another idea could be to use SDCC (like AHelper is doing for his TI-84+ OS on Cemetech) so you can write the calc version in C as well. I heard that calc C is a bit slower, but nobody really ever tried making the same program in both calc languages to compare afterward.
-
Or you could use token ide and an emulator. :) That way you'll get the convenience of coding on a computer while doing it for a calc.
-
If you write it in C on the computer, will you try to update the Axe version simultaneously too so we don't have to wait until the C version is completed before the calc version even starts being worked on? :P
Else, another idea could be to use SDCC (like AHelper is doing for his TI-84+ OS on Cemetech) so you can write the calc version in C as well. I heard that calc C is a bit slower, but nobody really ever tried making the same program in both calc languages to compare afterward.
I like that idea. I also like GlassOS, and I want to see it be successful. I'm considering developing isaac for GlassOS, to support it, even though that would mean a much smaller player base. If anyone sane is going to decide to switch to it, it's going to need to need some seed programs.
However from what I've heard, the linking tool isn't building right now, or at least something is broken. I'll get in contact with ahelper to see if there's some work around or if I can help fix it.
Sorry if this disappoints anyone wanting to see this project on AOS, but I think this is the direction I'll take the project.
-
I *think* Ahelper was saying there might be a way to get SDCC to output code that was compatible with TI-OS (is this what you mean by AOS?). I think if you release this as a GlassOS exclusive, your audience will be next to zero. IIRC, it can't be dual booted with TI-OS, and as far as I know, it is pretty far from a release. Nothing against GlassOS, but if anything, I'd suggest a dual release.
-
I *think* Ahelper was saying there might be a way to get SDCC to output code that was compatible with TI-OS (is this what you mean by AOS?). I think if you release this as a GlassOS exclusive, your audience will be next to zero. IIRC, it can't be dual booted with TI-OS, and as far as I know, it is pretty far from a release. Nothing against GlassOS, but if anything, I'd suggest a dual release.
Yeah, I know. I'm fine with no audience. However, you bring up a good point with the dual release. with a bit of conditional compilation and a separate rel file, it should be possible to compile it for multiple targets.
-
Herocore is has a very similar engine to binding of isaac. I am working on this game, so if you need some source code: just ask.
-
Yeah the issue is GlassOS will only be really successful towards people who are either:
1) Out of school and no longer planning to re-use the TI-OS features
2) Use an emulator
or 3) Own at least two 8x calcs (one with TI-OS and the other GlassOS)
It will have success but then you would have a signifiantly smaller audience. You could possibly make two version, one which has more features for GlassOS and a limited version for TI-OS.
-
yeah, what I've been working on on and off for the past couple of days is getting code to compile for multiple targets: the standard ti provided OS, GlassOS and a simulator for posix systems (for debugging). Hopefully this will allow for a large audience, support glassos, and provide a framework for future developers wanting to take a similar approach.
-
That is good to hear :)