Falling Sand

[Vynx]

It's been ported to the DS. It's even been ported to the PSP. But it hasn't been ported to the GP2X. Yet. If you're unfamiliar with the game, you can find one of the original java versions here:

http://fallingsandgame.com/sand/fall1.html (Well, technically not the first game, the it's a port of a japanese game)

You get falling "particles" called elements. Each element has a unique property. Water and be mixed with salt to make saltwater (in a later java version). Plant can be grown using water. Oil can be set alight, and so on so forth. It's immensely addictive for such a seemingly simple game, the depth comes from your own creativity.

Owen Piette has made an absolutely brilliant version of the game, that can support many more elements, custom elements, and even energy values and interesting effects. The possibilities are endless.

I highly recommend you give it a look, or even join the forums to get a hold of some custom modifications to see how expandable and diverse the game (if you could call it a game ) really is:

http://www.piettes.com/fallingsandgame/download.html

But most importantly?

Download the source code (For all you Open Source fans out there.)
I welcome anyone compiling for other platforms and sending me the binaries for hosting here.

By downloading the source, you agree to the terms and conditions of the file license.txt.

License can be found here

(Another version, SDL sand - which was ported to the Sony PSP can be found here)

I won't lie to you, the game has become considerably complex since the basic port of the java original, but source code is available for every version he's created so far, from the original port to his own interpretation of how the game should be. So, would anyone be interested? It's hard to show off the game in screenshots, so as i've said you really have to experience it for yourself to understand. And if that's not possible, there's always the possibility of porting SDL sand instead.

If someone ported this game, it would be a dream come true for me - it's been very popular when it's done the 'rounds on the Internet, and I myself have spent countless hours developing new elements, basic simulations of life, electrical circuits, and even complex Rube Goldberg machines. I guess it's more of a freeform simulator than a game, but still incredibly fun and imaginative.

The PSP has had it. The DS has had it. Linux has had it. There have been several PC versions. Would anyone be up to the challenge of adding the GP2X to that list? Thanks for listening.

 

[___]

this looks pretty cool! I think it would be nice to play around with on the gp2x...

 

[BenRoshi]

Woah... that's such a great way to waste time

 

[fringus]

I WANT THIS SOOO BAD!!!!!!!!!!! :lol: :lol: :lol: :lol: :lol: :lol: :lol: :lol:

 

[sand_man]

At first I thought it was dumb but then I got hooked on it

 

[hitbyambulance]

also check out Hell of Sand

 

[fringus]

Would this game be difficult to port?

 

[zektor]

Yes, I would absolutely LOVE this on the GP2X!

 

[hammy lite]

I checked out the source for SDL Sand, it's just a single file. Porting it is just a matter of remapping the keys and remapping the mouse to the joystick. It does use floats, depending how intensive the computations get it might need to be replaced by fixed point math, proberbly should be done anyway, but since the source is so small it should be quite easy. Should only take an hour or so to get a strictly working and unpolished port of it.

I might pick it up later this week if nobody else jumps the gun, but right now I have an oral exam coming up in a couple of days and I don't want any more distractions from that than I already have.

 

[Vynx]

I checked out the source for SDL Sand, it's just a single file. Porting it is just a matter of remapping the keys and remapping the mouse to the joystick. It does use floats, depending how intensive the computations get it might need to be replaced by fixed point math, proberbly should be done anyway, but since the source is so small it should be quite easy. Should only take an hour or so to get a strictly working and unpolished port of it.

I might pick it up later this week if nobody else jumps the gun, but right now I have an oral exam coming up in a couple of days and I don't want any more distractions from that than I already have.

Fantastic! I'm glad I remembered to include that link, as a lot of the other system ports came from SDL Sand. Do you think it would run well on the GP2X though? Or is there any possibility of you doing more than just making a basic port? Element scripting, for example, would be fantastic.

I never got it to work myself in windows, but many others did so it's probably my computer, but still, better check it works in it's current state first before porting the source.

I look forward to seeing it in GP2X form

 

[yoyoyoyoyoyoyo]

Can anyone give me a link to the DS version? My PC wont run it, but I wont to play it..

 

[sand_man]

My first release. It doesn't do anything yet but I'll keep working on it.

http://users.bigpond.net.au/sandman663/sand2x.zip

 

[sand_man]

Sorry guys. I changed my mind.
I don't have the time or patience to work on this.

 

[sparr]

to whoever ports this... the binary versions based on sdl sand all seem to have a bias causing rising steam and/or falling water to shift to the left. put a spout above a torch and notice the inverted 'hill' of steam on the roof always peaks left of the spout no matter how the torch is placed. this is probably due to uncompensated rounding error somewhere. please fix this before you port?

 

[hammy lite]

Fantastic! I'm glad I remembered to include that link, as a lot of the other system ports came from SDL Sand. Do you think it would run well on the GP2X though? Or is there any possibility of you doing more than just making a basic port? Element scripting, for example, would be fantastic.

I never got it to work myself in windows, but many others did so it's probably my computer, but still, better check it works in it's current state first before porting the source.

I look forward to seeing it in GP2X form

If it works on the DS it there should be no problem in terms om speed. Controlling the pen won't be as smooth with a digital stick compared to a mouse/touch screen but it's not like this is a fast paced RTS :rolleyes:. Also there might be a problem mapping all the keys controlling the elements, but in a worst case scenario using menus can fix this.

Not sure about other features yet, haven't thought about that at all. But if I port it I'll at least try to leave the source as clean as possible for anybody else who wish to implement it.

Whether or not I pick this up depends on how much I can work up my intrest for it, I really don't want to leave it as a half-assed incomplete port. But I also don't want it to suck up all my intrest and leave me with a failed exam so I dont' think I'll even be touching this addictive little game with a ten foot pole until I have gotten that out of the way .

 

[zzhu8192]

This simulation/game is pretty neat. Addictive...
The java port would've been fairly straightforward, but I didn't see source provided.
Also, the java applet version takes up tons of CPU.

 

[xythen]

Wow, this is a really addictive little game!

I hope someone is kind enough to port it over for all us peons to enjoy

 

[Vynx]

Fantastic! I'm glad I remembered to include that link, as a lot of the other system ports came from SDL Sand. Do you think it would run well on the GP2X though? Or is there any possibility of you doing more than just making a basic port? Element scripting, for example, would be fantastic.

I never got it to work myself in windows, but many others did so it's probably my computer, but still, better check it works in it's current state first before porting the source.

I look forward to seeing it in GP2X form

If it works on the DS it there should be no problem in terms om speed. Controlling the pen won't be as smooth with a digital stick compared to a mouse/touch screen but it's not like this is a fast paced RTS :rolleyes:. Also there might be a problem mapping all the keys controlling the elements, but in a worst case scenario using menus can fix this.

Not sure about other features yet, haven't thought about that at all. But if I port it I'll at least try to leave the source as clean as possible for anybody else who wish to implement it.

Whether or not I pick this up depends on how much I can work up my intrest for it, I really don't want to leave it as a half-assed incomplete port. But I also don't want it to suck up all my intrest and leave me with a failed exam so I dont' think I'll even be touching this addictive little game with a ten foot pole until I have gotten that out of the way .

Well, you wouldn't need to map every element to a button - couldn't you just scroll through them using L + R? The sound controls for plus and minus would be perfect for changing brush size too. The face buttons could be used for things like refreshing the entire window to save manually erasing everything, a button for limiting FPS, frameskip, and one for increasing CPU clock speed (Is this even possible before intialisation? Not sure) Start for pause, select for quit. That's everything pretty much covered. Then again, you're going to need some sort of joystick cursor control to draw the elements anyway, so you could always select elements with that as well.

A menu system would really help, as the elements are just coloured squares and that's incredibly basic and makes the game a bit obscure for those who want to play it.

to whoever ports this... the binary versions based on sdl sand all seem to have a bias causing rising steam and/or falling water to shift to the left. put a spout above a torch and notice the inverted 'hill' of steam on the roof always peaks left of the spout no matter how the torch is placed. this is probably due to uncompensated rounding error somewhere. please fix this before you port?

This has been a problem with several versions of the game, and I think this is because elements are checked from left to right - it's a compromise, I don't think anyone's bothered to solve it because current solutions require a lot of cpu consumption, but there have been ways to minimise it.

Some people think that looking at the source for Conway's game of Life will provide some answers to fix this bias, but not being an advanced programmer I couldn't really understand how to fix the problem myself. But this bias isn't in the java version, so perhaps looking at that would provide some clues?

 

[hammy lite]

Well, you wouldn't need to map every element to a button - couldn't you just scroll through them using L + R? The sound controls for plus and minus would be perfect for changing brush size too. The face buttons could be used for things like refreshing the entire window to save manually erasing everything, a button for limiting FPS, frameskip, and one for increasing CPU clock speed (Is this even possible before intialisation? Not sure) Start for pause, select for quit. That's everything pretty much covered. Then again, you're going to need some sort of joystick cursor control to draw the elements anyway, so you could always select elements with that as well.

Scrolling using L and R was what I had in mind. Nice sumation of the various features to map though. Increasing and decreasing the flow from the element emiters should also be possible, I think the best way to go would be to put these on the face buttons and leave overclocking, frameskip and quiting to a menu accessed through select.

Changing clock speed mid-game is possible, it works in DrMD.

A menu system would really help, as the elements are just coloured squares and that's incredibly basic and makes the game a bit obscure for those who want to play it.

Well a intro screen explaning the controls would suffice I think. A status bar displaying which element is currently selected would also be nice, maybe with some other usefull information like FPS and clock speed (or speeds if both CPUs are used, when dreaming you might as well dream big ).

 

[Vynx]

Talking about dreaming...what about a script editor to add custom elements? It's been done before in a few other versions of the game, and it just opens up a huge possibility of mods and support for the game. Of course, major wishful thinking, but i'd die and go to heaven if this were done. Oppiette managed it perfectly in his version, WxSand, but it's gotten incredibly advanced now so it might be worth checking out his first efforts to see how he managed it.

Once you know how to make a new element, it shouldn't be terribly difficult to turn it into a scriptable feature. It also gives you something to aim for in future versions (If you're willing to take this project on ) Or at the very least, make the code easily expandable with plenty of comments on how to add new elements, and just leave it to the GP2X community to tinker with it.

Best finish those exams first though, this game is incredibly addictive :lol:

Regarding element emiters - That'd be useful on the + and - controls too - perhaps it would be best to make brush size and emiter size menu driven, so once they're selected they could be used with + - control - of course, emiter size would be dependant on which element is selected too, but that's fairly obvious.