I have still been working on this project. The changes are killing me. I am thinking of reducing the size of this program by a lot, but I just do not know if I want to spend the time. If I do it, I will have to reprogram almost everything. I am currently using lists to store the data so it can be retrieved without accidently deleting it. The problem is that it uses over 3k. I could store to a string and only use about 350, but to recall, the information memory would probably increase slightly, and it could easily be lost with another program. But, I could also use another list that is much smaller, store the string to the list, and then send the info back to the string. This would decrease size by about 2/3rds overall to save data. Should I wait and do this after the beta release? I am sure there are still more changes that I could make. I just want to finish this thing so I can move on, but I do want it to be a quality game and that is why I am taking so long on it. I want it to be good for everyone and I might not end up fixing it if I do not do it now. Maybe I will use this method in part 2 or something.

I took a break from this program to work on introducing TicTacToe1000 V.1.0. The real reason I did this is because of an issue I was having with the OS while trying to allocate all files into one for easier use with DSC7. It will not let me use all the Lbls for some reason. I will attempt this again soon but I need to use less Lbls or something to make it work without corrupting the program. I am very dissappointed with my calculator at the moment.

Basicman, sounds great! You should also show us your source code so you can help you optimize it down.

Well here is a thought, though it might be size consuming, though nice if you manage to delete/overwrite the pics you need on accident. Store the "items" on the screen to a matrix using numbers for each, for example, if you had 2 stores on the top row and an armory on the bottom left (in a small 2x2 size "screen"), you could have something like:

Code:


Also that can be used for other purposes, also, when you select where you are building what, to change that number in the location on the matrix.

I hope this will be helpful.

Very nice, Sonlen! My main addition to your post would be that your Ifs would probably need Then/Ends, and you can optimize out a lot of closing parentheses and brackets.

The closing brackets and parentheses were added because of the syntax colorizer thingymajig. :p

Ah, that makes sense. Well, at basicman then, you can omit a lot of the closing delineation structure.

That is a very nice code Sonlen. Thank you very much. I' ll work with it and see if I can come up with good results. I will post code I have for this project soon.

Excellent, I am sure Sonlen shares my enthusiasm in seeing your code once you make some progress.

I would love to see it as well, in the months I have been messing with TI-BASIC, I would say maps are my favorite thing to do using matrices, nice and easy to use, collision and display are faster then huge strings etc...

Right now I think the code is about 6k. Storing the two screens to the list I am using takes 3k, plus two pics. It takes lot of memory. Maybe I should have stuck with one, but it would not be as fun to play. If it was not for the save feature it could be really small with more gameplay. I just do not know how much gameplay there will be, and if I should be storing the screens. I really need to finish the contents so I can determine how long the fortress will take to defeat.

I think with Doors CS, plenty of archive, and modern 83+/84+ calculators, you don't have to worry too much if your game uses too much RAM. I'd make it have all the features you want first, then worry about optimizing and modularizing it.

I am glad and somewhat sad to hear that. I already deleted a lot of much wanted code. Once I finish the bettle system I will start making decisions about add-ons.
here is some of the code from the existing main program. *note that I am going to try to include all or most of it in one file. I have a good bit of experimenting left.

Code:

Ok, I have been working on getting this program together for upload soon. The code has been altered somewhat for the better I hope. It is smaller than the latest code posted and I fixed some code so it should be more appealing. I need to work on the gameplay a little. This is going to be a good download.

Sweet, can't wait! I removed your code for now, by the way, please feel free to Pastebin or SC2 something that large.

Ok, thank you.

Not a problem, hope I didn't inconvenience you too much. Out of curiosity, what features will the version that is nearly done have?

The game has kept the basic structure throughout all of my trials. What I have now is a strategic battle of two empires or kingdoms.
Buildings, men, and artillary are the same.
I kept the two screen map for individual territories.
You can only place anywhere in your territory but, you can move into enemy territory to conquer the enemy.
I minimized the menus so I am left with only two.
One menu is for stats and the other is for items. I kept the scrolling items menu even though it is big for scrolling and I wanted three. The stats menu has food, water, gold, revenue, kills, and defeats. I kept the list because I felt it was safer and I could just add unarch and arch when closing the program if I want. It takes a minute to load the game initially but the gameplay does not have any long waits. You can continue without loading or you can load if you want to. I wish I would have went with larger sprites because it would have taken less memory and draw time but I am not planning on changing it in this game. You can browse the screen quickly with the cursor to view the items on screen and/or select the item for movement if applicable. You take turns with the enemy marching your men to victory. Turn is based on movements and actions. Any comments are welcome.

This all sounds great! Is there a maximum to how many troops you can have? Or perhaps a limit at which it still runs at a decent speed?

There is no limit but the screen size and recall memory, which is at 330. You could put 150+ troops if you wanted to and if you get enough income coming in. More troops does not affect the speed at all. Thats one reason why I wish I would have went with larger sprites and more screens. Part two, if there was one would have sprites four times the size and more screenplay but I am happy with the program.