Binary Grid!

Hey guys, this is my first project here at Cemetech. It's called Binary Grid, based off of the app of the same name for Android. Basically the idea of the game is to switch each section of the grid from 1 to 0 so the binary string is the same as the decimal number on the outside.

I've been working on this project on and off for a bit and it is already mostly done, I mainly just need to optimize as it is a little slower than I would like. One unique thing about this game is it will work on any TI-83+ or 84+ calculator, including color screens, since it uses the home screen.

Unfortunately I do not have any screenshots or gifs of gameplay yet, but I should be able to post them soon.

Anyways, feel free to post questions or suggestions below.

This sounds really interesting for a first project, can't wait to see how it will turn out!

You say you are using the homescreen which I think is really cool. I personally really like homescreen games (not sure why, probably just because of how fantastic the large font is on the color calcs).

It'll be interesting to see how you do/are doing a selector for indicating which square is selected. I know how I'd do it I'd use a "v" at the top of the screen and a ">" on the side and where they intersect is the selected square, or flash the number every few frames but there are so many cool options available!

Since it only has a 3x3 game mode (for now at least), it uses the numpad to switch the corresponding cell between 1 and 0. In the future when larger boards are added I will just use the area around the numpad in a similar fashion.

Also yeah, some of my favorite calculator games use the home screen, it's also obviously a great way to make a program cross-calc.

So, it's been three months, and I finally remembered about this project! I did a bunch of optimization yesterday, and I got the speed up so it is actually fairly responsive. This is probably the most optimized program I have ever made, but I am definitely willing to hear any suggestions anyone has for more optimization.
Here's the code:

Code:

(Edited to include _iPhoenix_’s changes)
Edit: removed variable L, not sure why I even used it in the first place. Comments have been added.
Also, anyone who has a color calculator or regular 83 can try this out to make sure it will work (I'm pretty sure it will).
I'll probably upload it to the archives soon if no suggestions are made.

Code:


Untested, but I did some minor optimizations that should be safe. If nobody else takes up the "job", I'll take the time to go further.

Looks pretty awesome, I'll actually dust off my CE and try it out.

Also, you should import your code into SC3. It formats things and is generally pretty awesome.

Thanks, I have used SC3 before but for this project I went with TokenIDE. I like it because I love using keyboard shortcuts for building and it is able to save a .txt file (useful for comments). SC3 is pretty great, though.

Alright, I've uploaded to the archives. I did manage to squeeze a few more bytes out of the game; the only noticeable difference is the lack of "Creating random puzzle" at the beginning as it wasn't really necessary.

You can download the game here.

As a reminder, this game is compatible with any TI calculator with an 83 or 84 in its name .

Very nice, it was a lot of fun to play.

I thought I could optimize it, so I wiped the dust off my CE (haven't written any proper TI-BASIC in just over a year), reverse-engineered your program (I figured I might as well rewrite it from scratch- I wrote this without seeing your source, just the screenshot and the readme) and the result was this, 273 bytes.


Code:


You were very, very close! I only really made two major changes, and the rest was just going around optimizing away some bytes here and there.

The first thing I did was that I only use one list. By using one list, I can write code once and use it multiple times, instead of having to rewrite my code for each list. This keeps my code DRY and was the main source of size reduction.

The second thing I did was reverse how you are creating the board. Since I'm using only one list, I can use the optional third parameter of the randInt(<lower>, <upper>, [<amount>] command and generate my grid all at once. Generating the "hints" first, then taking those hints and creating the board is the obvious strategy, but it's much easier to generate the board and then create the hints.

If you have any questions on what any line does or why I did something the way I did, let me know!

Wow, this is really good! I knew there had to be a way to make the beginning part less redundant, but I never would have come up with this.

Also, for some reason I forgot/didn't know about the optional third argument for randInt( .

Anyways, thanks for optimizing; I learned a lot from this!

Now that you're done, are you planning on adding new modes (4x4, 3x4, custom selection of size, etc.)?

I actually wasn't planning on it originally, but with the updated code more modes are certainly more possible, so if you are interested I definitely could try.

I definitely would, because I downloaded the original, and enjoy it very much. After a while though, it becomes very easy. I don't know how you would do the menus though, so it could be a challenge.

PS One time I ran the program, it generated all of the 'goals' as 0. I just clicked a square twice and won. Don't know if you want to have an if statement checking for that so there is always a game.

So, I've been experimenting with larger grid sizes, and the question I have for people is which one of these would you prefer:





The images are mock-ups of what the maximum sized grid would be, and I'm not entirely sure which one I should use. In my opinion the second looks less cramped, but I just want to hear what other people think.

Also, thanks bdoggamer for bringing to my attention the all zeroes bug, that can easily be fixed.

I definitely agree, the second one looks way less cramped and thus better, in my opinion.

PS-In your screenshots, you have a grid with 6 width and 5 length. This is fine, but they both display 31. Wouldn't the width side maximum be 63? You might have just used it as a place holder, just checking.

Yes, it was just a placeholder, but as it turns out I will have to make the limit 5x5 anyways, due to the calculator only having 5 columns of keys. I must have overlooked this .

An updated version with 5x5 grid support should be released later today next week .

(Getting the controls to work could take some time)

Well, it's been more than a week, but I've finally finished version 1.2 of Binary Grid.

New features include _iPhoenix_'s optimizations, 4x4 and 5x5 puzzles, and a check to make sure the puzzle is not all zeroes at the beginning. I've also updated the readme with information on controls for larger boards and some notes.

Edit: Download the new version from the archives here.

thanks for the post!