I have been giving some thoughts to the design of this game throughout the day while doing other things, and following things I have thought now.
1. I have now figured out how the story should work out from.. how would i say? mechanic point of view? Idea is that you are going to be doing those robot fights to get some money. That money is needed, so you can buy better radio equipment to hear that voice (remember the first post mentioning about tuning your radio transmitter as parable to prayer). That way there is clear way how the game goes forward. Your goal will be to buy better radio equipment, and naturally those equipment will be much more expensive than rest of the AI chips, so that you need to get to bigger league robot fights to get more money.
2. One of the problems that can come at game is, that neither side wins. Computers AI especially at beginning can be just to stand still, and player on the other hand might not be understanding the AI programming well enough, and it ends in situation where neither robot is able to destroy other, that both get stuck somewhere. I was wondering how to handle this. To have certain amount of turns in each battle or something, and determine winner based upon that, but i was wondering if that would create new kind of problems, say someone is able to figure out a way to make one damage at beginning of battle, and then stay hidden in some corner from computer robots and winning every time. Hence I figured that there will be surrender button that player can push. That way you have to every time actually win, but you can also surrender in case game gets stuck.
3. When losing/surrendering you will get some money too, this makes sure player does not get stuck because he cant afford to buy better/right chips. Of course there is the risk of someone abusing surrender system by starting fight, surrendering, starting fight, surrendering... to get little money fast. Hence I thought there either needs to be slow forced start animation, like robots entering the arena to make it too slow and painful to abuse the system to get little money fast, or, then i just let player do so. I guess i just let the player do it, after all, he is ruining the fun just fot himself if he does that.
4. There will basically be two kinds of levels: A. Destroy other robots, B. Get to some certain location. I was thinking of things like carry items, protect something, survive X turns, but I think I better keep it simple for the Speedgame, so maybe just these two.
5. To keep things simple for the speedgame, levels will contain only two kinds of squares: A. open squares, B. Walls. Basically I would like to have even more types, teleports and stuff, but better keep things simple for the Speedgame, I wont be having much time to spent on this one anyway, so better keep it pretty much to the minimum, and focus on what is important, which in this case is to develop the AI programming as far as possible, since that is the salt of the game.
6. Regarding Tuning, as BurnerKnight Studios suggested to have tuning as its own minigame, I was thinking what would be simple to make and fun enough system, i have come to conclusion at least for now. I will be using this mastermind minigame for the tuning part. It isnt much, but I think it will be fun break from all the fighting, especially since fighting might become bit monotonous because of a lack variety due to keeping it simple. Hence even it is not anything that exciting or creative, it will anyway give a nice break from the usual for the player, and, it should be easy enough to program it in only a little of time.
7. One thing I have been wondering is how to get the player to figure out the necessity to use GO TO as an option instead of for example manually executing each command in a row. For that I have now been thinking of an option, which i might use in some other levels too to force the player to use new systems. For I have been thinking that the first two levels are basically same. They be so that Robot can move only forward, and robot needs to reach a certain spot couple of squares front of him. Now in first level (which i think will be called tutorial actually), player will be clicking several "move forward" commands in a row to reach it. But next level I will introduce the player "GO TO" command, and to prevent him from using the multiple "Move forward" clicks, I will this time prevent him from using more than 3 lines of code. Which means he has to use "10 Move Forward", and "20 Go to 10" to get there.
8. I have also given some thought to the user interface and what it should look like. I think I will be using 50 x 50 squares in game, or left side of screen or somewhere, it will be showing the command lines and will be highlighting always which command is currently being executed. Similarly I have been thinking the programming interface that when you are on edit phase, when you click on one of the lines, it will make empty line between that and the next one, to show it clearly for the player where that next piece of code is going. I have also been thinking that as there are these "IF" condition kind of things, I will be using "On Error" command, which will always be attached to same line as the one going to go to "On Error" situation. Hence for example if you are trying to move forward, and you attach "On Error" to that one, then it means that by default the command tries to go forward, but if it is not able to execute the "go forward" command, then the "On Error" will happen. This is for two reasons: 1. Since game goes in turns, I dont think robot should need to stay still for one turn to figure out theres been an error, but instead, it can already do that on error part. 2. I also think it will be easier for non programmer players to understand how this works this way.