Omnimaga

Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: dinosteven on December 24, 2012, 10:06:45 am

Title: Flow
Post by: dinosteven on December 24, 2012, 10:06:45 am
You might have played Flow, one of the most popular games on Android and idevices.
https://play.google.com/store/apps/details?id=com.bigduckgames.flow
I decided to make a port of it.  :)
Now, there's only 1 level in it now, hard coded. (The first 5x5 level on the Bonus Pack.) I'll make a level editor later and ask for people to help me make levels.
The game is for 5x5, and I used different sprite shapes for lack of color.

I can't make a screenshot now (haven't got tilp working yet). To anyone who has time to download this and compile it with Axe and make a screenshot of it, please do so and post a screenie! Please!
I only included the source, you'll have to compile it with Axe.

EDIT: Of course I forget about controls and additional details. That's just me.
Arrow keys to move around, [2nd] to select something, then you can move its line w/ arrow keys. You can't move outside, into another line, or into the base blocks. [Alpha] to release. You release either above, below, right, or left of the block to complete it. It autocompletes.
Title: Re: Flow
Post by: dinosteven on December 25, 2012, 08:26:02 am
Sorry that this is a double post; anyways, I think I can make 8 byte levels, so a 20 pack should be 160 bytes, plus some for the name - ~200 byte level packs and a ~4000 byte game.
Time to reorganize my code!
Title: Re: Flow
Post by: stevon8ter on December 25, 2012, 08:56:53 am
Wow, that's small enough :p
Now start making it xp
I'll play it when i have time... Atm playing it on ipod xD

Ok much luck and i hope you can create something cool :p
Title: Re: Re: Flow
Post by: TheNlightenedOne on December 25, 2012, 09:12:44 am
That's not too bad of a size, and don't forget that you can always optimize later. I'm sure this'll be awesome!
Title: Re: Flow
Post by: dinosteven on December 25, 2012, 09:27:47 am
Thanks! Does anyone know how to input an appvar name? I'm planning on having that level default and let people load their own level pack. Can I use the input command or do I need some other text input system? (Never used input command)
EDIT:
For my own use:
Red = Pic1 = CDEF
Yellow = Pic2 = GHIJ
Blue = Pic3 = KLMN
Green = Pic4 = OPQR
Title: Re: Flow
Post by: shmibs on December 25, 2012, 12:52:20 pm
you can use input, but it's not really worth it, as it looks a bit awful. i and a few others have made and pasted custom input routines around here somewhere./me goes to look.
basically, though, the idea that the majority use is to clear out 10 bytes at the beginning of some free ram area (L1, etcetera), use the first of those to store the header that says which sort of variable it is (the "pgrm" token, the "appv" token, etcetera), have a constant string somewhere that maps key values pressed directly to letter values (i.e., L has a getkey value of 21, so the 21st element in the string would be the "L" token. then you would have a "getkey->var" line and insert the var'th element of your string into the next empty position in your free ram area).

it's a bit more complicated than that in reality, because the getkey values for letter keys do not start at 0 (the smallest is W, at 11), so you'd have to use var-11 instead of just var to get the proper string position, there are values outside the bounds of the letter key section that you'd have to ignore (numbers smaller than 11 and greater than 47, the value of A), so you'd have to have a "If var>10 and (var<48)" check, or something like that, before inserting values, and there are several numbers in that range which don't have a corresponding letter value, so you'd have to deal with those as well. the easiest way i know of is to insert null bytes into your string at those positions (i.e., your string would look something like: "WRMH"[0000]"?θV  ...). then, rather than using a variable to keep track of the next empty position in the string, you can use the length( command. because length( checks up to the nearest null terminator, inserting a null byte at the end of the string won't change the length, so the next key pressed will insert to the same position.

lastly, if you want to have lowercase letters and numbers as well, you can use one really long string that is three concatenated together ("WRMH"[0000]"?θV  ... "wrmh"[0000]"?θv ... [000000000000]"36 ...) and then have a variable which is multiplied by the total length of the first string and added to var, so setting that variable to 0 would select from upper case, 1 from lower case, and 2 from numbers.
Title: Re: Flow
Post by: squidgetx on December 25, 2012, 01:29:47 pm
I've found a better way, instead of keeping track of letter arrangements, would be to keep track of the key values. That way you can have one uninterrupted array of key values, the first element being the getKey that matches the letter A, and so on. Then you can just simply use inData(getKey,data(...))+65 to retrieve the ascii value of the letter :D
Title: Re: Flow
Post by: shmibs on December 25, 2012, 01:48:49 pm
that's good =D. how would you incorporate numbers and special characters into that, though? theta would be an annoying one to handle, for example, because it doesn't change between upper and lower case. would you just have different data sets for the three different states (upper, lower, num)?
Title: Re: Flow
Post by: squidgetx on December 25, 2012, 01:57:08 pm
Well theta comes right after Z in TI's ascii set, so that's not a problem. You'd need a different data set for numbers, but for lower case you can add a different number instead of 65 (I think 97 points to lowercase a). Other special characters are a bit of an issue, but if you're just wanting to input something like an appvar name it's not a big deal.
Title: Re: Flow
Post by: Sorunome on December 25, 2012, 05:18:37 pm
What is Flow?
Title: Re: Flow
Post by: shmibs on December 25, 2012, 06:55:58 pm
Well theta comes right after Z in TI's ascii set, so that's not a problem. You'd need a different data set for numbers, but for lower case you can add a different number instead of 65 (I think 97 points to lowercase a). Other special characters are a bit of an issue, but if you're just wanting to input something like an appvar name it's not a big deal.

if you are in lower case mode, though, you'd have to either use a special case for theta or have a separate data set. the same thing is true for ?, :, and space, but it's still probably better, though not as clean, to have checks for those beforehand instead of using another data set.
Title: Re: Flow
Post by: dinosteven on December 25, 2012, 09:46:30 pm
https://play.google.com/store/apps/details?id=com.bigduckgames.flow
Flow is a super-addicting game where you connect things of different colors with pipes. You can play it on a computer here: http://moh97.us/flow/
I looked at ztrumpet's Jump! code and found some text input code. It works.
So after I get the name string, how do I access the data from it? You have to store something like "appvTITLE"->Str1 and then GetCalc. I know how to do that - I used it in my Bounce game - but how do I add the "appv" part?
Title: Re: Flow
Post by: shmibs on December 26, 2012, 08:49:58 pm
like i said, use a freeram area. you don't need to store the name to an Str, and that wouldn't allow you to use dynamic input, as that hard-codes the string in your program at compile time. in order to do it dynamically, you would need to do something like 21->{L1} (21 is the value that axe inserts when you use the appv header token), put your name in bytes L1+1 onward, making sure that there is a null terminator ([00]) at the end, so it knows where the end of your name is, and then do something like Getcalc(L1).

also, you should really use squidget's method; the code is much smaller and neater.
Title: Re: Flow
Post by: AngelFish on December 26, 2012, 09:09:49 pm
Now, there's only 1 level in it now, hard coded. (The first 5x5 level on the Bonus Pack.) I'll make a level editor later and ask for people to help me make levels.

There really shouldn't be a need to have people make levels. You can generate them with a little bit of topology (well, more than a little).
Title: Re: Flow
Post by: dinosteven on December 27, 2012, 08:43:42 am
I suppose I could possibly generate random levels, but the original game has level packs.  I also have no idea where to start in making a random level generator.
Title: Re: Flow
Post by: Nick on December 27, 2012, 09:02:33 am
I would make a standard level pack, along with a random level generator. That way you can play the original levels as you wish, and still be able to make levels as you go.

When using a generator, it will also be hard to determine the least possible steps to get a maximum score (i guess that's the way it counts point, isn't it?), because the generator would have to determine itself whether it gives a lot of point or not. But it would definitely be a good idea to make one.
Title: Re: Flow
Post by: squidgetx on December 27, 2012, 10:37:27 am
I've only played the first few hundred levels of the free version but as far as I can tell the optimal number of moves is always the absolute minimum. I've never played a level that required more moves than there were "flows"
Title: Re: Flow
Post by: Nick on December 28, 2012, 09:05:00 am
I've only played the first few hundred levels of the free version but as far as I can tell the optimal number of moves is always the absolute minimum. I've never played a level that required more moves than there were "flows"
oh well.. i downloaded it too and played a couple of levels, and indeed, it's always the same numbers as there are different colors, so making a generator wouldn't be that hard i guess, but then you'll need to make a solver too, to see if it's possible to solve the generated one..i don't think this will be easy
Title: Re: Flow
Post by: AngelFish on December 29, 2012, 04:03:55 am
I've only played the first few hundred levels of the free version but as far as I can tell the optimal number of moves is always the absolute minimum. I've never played a level that required more moves than there were "flows"
oh well.. i downloaded it too and played a couple of levels, and indeed, it's always the same numbers as there are different colors, so making a generator wouldn't be that hard i guess, but then you'll need to make a solver too, to see if it's possible to solve the generated one..i don't think this will be easy

Right, the minimum number of moves is always the same as the number of colors because the lines never cross.

As for generated maps, there's actually a slightly different way to do it than proving a particular random map is valid. My thought isn't fully developed because topology is somewhat of a weak area for me, but here it is:

Imagine you're specified to have K colors in a plane for your puzzle. Within this space, there exist k lines stacked on top of each other in any particular order in a way similar to this:
Spoiler For large image:
(http://us.123rf.com/400wm/400/400/flippo/flippo0904/flippo090400590/4726074-a-stack-of-colorful-foam-forming-a-mulit-colored-striped-background.jpg)

At the endpoints of each of those lines is, well, an endpoint. These will become the points between which the flow is drawn. Now, we can use these lines to generate any possible puzzle by a certain series of stretching, bending, and compressing operations from at least one possible color order. The only real rule is that the lines cannot cross (i.e.: the boundary conditions can't change). This generates what can be called a homotopic configuration: A set that can be continuously deformed by those operations back into the original lines. All possible valid configurations MUST meet this criterion, so we know the set of homotopic configurations contains all of the solutions we're looking for. But wait, there are two other criteria valid solutions must meet: That the configuration fit into an NxN grid and that the flows completely fill the grid. The former criterion is really the problematic one because it's discrete. In a continuous space, we could just wrap the flows around very tightly and "fill" the loose parts, thus making the second criterion trivial except given the first. To be honest, I'm not entirely sure how to guarantee that the generated solution will fit in the discrete grid nor that it can be "expanded" to fill the grid, although the latter shouldn't be too difficult.

Other related questions:
Is the set of homeomorphic flows identical to the homotopic set?
Can all homotopic flows be "expanded" to fill a grid?
Is there a way to generate the set of all valid flows without specifying color ordering?

Clearly I've put a bit too much thought into this since I downloaded the game :P
Title: Re: Flow
Post by: DJ Omnimaga on December 29, 2012, 01:49:19 pm
Are there any screenshots so far?
Title: Re: Flow
Post by: dinosteven on December 29, 2012, 02:08:22 pm
I haven't been able to get tilem working... :(
I won't be able to make them, but if someone could download the src, compile it, and screenshot it, I'd be thankful.
As soon as I get some more things sorted, I'll upload it again with the build this time.