Cemetech Contest 23: Stealthy Spies has now concluded. Click
here to see the results!
Original post:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Before a spy can enter active duty, he must be well-trained. At Omicron 34, special agent trainees receive instruction on how to break codes, pick locks, and more.
The game currently consists of four puzzles. The player works each one a certain number of times, gaining points for the ones he solves. If he has enough points at the end, he can go on to the next level which makes each puzzle harder to solve.
I currently have four puzzles that I am working on:
Code Fragments: a Hangman-style puzzle where the player has to complete a phrase within a certain number of tries
Locks: the player has to pick a lock with the aid of a clue
Computer Hacker: where you are searching through computer files to find keywords and passcodes
Time Bomb: You have to diffuse a bomb by flipping switches to isolate the explosive under a time crunch
These are still in early development, so they might change as the contest continues. This will also be my first serious ICE program as well as my first Cemetech contest.
I wish everyone success with their programs!
I love the backstory and the whole training concept - plus there will be some real variety to this entry which is enticing as well.
Progress Update
So far I have been working on the game mechanics and getting a feel for ICE. The mechanics for the Lock Picker, the Phrase Challenge, and the Computer Hacker puzzles are semi-finalized and I'll be getting started on the graphics soon. The Bomb Diffusing puzzle turned out to be a little more complicated than I expected, so following epsilon5's advice I am concentrating on finishing the first three puzzles before returning to it.
I would also like to thank dankcalculatorbro for his very helpful ICE tutorial series.
Sounds really good so far! Got any screenshots to share? Also, thanks for taking my advice, I really appreciate that.
This is the Lock Picker scene. The white box at the top will contain the clue.
Right now it is just a picture, but I am busy getting the mechanics behind it.
And this is the win scene.
It is animated, but for some reason I couldn't get CEmu to export animated PNGs. It takes the recording and exports it as a regular PNG. Does anyone know what I am doing wrong?
EDIT: It's working now. It is smoother than it actually looks on the calculator since the calculator has the screen lag.
Love the designs! How's the actual mechanics coming along?
Currently, it is all on paper. I made the animation and picture on calc, but I am going to switch to SourceCoder so I won't run the risk of corrupting my calculator's memory.
The rules for the Lock Picker puzzle are fairly simple. The goal is to shift each of the pins up or down to find the right combination that opens the lock. The clue gives you the correct combination in code. If you move a pin in the wrong direction, the entire lock resets and you lose points. Each time you solve a lock, a green box is added to the group in the upper left-hand corner, and you are given another clue for a new lock. The faster you solve the puzzle, more points you earn.
The Codebook label in the center of the control panel gives you access to the list of codes you have so far. I am thinking about adding a shop where you can "update" your codebook to get the keys to codes that come later.
Your secondary goal in each puzzle is to earn enough points to unlock the next level which makes each puzzle harder to solve.
Sounds interesting... Do you mean that the clue is written in computer code? I'm not sure if that would work out for people who don't code at all... Or is it something else? Otherwise, the shop idea sounds great! You should totally add it!
Thanks for the feedback!
The code that I'm using to encode the clue is currently classified.
But it isn't computer code.
Progress Update and Help Request
I have made some more progress on the Lock Picking puzzle. The lock now resets when the player makes a wrong move and the attempt box in the upper left updates each time the lock is picked.
I have also created a main menu as well as door animation inspired by the tower defense game, Kingdom Rush.
Right now, I am trying to figure out how to store data like game progress and points as well as the clues that the lock picking puzzle uses and I have several questions. Is there a forum thread or a documentary that deals with appvar reading and writing?
Copied from a response I gave to Argus earlier:
epsilon5 wrote:
Easy: first you need to figure out the size of the string (I think there's a getSize function somewhere in the commands list). Or you could just figure it out yourself- uppercase characters are 1 byte, lowercase characters are 2. In this case, your string would be 5 bytes (I would use getSize for longer strings, or just use, say, 10 bytes, for every word in your appvar).
Creating the appvar and writing in your strings- A is the slot number
Code:
//Not necessary, but useful if you want to manipulate the string in any way.
"HELLO"->Str1
//Close all open slots
CloseAll()
//Create the appvar and store its slot number
Open("APPVAR","w+")->A
Write(Str1,5,1,A
To read it back out-
Code:
CloseAll()
Open("APPVAR","r")->A
Read(Str1,5,1,A
And that's all there is to it!
It really isn't very complicated, as you can probably see. If you need more help (like maybe with Seek( or something), feel free to ask.
And your game is looking incredible so far, keep it up!
Thanks!
What if I wanted to read some data out of an appvar that I didn't know how long it was going to be? For example, if the appvar that contained the lock picking clues looked like this:
Move all pins up/Move all pins down/Move 2nd, 3rd, and 4th pins down/...
How would I tell the Read( command to read only one clue's worth of bytes?
You could include one byte that tells how many clues there are, then read clues that number of times.
Alternatively, you could use a value to represent "that was the last clue."
For example, if you had one byte for each clue and the state of each of the 6 pins in bits 0 through 5, you could use a value greater than or equal to 2^6 to mean that the previous value read was the last clue.
This is similar to how strings are stored, where a value of 0 (a "NULL terminator") means the end of a string.
So, I could write the appvar like this:
16Move all pins up/18Move all pins down/32Move 2nd, 3rd, and 4th pins down/... .../15Move 5th pin up0
where the integer preceeding the clue is how long the clue is and the "0" at the end is the NULL terminator?
Sorry, I wasn't making myself very clear. I was trying to find the length of each of the clues, not how many clues there were. But thanks anyway! Now I know something very useful about bytes that I can use.
Captain Calc wrote:
So, I could write the appvar like this:
16Move all pins up/18Move all pins down/32Move 2nd, 3rd, and 4th pins down/... .../15Move 5th pin up0
where the integer preceeding the clue is how long the clue is and the "0" at the end is the NULL terminator?
Sorry, I wasn't making myself very clear. I was trying to find the length of each of the clues, not how many clues there were. But thanks anyway! Now I know something very useful about bytes that I can use.
That looks about right, as long as those numbers are integers. You could also put the number of clues before the first clue as well. That way, you can eliminate the null 0 terminator, and also be able to say stuff like "clue 1 of x" in the program.
Oh, these are actual text clues. For whatever reason I thought you meant data that are used to generate both the actual puzzle as well as the text printed on screen.
In that case, what you have could work well, or you could have the first byte be the number of clues and then not include a terminating 0 on the end.
Has anyone else had trouble with writing appvars in SourceCoder? I have created an appvar called OmicronS and tried to export it to CEmu to test it. It exports properly with the proper title and file type, but whenever I view the appvars in CEmu, the file name changes to O... (with odd greek letters after the "O").
I am writing it as a TI-83+/TI-84+ BASIC file in SourceCoder. Does anyone know what is going wrong?
SourceCoder can only edit and export basic programs. Anything else is too much for it.
Oh, okay. Thanks.
I also have another question: If you want to read an integer out of an appvar, is it a three-byte value or a one-byte value? I believe the ICE documentation says that it can only handle three-byte integers, but I just wanted to make sure.
You could write your appvar into a binary file, and then convert the binary file to an appvar with
convhex.
Integers are 3 bytes in ICE.