Omnimaga
Calculator Community => TI Calculators => TI-BASIC => Topic started by: {AP} on November 04, 2008, 06:24:17 pm
-
Alright, here I hope to discuss some ideas on the game and get a little help.
Currently, I'm mostly curious of two things.
One, is there a way to hide archived programs from the program list?
I don't think anyone wants to see several programs with stars beside them in their list.
I use so many because these calculators lack a function and I'll save a LOT of space this way.
Right now, I just have the main system, battle system, and shop system in separate programs.
Next one being worked on is either a world map system or random dungeon system. (I'll bring this up again later)
Next is character data storage.
Currently, I'm using lists... and well... I'm wondering if there's a way that takes up less space.
Especially with 6 save slots.
There's also the fact that people can EASILY cheat that way... but I see no alternative.
Any feedback is welcome.
I need some help here. =P
-
It is possible to hide programs through the use of ASM, but IMHO it's not necessary. Most people won't care about such a thing. Also, I'm not sure but in order to acess a hidden program I *think* you would have to un-hide it and then re-hide it when you are finished using it.
-
Ew... that doesn't sound fun.
Oh well, I guess people will have to deal then.
It looks like there will only be about 5 programs in all anyway. (after checking things out again)
-
For large BASIC programs 5 is NOTHING anyway. ;) Just ask DJOmnimaga or Tifreak. Metroid and some of the other large BASIC programs have had like over 9000 subprograms. O_o
-
Well, they're currently: 5k, 4k, 2.5k
In space. The other 2 are undetermined... but they'll probably be bigger due to the massive use of matrices. (lots of maps)
Maybe I'm worrying too much... I use xLIB so I always only have one or two programs in RAM at a time.
-
As a shameless plug...
While trying to *run* a hidden program won't go over very well, you can use Celtic III to access hidden programs. For an earlier post, you can also paste in list data as a string using another one of Celtic III's functions. The destination can be an appvar, so it won't be as easy to hack it. You can also explore Celtic III's ability to convert matrices into strings that you can use to write back into a program that could recreate it.
-
Hm... Celtic III doesn't interfere with xLIB at all, does it?
I doubt I can use the hidden program thing, but the list -> string -> appvar thing sounds really useful.
Don't understand the matrices part exactly though...
-
Interfere? Heck no. That's not the purpose. Celtic III is a stand-in replacement for xLIB with a load of extra functionality. Doesn't fully work quite yet, but if your needs aren't too demanding ( DJ's games don't qualify), it'll work out just great without any modification to the syntax.
Another plus is that Celtic III comes with an autoinstalling program in case you don't want to leave the installation of the lib up to the user. More information and documentation can be found here : http://www.unitedti.org/index.php?showforum=62 . You'll be looking at "Progress..." for the most recent binaries. Also be sure to read through the topic, as it indicates known problems. If you experience problems, feel free to contribute.
Edit:
As far as list to string goes, the same can be accomplished with a matrix. If you store the resulting matrix to a program file, it'll likely take up less memory than having the matrix as a matrix in memory. Sure, it's not immediately usable, but it'll help save space.
But... if you choose to use Celtic III as the main lib, you'll also be able to use string tilemaps, where you can absolutely do away with the entire matrix idea. But... you'd want to ask a very experienced BASIC programmer if you want a halfway-decent explanation on how that works.
-
I can't be sure, but from the looks of it I wouldn't have to reprogram anything by using Celtic III.
If so, then as soon as it's finished up a bit more, I don't see any reason to not use it.
Also, I know how string tilemaps work... just no idea how they'd work with sprites. =P
_____________________________________________________________________________
With all of that covered... I'm on to needing a bit of help on one issue.
I can't decide wether I have it kind of Diablo-esque with one town and a randomly generated dungeon thing going on... or to try making a world map of sorts.
This would probably go along better with a story... the problem is... a full RPG story would take up WAY too much space.
Not to mention that with the state of my system, it'd be hard to manage.
Yet, I'm still going to add quests in.
Most likely in a randomly generated format.
...You know, I think this game is run, like, 75% on random generation when it comes down to it.
That could have something to do with a story of some sort.
The random creatures and even that random name it's got.
Well, what do you guys think? I'm listening. =D
-
If it's true that 75% of the game is basically randomized, I'm pretty sure that it would be suffice to say that random maps would also be sufficient, but if you really want it "Diablo-esque", you're going to want to save the maps that are generated, which could take up more space. A potential solution to that problem is to generate a map that is based upon a single seed. I say a single seed because "random" isn't really random if you seed the random number generator with a known value. In fact, all the numbers after the seed are the same if you happen to reseed rand with the same number. You can possibly get this seed by various means, including your stats and how many cycles it took for the player to push a key. Store this number (seed) into a list so that upon regenerating the map, you can look up that list for the seed that was used to generate it.
A good approach is to define a list used specifically for maps, and a variable to determine which map you are in. If you go to the next map and the variable's value exceeds that of the list dimensions, expand the list by one and add in a randomly selected number to be used as the seed. After that, go into some generic routine that picks that list element back up and loads it into rand for your random generator.
...
If you know all of this already, then... darn. I must sound like some sort of elitist or something. (sorry!)
Still. I can't ignore a possibility that an entire map can be stored in a single list element (9 bytes). Just make sure there's enough variation depending on the map level to ensure that none of the maps really do look alike, even with the same seed. You could be using your map level variable to make the determinations.
-
I get what you're saying.
I was thinking of something close to that.
My main problem is thinking of a way to have it randomly generate the matrix which defines the map.
I was thinking of a room style where I have a set of rooms that that are randomly picked then put them together into the matrix.
...
Okay, ignore most of what was said above.
You're some kind of genius, but I didn't read correctly the first time around.
This kind of goes with my room styled idea, except that with your method it's a series of maps that make the dungeon rather than one huge map.
Oh, the possibilities!
I'll have to change a lot of code to get it to properly change through randomly generated maps.
Though... then again... as I type, more ideas are flying through my head.
I'm pretty sure I have this figured out too now.
Thanks much, Iambian! You got my brain going!
-
No problem.
But now that I think about the whole scheme, I'm now interested in how fast you can regenerate a map from a single seed, since I'm pretty sure that constructing a sensible map from a random number must take quite a bit of work. For generating an actual dungeon from a random number, I've got very little idea as to how about doing it, and the only way that I can possibly think about doing it would take some serious processing time.
I hope to see what you can come up with. Exceed all expectations and create a truly great game! (Hmm... Diablo for the graphing calculator...)
You still may need a separate list linked to each "randomly"-generated dungeon to define the events that have happened in it. For example, which treasure chests have been taken and which ones are still there for grabs. Which quests have been completed in that level and which ones still remain to be done. You know, stuff like that.
EDIT: btw, the idea for the random number seed came from a much earlier project when Weregoose asked me to retrieve a listing of a couple hundred thousand results in an attempt to create some sort of weird compression routine that used the randomness found in the random number generator. I though it might be useful to somebody someday, even if in a different incarnation.
-
Interesting ideas, if you have random dungeons I would really recommend that it chooses from a set of premade matrices/rooms, because generating dungeons areas tile by tile would be quite slow I think, especially since it would need to make sure rooms are linked and that it's possible to pass through the room
personally i dont care much about seeing multiple programs in the list because I usually have everything I don't use grouped and if I got another huge game I delete it (except save files) before installing another huge one then reinstall it later if I want to play again. But one thing, if you have a 84+ I would advise against using the timer/clock functions because then the program will not even work on the older models or if you plan to use them release a version with no clock/timer usage and another version with timer/clock enabled
-
Well, currently... I can't think of a way to implement a seed "number" per se...
My current idea is to have a list for each dungeon.
In the random generation part, it's choose a number that defines the layout of the dungeon (first element of the list) then generates the rooms to be placed in the layout (next approx. 9 elements).
That list will be that character's first floor of the dungeon.
The rooms that will be generated will be set based on a collection of interiors and the walls that contain the doors/pathways will be placed based on the layout.
From a little more on the thought of the layout, here's my examples.
Let's take a (3 room)x(3 room) dungeon.
_ _ _
|_|_|_|
|_|_|_|
|_|_|_|Now, the layout will decide which rooms to use which will leave out about... 2-3 rooms.
Not positive yet.
A possible layout could look like so:
_ _
| | |_
|_ _ |
|_ _|Of course, the possibilities are endless. (due to the rooms that can be taken out and the placement of doors/walkways)
I'll probably only have 10-20 layouts to be randomly picked.
What's in each room will be randomly generated and I'll work on random encounters too. (generation of room contents was explained above)
Assuming anyone understood the above... do you think it's a good idea?
Also, excuse my lame art above, I did it in a rush.
-
Even with random generated dungeons you should have some order to it. Likely you may want to have a specific treasurse (IE a specific weapon or armor) appear in a dungeon. You also want to make sure that If you have locked doors that you have the proper number of keys generated and that they are generated so that the user can get them. It would be no good to have the key to the last door locked within the locked room now would it ? ^_^
-
True, true...
I'll have to figure a good way to code the generator to account for that.
Shouldn't be TOO hard, just a bit of brain power and testing.
__________________________________________________________
Right now, I'm wondering if I should have an ending to the game.
Originally, I was thinking of no level cap and just letting people play on until they get bored.
My main issue with an ending though is where should it be?
Also, after awhile I'm sure dungeon crawling will get a bit tiresome... especially since I have to account for characters levels. I could just set all creatures to the level of the character at the time they meet. If not, I'd have to have a dungeon for each level they get to.
In either case, creating quests and/or bosses wil be a pain with this whole random generation thing too.
Though, I'm just not sure which would be more fun. A fixed world with a fixed plot and a fixed ending.
Or random world, no plot, and no ending.
In either case it'll be battling monster after monster to level up and become more powerful.
Argh... my mind has WAY too many conflicts.
So, what are your thoughts, Omnimagans! (yes, I invented a word for members of Omnimaga)
I'm off to school and will be reading and considering everything posted upon return. =D
-
a neverending game would be cool, providing it's not too repetitive, especially near the end, and that very challenging stuff occurs late in the game.
Of course I am more into fixed storylines and static dungeons, altough it doesn't matter if it's linear or not, because sometimes it's less empty and repetitive in terms of storyline, but random dungeons would make the game more unique since there aren't much randomly generated BASIC games on ticalc.org
-
[...]
Right now, I'm wondering if I should have an ending to the game.
Originally, I was thinking of no level cap and just letting people play on until they get bored.
My main issue with an ending though is where should it be?
Also, after awhile I'm sure dungeon crawling will get a bit tiresome... especially since I have to account for characters levels. I could just set all creatures to the level of the character at the time they meet. If not, I'd have to have a dungeon for each level they get to.
In either case, creating quests and/or bosses wil be a pain with this whole random generation thing too.
Though, I'm just not sure which would be more fun. A fixed world with a fixed plot and a fixed ending.
Or random world, no plot, and no ending.
In either case it'll be battling monster after monster to level up and become more powerful.
Argh... my mind has WAY too many conflicts.
[...]
If you're going to have a dungeon level system similar to that of Diablo, you're going to want to tie in quests and bosses to your map level variable so that they can appear (doesn't matter where, just that they appear before the exit of that particular map) on specific floors in specific areas. Who said things like that should be *completely* randomized? Quests should appear on a very specific floor (or you could do it plus or minus one floor for a sense of randomness) and bosses too. Speaking of the difficulty of the enemies that appear in the dungeons, you could also tie that in with your map variable so that you can allow the player some breathing room.
If you've ever played Lufia II, or some of its sequels/prequels/whatever, most of them feature this "Ancient Cave" thing. The one in the game I mention is completely randomized and goes down 100 floors without anywhere to save and very few places to heal yourself (forget about mana. Only the items you find inside can help you). In this game, there are only stairs leading downward but none going back up, so forward is the only way to go until you reach level 20 to 30 where you'll find "Providence" which will bring you back topside. All acquired items in the dungeon are taken away from you (except blue-chest items) and your experience level is reset to when you first entered the cave (along with items you can't take into the cave). When you go back into the cave, you gotta start with EXP lv 1, on the first floor, with nothing but 10 potions and any blue-chest items you've found.
Of course, the Ancient Cave itself was meant to be the ultimate challenge in the game. You need not make your game as difficult as that. But... if you want players to make 6 hour long runs at a time as they shoot straight to the final floor, you can do just that.
Just make sure that when you reach the final floor, the game says it's the "Final Floor" instead of something like "Floor 100". It gives a sense of deep satisfaction to know you're so close to the end. Also, make sure that the final floor isn't randomized, but is a very specific shape and size. Perhaps that of a long corridor leading into a very large chamber. With candles lined up on the sides!
Well, anyway. Whether or not there's a fixed plot and/or storyline, there can most certainly be a fixed ending. I think it's more fun with a definitive ending.
... or you could also add in my Ancient Cave idea as a bonus for getting the player through the normal game. It'll be a way to throw in some bonus content throughout the whole thing.
-
I think that the game should have an ending... but after the end, you can go on playing until you become a dusty skeleton!
Anyway, I think you should really add battle sprites, cause the battles now are too repetitive.
-
Yeah, I'm working on the graphical battle system next.
The only thing that's slowing me down is my actual ability to draw on a calculator.
But, yeah... there will be a (probably randomized) background, sprite for each class and creature, animation for every attack, and prettier interface.
Needless to say... this will be a HUGE improvement.
Though, I fear that after awhile it will feel repetitive too... but I'll burn that bridge when I come to it.
Also, thanks for the thoughts guys!
Yeah, I'll definitely need a boss.
Actually, I probably make like... a dungeon for every level (most likely ending at 20) and a few mini-bosses and a final boss at the end.
Then, I'll have you unlock an area so you can continue leveling your character.
Oh, and I'll be adding a multiplayer feature!
I'll let you battle friends to see who's stronger. =D
With all this covered... my next issue... is coming up with quests.
-
yay for multiplayer ^^
-
Yeah, I actually made it for the old version awhile back as a stand-in for a lack in content.
Though, it's lost by now and wouldn't be near compatible.
Still, the concept is really simple.
Just a modified version of the battle system is all.
-
You could have a second difficulty level after you beat the game for the first time where all monsters are X levels higher and the loot gets better.
-
I think the multiplayer idea is great!
It'll be the 1st multiplayer RPG game ever made!
-
Multiplayer huh? I didn't think that was really doable in BASIC, except on the same calc... and that's kinda MEH.
-
It's easy... all you need is the Send( and Get( functions.
It'll be a little slow (I think), but I've done it before.
-
mhmm actually Get( is for CBL/CBR, it doesn't work well from calc to calc, you must do Getcalc( instead. Also the other calc must be paused for it to work else the var won't be received at all. To be able to get/send variables when the calc is busy fine you must use an asm library called ZCOM on ticalc.org. A lil slow but I think for a RPG it could be bearable if there isn't way too much data to send every loop
-
um.. if you make this dont make a million subprograms like in some other ones on this site, they are so hard to keep track of which goes where because there a like a hundred that are just a letter with two numbers after it.
-
Don't worry about sub programs.
I'm using as few as possible and if you install the game correctly you won't even be able to see anything but the main program.
I never liked the 'hundreds of subprograms' thing myself.
-
thank you. i am for ever in your debt. i am obliged to play this game when completed. if i didnt then i would at least have to buy all of your comics and frame them. thank you.
-
{AP} here's your chance make some comics and sell them for insanely high prices.
-
While many subprograms can be annoying, you have to realize that the person who said "good things come in small packages" didn't have just 20kB of RAM to work with.
-
actually stop dissing games with multiple sub programs guys. Authors put a lot of work into them because they are some of the most complete games around for TI calculators (even more than some ASM games) and they had to be split into that many files to fit in RAM. Today, Celtic III solves this issue, though, since it lets you load only certain specific lines of code from a program in particular, meaning you can put every single sub routine in one program, but a lot of the games in Omnimaga download section were coded years before Celtic III came out and on top of that, back in the days most BASIC optimizing tricks were not discovered yet.
-
Not saying there's anything wrong with them.
It's just that it IS an inconvenience to have to mess with that many subprograms.
I do respect all the work put into them and have never dissed the games themselves, just that feature.
Face it, no game is perfect, but if the only problem is that it's a minor inconvenience to have so many programs on your list then it's damn near close to perfect.
In my case, I was just letting Skuller know that my game wasn't going to have too many and that the ones I do have will be hidden.
______________
And, yes, I know you were talking to me too, because you said 'guys' and the only ones to bring it up are skuller and I.
-
ah ok I was a bit worried at first x.x , because there are many people who used to judge my games as well as Contra 83, FFTOM and some other BASIC RPGs solely based on the amount of subprograms or the total file size. They even said that they would never play the games simply because of that, plus someone even complained once because the games used pictures and it overwrote theirs x.x
This is partly why I requested the deletion of my entire ticalc.org profile one year ago, because I felt that they weren't worthy anymore to be on ticalc if nearly everyone prefered shorter but smaller games
-
Hiding your programs/appvars would be a smart idea, and having the program fast (as needed) is the number one priority for me.
-
is there a way to do that in basic?
-
Necro Post... er... Necropost I mean. WAIT! Necro Post, yeah I was right... oh NOT! it's Both lol. :P
I don't think there's a way to do that in BASIC. I wonder if Celtic III can do so, though. That said, even if it,s impossible, just convering the programs into APPVARS might solve the cluttered program menu issue.
-
To feed the necropost, Celtic III *does* have the ability to hide programs and appvars and will still read from them as though they weren't hidden. Don't try to actually run one of those kinds of programs, though.
And there are known issues revolving around archiving a "hidden" program. Supposed to cause, like, major memory meltdown or something.
-
To feed the necropost, Celtic III *does* have the ability to hide programs and appvars and will still read from them as though they weren't hidden. Don't try to actually run one of those kinds of programs, though.
And there are known issues revolving around archiving a "hidden" program. Supposed to cause, like, major memory meltdown or something.
IIRC, the problem is with hiding an archived program, not archiving a hidden program (if you know what I mean). That is, the name in the backup VAT entry in the archive needs to match up with the one in the entry in RAM.