IDKJava

Clower Stats

2011-07-18T08:11:00.001-07:00

Our partner in crime for ICFP this year, Mr. Michael Clawar, recently established his new website for the various statistically-oriented projects that he does in his free time (he's crazy). I just thought we'd throw up a link if those of you as crazy as him want to check it out. It's really pretty cool actually.

Here ya go: www.clowerstats.com

ICFP 2011: Results

2011-06-30T06:42:00.001-07:00

After many hours of hard work, we finally got the results ... and took place 192 out of 199! Though this may sound terrible, and it is, it is better than last year, in which we tied for last with 0 points because the competition was so devilishly hard. This year, we got a total of 68 points. Considering a win was worth 6 points, and a tie was pretty rare, this probably means we won 11 games and tied 2. There was a total of 198 games, so that's a pretty miserable win/loss ratio. In retrospect, I think our biggest problem was that we targeted the most used slots in hope of breaking them, but we didn't really kill slots fast enough. If we had the time we should have made use of some of the higher functions, especially zombie. Unfortunately our schedules really conflicted with ICFP this year, so we weren't really able to all get together and get a solid few days of work done on it. Overall, I'm pretty happy with the results, because there are some pretty experienced programmers in this competition, and to even have placed above any teams at all is a pretty good accomplishment.

ICFP 2011

2011-06-22T06:17:00.000-07:00

It's been a few days since ICFP 2011 and we've finally had a chance to cool off and relax, so I thought I'd throw a blog post up about what we actually did.

Before I go into the details of the competition, allow me to introduce our team. We had four members in total. Three of us are prefrosh at MIT: Ryan Cheu, Kevin King, and myself Gurtej Kanwar. The three of us also happen to be the core members of IDKJava. Our fourth member, a talented statistician named Michael Clawar, is a rising senior at the high school Ryan and I attend. Naturally we were wary, because he aspires to attend our rival, Ha'vard. He was, however, a valuable member of our team, and we grudgingly came to accept his choice. With this formidable team assembled, we were ready to dominate.

We started off at around 8 PM, when the contest opened in our local timezone. We read the problem and immediately felt a little lost. None of us had any experience with Lambda Calculus or SKI combinators, and so we spent much of our precious time figuring out how the problem worked. In addition, we immediately had issues with the fact that we could not all meet up for the majority of this competition, because Kevin lives several hours away from the rest of us, and Michael was out of town for the majority of the competition. As a result we ended up using a lot of Skype, AIM, and Facebook to figure things out.

After finally getting a grasp of the problem statement about a day in, Ryan and I got together and we started work on simulating the situation, so that our "player" would have some idea of what was going on to make AI decisions. Ryan and I met up Friday evening, and we got cracking. We realized that the best way to code this would be to create some of our own data structures, such as a struct Slot and a class Card. One question we ran into was how to represent non-basic functions, such as functions that had been returned by S or attack. We decided to create individual classes for each of the different "stages" in these cards. For example with S, there is the main S card, and then two intermediate stages. Thus we had classes called S1, S2, and S3 to represent this. These classes could then call on the display functions of the arguments they had been passed to display themselves in proper parenthesized form.

Once we had our basic simulation set up, there was about a day's worth of debugging to go through, and special cases to add in. In particular, the zero card threw us off, because originally we thought there was a difference between it and the number 0. In the end, however, we realized that zero and 0 were the same thing, and then zero could not be called as a function as we originally thought. In addition we had to work out the zombie loop and add in another function to deal with the fact that some cards changed how they worked when being called by the zombie loop.

This took up the majority of our time on Saturday, leaving us just Sunday to get some strategy done. On Sunday I set up our program with the framework for creating an AI: a system for adding moves to a queue to be executed (actually a stringstream), and a few utilities, such as clearing slots, applying an SKI combinator, and applying a slot to another slot (given that the first slot was a function). I then unfortunately had to go to work, leaving Ryan to develop our entire strategy for all of Sunday. When I came back with two hours left in the competition, I found an elegant system, in which our program would constantly change which slots it would use, and constantly use help to add vitality and then use that extra vitality to attack the slots most used by the opponent program. Unfortunately, there were several bugs with our system, and it did not work as expected or segfaulted repeatedly, so we spent much of our remaining two hours trying to work out these bugs. With an outside pair of eyes, thankfully we managed to work them all out and with only a few minutes left to go had a working program. Because we were short I did not get a chance to test using the provided utility to see if our program actually worked, but we managed to get everything in on time, and we'll see how we did soon!

I'm pretty proud of how much we accomplished with such sub-optimal timings and conditions. If we had had all four days free and all of us could meet up, I believe we would have been in much better shape, but the fact that we actually submitted a working program at all is an improvement over last year, in which we were close but just missed the deadline on getting in something that worked. We did a great job!

Tegra 2 Issues

2011-02-26T17:03:00.000-08:00

Hi Everyone,

We've been fighting a bug recently on the Atrix relating to our textures not working correctly in our development version. We've tracked the problem down to glTexSubImage2D in android native. It appears that the width of the area which you wish to change must be a power of 2. The height however does not need to be a power of 2. This behavior has not been observed on any other device to our knowledge. Hope this helps anyone who has similar issues!

-IDKJava Team

EDIT: We got it working on the first try! After all we've been through with this issue I think we deserved it.

The Hint

2011-01-23T14:53:00.000-08:00

Apparently our program is trying to give us a hint:

EDIT: We found this later; still not quite sure what it's trying to tell us:

MIT!

2010-12-17T16:56:00.000-08:00

We both got accepted into MIT as of last night! The wait was long, but it's over now. Hopefully we will have more time to get some work done on The Elements and the UAV now.

Happy holidays everyone!!

DestinyCloudFist Risk

2010-12-05T16:21:00.000-08:00

Because of the lack of a good Risk game for Android, Ryan and I decided to take it upon ourselves to hack out a functional one ASAP. We started about 5 days ago and so far have a skeleton of the Activities set up and are just about getting into the game-play itself. Since we've never dealt with AI before, that part may be a bit of a challenge, but we're setting Feb 1 as our deadline for non-AI gameplay.

We decided to call our Risk game DestinyCloudFist in reference to a hilariously-named Starcraft strategy. Our Google Code page can be found at http://code.google.com/p/destinycloudfist/.

As always, if you have any advice, admonitions, compliments or threats, email them to idkjava@gmail.com!

Progress

2010-11-20T15:12:00.000-08:00

So we'd thought we'd update you on what we've been doing so far. We've been fairly busy, but the UAV has made progress; we've been putting it together and working a bit on the programming side. Here are some pictures from our work.

Marking the position for gluing airfoil pieces
Skeleton of the UAV put together, no electronics in yet.

Attempting to test our motor and propeller, hoping for lack of explosion. Later found that brushless motors don't connect like normal motors. We wasted an hour here.

Cool picture of the wing

College stuff done!

2010-11-03T16:14:00.000-07:00

Hi Everyone,

Gurtej and I are finally done with our college applications! This means that pretty soon we should be pumping out updates again. Currently there's a coding competition called CodeChef that Gurtej and I(Ryan) are participating in so it might be about a week before the first update comes out, but we promise it is coming!

On another topic, if you happen to be a college admissions officer looking for the site that Gurtej and I have been working on, the website is up at 74.70.156.22:8080 (ISP doesn't let incoming port 80 through). The source code of this page is up now as well at 74.70.156.22:8080/www.tar.gz! All of the pages, including PHP code are up, with the only change being removing the password/user names in PHP.

College Applications almost done!

2010-10-30T13:30:00.000-07:00

Hi Everyone,

Sorry for the lack of updates for such a long time. Gurtej and I(Ryan) have been pretty busy the last few months with college applications and schoolwork. Starting soon, we will be returning to all of our Android programming and new updates will be flowing out!

Money for a Server

2010-07-30T16:12:00.001-07:00

We plan to add a save feature to The Elements soon. This would hopefully allow everyone to upload something like 3 saves for others to browse and load. However, currently our server is just a patched together laptop sitting in my (Gurtej's) basement. It is neither a dedicated server nor fast. Ideally we would like to buy a computer that we can use as a dedicated server. Unfortunately, we lack the funds. Thus, we are calling upon you to buy the Falling Sandpaper app (think of it as a donate version of our app with a free gift!) and donate through the button here in our blog to raise the money we need. Once we get enough money together, hopefully we can find a decent server and buy it, or at least rent space in one. Please, help us out so that we can continue to improve this app!

Falling Sand Live Wallpaper

2010-07-12T14:49:00.000-07:00

A few of you may have noticed that recently, we released a second application to the market called "Falling Sand Live Wallpaper." It is essentially a live wallpaper of our application, "The Elements."

There are a few known bugs.

-It does not work on the official 2.2 update for the Nexus One.

-When tested on a custom 2.2 Nexus One ROM, it caused slowdown on the phone. This did not happen on 2.1 Droid.

We hope you will purchase this app to support us!

-IDKJava Team

Update 4.0 / 4.1

2010-07-12T14:47:00.000-07:00

Recently, we released two updates to our application, 4.00 and 4.10.

4.00 Added custom elements, fixed an explosion bug ( which in turn caused another bug), and added mud.

4.10 Was primarily bug fixes, the specifics of which can be found on the Google Code Site.

-IDKJava Team

Open Source!

2010-07-08T05:23:00.000-07:00

Both Gurtej and I are huge opensource supporters. We both use Ubuntu Linux as our main OS on our computer, and use Android on our phones. We proud to say that as of yesterday, our project, The Elements, has been opensourced! You can now find the project here, on Google Code. This means that now everyone can see and use the code we have written for The Elements. The only thing we ask is that if you port it to a closed system (iPhone, Windows), please make the application a paid app. On open systems (Android, Linux), please make it a free app. Thanks!

If you want to contribute, there are a few things that we need. First off, if someone who is knowledgeable in C/Java wants to help make our code neater and more organized we definitely need that. There are a number of tasks that I have in mind if any other programmers want to help as well. If you are skilled in art, we need someone to make a better icon, buttons for the main menu, an eraser button for the UI, and a better background for loading screen and main page.

If you're not skilled in programming or art, we also have a few things there as well. The most useful thing is reporting bugs, and testing. When you report bugs, try to post the exact steps to follow to reproduce the bug if possible. Bugs with vague descriptions such as: "It crashes sometimes when C4 is used" are not very helpful since they are hard to reproduce and determine exactly what is the problem. A better bug report would be: "When I place C4 on the bottom left edge of the screen in zoomed mode, and then place magma along the upper left edge, when the two react and the C4 explodes, the game crashes without a force close button." That allows us to look into the problem and place debug calls to find out what is happening.

Another thing we need is people to write out information for our game. We need people to fill the wiki, make a better help page for the game, and help translate the game. Anything else you can think of to help would be great as well!

-IDKJava Team

UAV: Update 1

2010-06-28T06:20:00.001-07:00

We've made big plans again! This time we're going to be working on building a UAV (Unmanned Air Vehicle) over the summer, desgined to drop water balloons on pre-programmed GPS coordinates. So far, we have ordered several servos, the Arduino Duemilanove board, brushless motors, and lots of different propellers. We're pouring the meager profits we made from ads in our Elements app into buying these parts, though we're still in the red unfortunately!

We are currently in the design stage. We have so far decided to use a balsa frame with cellophane covering (we'll see how that goes and maybe try something else). We're going to order the balsa pieces precut, which means we had to design the entire plane first. To achieve this end, we are using SketchUp 7. Here is one of our beautiful preliminary designs:

As you can see, the nose still needs to be designed. In addition, we need to finish modelling the ailerons and put them into this file. We will continue to document our progress, with as many videos and pictures as possible, and maybe at the end we can write up a tutorial for how we did it (assuming we actually succeed!)

ICFP 2010

2010-06-21T04:48:00.000-07:00

After taking part in Google's Code Jam and the more recent IPSC, which was an abject failure, we found another coding competition: ICFP. ICFP ran for 72 hours this weekend, from 8AM Friday to 8 AM Monday (EST). We worked on it for a total of about 12 hours each, because things like eating, swim practice, family chores, sleep, etc, got in the way. We competed under the team name of IDKJava as usual, and we were very hopeful going into it, and pretty satisfied, but a little annoyed coming out. If you want to take a look at the problem which we were trying to tackle, here is the task description.

The results were that with five minutes left of the contest, we were two digits away from getting the key prefix (a total of 17 digits) and we knew how to fix it. Unfortunately, we ended up finishing several minutes after the end. We are disappointed that we were not able to finish in time, but we were pretty proud of what we were able to do, because the problem was really challenging, and if not for a few stupid mistakes, we would have submitted a working circuit for the first car, which would have gotten us more than 0.000 points, and bumped us into the top ~200. If you want to know what we did each day, and more of the technical details, read on.

The circuit that we ultimately designed to output the correct key prefix was:

30R:
3L3R0#1L1R,
0L0R0#2L2R,
1L1R0#30LX,
4L4R0#0L0R,
5L5R0#3L3R,
6R6L0#4L4R,
8L8R0#5R5L,
9R9L0#8R8L,
7R7L0#6L6R,
11L11R0#7R7L,
12R12L0#11L11R,
10L10R0#9L9R,
13L13R0#10R10L,
14L14R0#12L12R,
15L15R0#13L13R,
16L16R0#14L14R,
18L18R0#15L15R,
19L19R0#18L18R,
17L17R0#16L16R,
22L22R0#17L17R,
28R28L0#21R21L,
20R20L0#22R22L,
21R21L0#19L19R,
29L29R0#24L24R,
23L23R0#25L25R,
24L24R0#26L26R,
25L25R0#27L27R,
26L26R0#28L28R,
27L27R0#20R20L,
30L30R0#23L23R,
2LX0#29L29R:
2R

Basically, it has gates in a row, connected to each successive gate with backward wires. The input thus moves down the chain one gate every click. By changing which outputs connected to the next gate and by adding in gates that were connected by forward wires we were able to modify the output to achieve the key prefix that we needed to submit in order to get past the first car.

Unfortunately, this technique was realized late Sunday night, and it was not until the next morning when Ryan woke up and explained it better that we were able to finish the circuit. If we had worked just a little bit faster, we would have been able to place in the top 200 out of ~800 which we thought was pretty impressive for competing as teenagers with no formal programming experience and a lot of things getting in the way. We're pretty sure that if we had had a little bit more time, or not had so many things conflicting with the contest, we would have been in the top 200.

A little timeline on our progress in ICFP:

8AM-Friday: Both of us are in our US History Regents. Neither of us will even read the problem until we come out.

11AM-Friday: We first read the problem, and realize how difficult this is going to be. Ryan goes home, ponders, and starts work. Gurtej has a Spanish final, so he mostly just ponders.

4PM-Friday: Both of us finally have time to work on the competition at home. We have figured out how to wire a circuit and the syntax of the circuit. We think the 19L in the sample circuit however, means "19 Lines". We also believe that the Xs (the external input/output streams) both have to be on the same gate, and that gate has to be on the bottom.

6PM-Friday: After messing around a lot, we realize we made a mistake earlier and figure out that the gate with the Xs can be anywhere on the circuit, but still think that the two Xs have to be on the same gate. We also realize the top and bottom labels are the locations of the Xs.

6 - 10 Friday: Many, many, circuits are made, lots of math and diagrams and truth tables. We document a bunch of different circuits to try to find patterns. We argue about what the wires initialize to, and what the external gate is. Both of us have different techniques for finding the truth table.

1PM Saturday: Both Gurtej and Ryan can work again, after swim practice and other things. We both get together at Gurtej's house. We spend a little bit working with circuits, then write a program to attempt to brute force the truth table. We don't realize that what we wrote won't actually work until about 2 hours later because we had been thinking of the special gate incorrectly. At this point, we decide to take a break: thank you, Modern Warfare! When we get back, we make more attempts at various stuff until we realize that we made a mistake and that the X's can be on different gates, and the problem suddenly becomes 20x easier. Within 15 minutes we know how the gates work, and develop the following truth table:

0,0=0,2
0,1=2,2
0,2=1,2
1,0=1,2
1,1=0,0
1,2=2,1
2,0=2,2
2,1=1,1
2,2=0,0

We were then able to get the input stream as follows 5-10m after we had the gates:

01202101210201202

The next step was building the program to simulate the circuit. Unfortunately we still were hazy on one issue: the backwards vs forwards facing wires. We thought at the time that loopback wires were ones that were required to wait one cycle before sending input because otherwise the result would be an infinite loop that would never stabilize. Therefore, we developed a recursive algorithm that was able to label these "lag" wires. At the end of the day, we have a semi-functional program that could identify the "lag" wires based our ideas. Ryan slept over at Gurtej's house so that we could continue work the next day.

Sunday Morning: We don't make much progress besides fixing a number of special case bugs in our program. We get a little frustrated and take another break. The next major discovery comes at about 2PM when Gurtej realizes that "lag" wires were actually just those that went from higher numbered gates to lower numbered gates, and could be accounted for by simply running through the gates in order of number, rather than using a crazy recursive function to make sure gates wait for the input from any non-lag wires before computing outputs. This made our program 10x simpler and we were able to get it working perfectly in an hour (see below for the C++ source code if you're interested). This allowed us to compute the key prefix:

11021210112101221

The next step was building a circuit that could output that key prefix. We had experience with working with normal circuits (Gurtej had significantly more than Ryan), so the first thing we tried to do was make modules that we could use to build a circuit. We came up with a number of modules but we were still missing a clock or a counter.

The next major breakthrough was a normalizer which could take the input stream and change it into a stream of 0s. Gurtej did this by taking a basic circuit which produced 220220220220... and adding a circuit to remove the 2s.

Input Normalizer:
0R:
0LX0#0L1R,
3R0R0#2R2L,
1R1L0#3L3R,
2L2R0#X1L:
3L

So we now could produce a constant stream of 0s. We also realize that we could convert that to a 2s stream pretty easily by tagging on a 0 - 2 converter (one of the modules we built earlier).

0 - 2 Converter:
0L:
X0L0#0RX:
0R

We then try to get a 1s stream, which was a little bit harder, but we eventually get it. The 1s stream is never actually needed so we don't have it typed out. Ryan comes up with a way to use the 1s stream to get a stream of 210 repeating, thus a mod3 counter. We also are able to create a mod7 counter which produces 2 outputs of different combinations modulo 7 given two streams of steady 0s as input. This way, we can easily produce 17 different 3 number combinations which are unique to which click the circuit was on, which we can then feed to a truth table circuit that will produce a certain output based on each input. This was certainly possible, but we realize it would be pretty hard. Additionally, we need something that could normalize any stream, not just the input stream, and eventually get this:

1s Eliminator:
0L:
X2L0#1R1L,
0R0L0#2R2L,
1R1L0#0RX:
2R

2s + 0s Stream Normalizer:
0R:
3LX0#1R1L,
0R0L0#2L2R,
1L1R0#0LX:
2R

Full 0-Normalizer:
0L:
X2L0#1R1L,
0R0L0#2R2L,
1R1L0#0R3R,
5L2R0#4R4L,
3R3L0#5L5R,
4L4R0#3LX:
5R

We basically only have to build a truth table circuit at this point, but we are really low on time.

After taking a shower, Ryan realizes that the same concept that we had used for the mod7 emitter could be used to create any input stream and be controlled very easily. Unfortunately, however, he does not explain it very well to Gurtej and goes to sleep before he can implement it himself, so it is not completed.

Monday Morning: Ryan wakes up at about 7:00 and is still really tired so he calls Gurtej and explains how the circuit has to be built so Gurtej could build it. By 7:30 Gurtej understands it completely and begins working on it. He is 2 numbers away from it working at the end, but fails to fix it because he is accidentally modifying the wrong gate. The circuit is then completed by Ryan about 15 minutes after the contest ended.

In the end, we had a lot of fun, and we look forward to it next year. We think that we actually preformed very well despite not quite finishing in time, and had we not made some of the mistakes that we did, we would have been in the top 1/4, which is very good, considering that we are still in high school, and that this is an international open competition.

Finished simulator source code:

#include
#include

#define PAUSE while(cin.get() != '\n') {}
#define LEFT 0
#define RIGHT 1

using namespace std;

int input(int side, int gate);

int inputnum, inputside;
ifstream factory("factory");

int main()
{
ofstream outputstream("output");

int inputarray[17], outputnum, outputside, colons = 0, nodes = 1;
int* wireval;
char in;

int truthtable[3][3] =
{
{2, 8, 5},
{5, 0, 7},
{8, 4, 0}
};

//Cache the inputstream
ifstream inputstream("input");
for(int i = 0; i <>> inputarray[i];
}
inputstream.close();

//Run through array and get stuff
factory.seekg(0);
factory >> inputnum;
factory >> in;
if(in == 'L')
{
inputside = LEFT;
}
else
{
inputside = RIGHT;
}

while(colons <>> in;
if(in == ':')
{
colons++;
}
if(in == ',')
{
nodes++;
}
}

factory >> outputnum;
factory >> in;
if(in == 'L')
{
outputside = LEFT;
}
else
{
outputside = RIGHT;
}

//Done running though factory...

//Create the variable sized arrays and initialize them
wireval = new int[nodes*2];
for(int i = 0; i < j =" 0;" i =" 0;" il =" input(LEFT," ir =" input(RIGHT," il ="=" out =" truthtable[inputarray[j]][wireval[ir]];" ir ="=" out =" truthtable[wireval[il]][inputarray[j]];" out =" truthtable[wireval[il]][wireval[ir]];" left ="=" right ="=" gate ="=" side ="=" nodes =" 0,">> num;
factory >> in;
factory >> in;

//Move it after the correct comma
while(nodes <>> in;
if(in == ',')
{
nodes++;
}
}

if(gate != inputnum || inputside != LEFT)
{
factory >> num;
}
factory >> in;
if(side == RIGHT)
{
factory >> num;
factory >> in;
}

if(in == 'L')
{
sidefinal = LEFT;
}
else
{
sidefinal = RIGHT;
}

return num*2+sidefinal;
}

Code Jam!

2010-05-24T16:22:00.001-07:00

In other news: both of us competed in Google's Code Jam 2010. Code Jam is a timed programming competition, in which you are given problems and have to write code quickly to solve them. Both of us got past the Qualification Round, but we struggled in Round 1 because it was significantly shorter and we both had other events that cut into it. Not to mention, in the last sub-round, lack of sleep managed to knock out Ryan, but Gurtej progressed to the next round.

If you want to see our placements, you can view the our scores in all the rounds. Gurtej registered as "looterguf" and Ryan registered as "choochoo".

Unfortunately, neither of us would have been able to compete in the next round anyways because it conflicts with our SATs. Our next competition is going to be the International Problem Solving Competition on June 6 for which we will be a team under the name IDKJava. In the meantime, we will continue our development of our next Android app, and hopefully release more elements.

3.71: Glass

2010-05-24T16:20:00.001-07:00

We added in Glass in this most recent update. Glass is mostly inert, but can be formed by mixing Sand and Magma, and also can be broken by nearby explosions, turning it back into more Sand.

Unfortunately, somewhere along the way, we lost our version of the code containing the removable top and bottoms and managed to break the eraser. We fixed the eraser, but as still working to fix the top and bottom. Thanks for bearing with us!

Update: v3.3!

2010-04-15T16:37:00.000-07:00

v3.3 is out! This version added two new elements: Salt and Salt Water. Briefly, here are the descriptions:

Salt:
-Interacts with water to produce Salt Water
-Melts Ice

Salt Water:
-Sinks in Water, floats in Oil
-Magma and Fire cause it to turn to Steam
-When it comes into contact with Plant, the Plant "dies", turning into Sand
-Melts Ice

We thought this was a significant enough change to deserve a .1 to itself, thus we are now at 3.3! Hope y'all enjoy it! As always, feedback is appreciated. Email us at: idkjava@gmail.com!

We love you guys!

2010-04-13T16:16:00.001-07:00

Thanks for all the great comments we've been getting this past week! Though we love them all, this one in particular was our favorite! We just thought we'd share it with you!

Update: v3.2

2010-04-07T09:38:00.001-07:00

Both of us, the developers, have spring break this week. We decided to set a goal of 3 new elements over the course of this week, and this update takes us 2/3 of the way to that goal. In this update, we added in two new elements: Acid and Steam. Acid eats it's way through every material except Wall and Water. Steam is the gaseous form of water, forming when water encounters Fire or Magma. Steam also condenses back into water over time. Hopefully these two elements will add a whole new dimension to the game. Meanwhile, we are brainstorming what other elements to add, and all suggestions are welcome! Simply email us at idkjava@gmail.com with your suggestion, and we will try to work it into the master plan!

Update: v3.1.3

2010-04-07T09:34:00.000-07:00

The last update, v3.1.2, attempted to fix the generator bug; However, it turns out that it didn't completely eliminate it. This version fully fixed that bug, but didn't change anything else, so we only gave it a .1 increase. Hopefully those of you who were running into issues with this bug have them solved now. We hope you continue to enjoy our app!

Update: v3.1.1 & v3.1.2

2010-03-30T16:47:00.000-07:00

Our latest two updates, 3.1.1 and 3.1.2, included a few minor bug fixes. The first update fixed a bug in which the game would crash whenever a generator touching an edge was activated. The second update reduced the lag time in the menu, so that it didn't take a few clicks until the Play Game button functioned. As always, email us at idkjava@gmail.com with feedback!

Update 3.1

2010-03-21T08:05:00.001-07:00

We recently released an update, version 3.10. The update added:

-wind: still experimental, probably will rename dragger or something else in future. It can be used to throw sand and such places, not very useful right now though.

Bug fix: The top of the screen now has an invisible wall like the other 3 sides, useful for accelerometer control

Update: 3.00

2010-03-14T12:38:00.000-07:00

This update changed the name from "Element Works" to "Reactions" and changed the icon as well. We felt like the icon was a bit boring and decided to change the name with it. Any feedback on these changes are welcome. Two new elements were also added to the update.

-Fuse: Like plant except it doesn't grow with water.

-Destructible Wall: Like wall, but can be melted by magma. It also can be turned to sand with the use of explosives.

Hope you like the update!

-IDK Java Team

Update: 2.50

2010-03-10T17:10:00.000-08:00

A new update was just released on the android market with a few changes and bug fixes. Sorry we didn't get an update out for awhile there, we had a few other things on our hands that we had to work on first.

Changes:
-Added Accelerometer control option in preferences
-Added bug fix for eraser (now correctly de-selects after selecting an element)
-Added ad on the main menu. Please check these out, we like revenue.

BUG FIX: v1.87

2010-02-22T05:23:00.000-08:00

We recently released an update which seemed to have a massive bug for phones running 1.6. We apologize for the fact that it wasn't fixed for several days because both of us were out of town and didn't get a chance to work on it, so we took it off the market until we could fix it. Yesterday we got together and released an update that should have fixed the bug. Please let us know if you are still having issues after the update, and we'll try to fix it ASAP.

Sorry! Our app is down for a bit...

2010-02-18T03:44:00.000-08:00

We recently released two updates: 1.85 + 1.86 that seemed to work on the droid but didn't work on some other phones. Because of this, we had to temporarily unpublish our app to avoid other people getting the faulty update. Hopefully we'll have this fixed soon.

Update: v1.85 + v1.86

2010-02-17T18:21:00.000-08:00

v1.85 was created in response to a user comment suggesting that the UI be optional. We quickly modified the code and released with the new changes, however there were a few bugs.

v1.86 fixed the following bugs from 1.85: Eraser was missing in non-ui mode. UI preference was not saved and often needed to be toggled twice.

However, we still have a bug with it crashing on some phones (not Droid) which we are working to fix. Please be patient!

Update: v1.8

2010-02-16T13:38:00.000-08:00

v1.8 is out! Only one thing was changed in this update: the UI. We did our best to make this into a much more user-friendly app, and hopefully we succeeded. In this latest update, we added in two bars, one on top of the screen, and one below.

On the top, most of the options that used to reside in the options menu are now in the forms of buttons above. The buttons in order are: Eraser(toggle), Play/Pause(toggle), Save, Load, Load Demo, and Exit. The first two buttons are labelled toggle because they alternate between two states. In the case of the Eraser button, it starts of deselected, but when you press it, it gets highlighted in red, and the current element is switched to an eraser. When you press it again, it goes back to deselected and your previous element becomes the current one again. The Play/Pause button toggles between being in Play mode and Pause mode, with the button showing what mode it will go to when you click it. The other buttons are pretty straight-forward.

On the bottom, there is one button and a slider next to it. The button has a palette symbol and functions as the new element picker. The slider is the new brush size picker, allowing you to easily change the size without having to go into the menu every time you wanted to make a slight change.

Even though most of the options were taken out of the options menu, a few were left, namely: Clear Screen, Toggle Size, and Preferences. The one change we made to this part was that for each of these that were left, we added in icons to just make it look nice!

Hopefully you will enjoy these new features! If you have any comments, suggestions, complaints, or just praise, send us an email: idkjava@gmail.com

4 Stars!

2010-02-15T15:45:00.000-08:00

We've reached four stars! Thanks for all the good ratings everyone! At this rate we'll be at 4.5 stars in only a few months! Here's an image taken from the AndroLib site showing our ratings spread:

This is all thanks to you!
As always, any feedback is appreciated.

1.6 Release

2010-01-31T08:28:00.000-08:00

A new update has just been released to the android market: Element Works Beta, version 1.6. This update contained:

New Elements:
-Magma
-Stone

Features:
-Preference Screen, background can now be changed to either white or black

Bug Fix:
-Screen can now be flipped in preferences. This will make the game draw on many 2.0 ROMs for the G1 that had issues before, and may fix drawing for the HTC Tattoo as well (EDIT: confirmed).

v1.5.5 is out!!

2010-01-26T04:54:00.000-08:00

Our most recent update, v1.5.5, was published last night! In this version we:
-Made Oil lighter so that it is easier to see against the background
-Made toggling size not clear the screen
-Made pressing Home and then going back into the app not clear the screen

Because this update did not include much, we felt that it did not deserve a whole version to itself, so we named it 1.5.5, because we plan on making a full update next week (v1.6) with added elements with many new functions! We just wanted to get out what we had so far after making our breakthrough with solving the clearing screen issue (that one took us a while). Hope y'all enjoy it!

Send us Feedback please!!

1.5 Released

2010-01-24T11:44:00.000-08:00

Last Sunday, we released the 1.5 update to the Android Market and forgot to update the blog. The update contained oil, made ice a stationary element, and changed the movement of liquids. Various minor bug fixes were also included. Tomorrow we hope to update with a fix for the reset issue when switching to another application and coming back.

-IDKJava Team

1.4 Released

2010-01-09T15:25:00.000-08:00

Alpha 2, Version 1.4 has been released on both the android market and the SlideME market.

Changes:

-Ice freezes water slower
-Fire has longer lifetime
-Fixed reset on screen blackout
-Added one slot save/load
-Added exit button
-Increased generation of particles by generator element
-Fixed landscape mode on high resolution screens (Droid,Nexus One)

Planned features for next update:

-New element: Oil
-Possibly change ice to stationary instead of falling
-More save game slots

Update: v1.3 is out!

2010-01-06T14:51:00.000-08:00

Our New Year's Resolution was to work more on programming and get more updates out, and we have succeeded so far! This is the second update of the new year, we hope you enjoy it!

New in this update:
-Added Generator

Generator:
Our new element is called Generator. It is very similar to the element "Clone" in the Powder Game. Basically, when a particle collides with it, it is "set" to that particle. Then it will randomly produce that particle in nearby empty spaces. It also sets all the Generators around it, so a line of Generators will usually all be set to the same element, unless two elements were set at different points on the line at roughly the same time. We hope Generator will exponentially increase the complexity and enjoyment of our game!

As always, enjoy and send us feedback via email!!

Update: v1.2 is out!

2010-01-05T14:47:00.001-08:00

We managed to get another update out! This update added in the element ice and fixed a bug when a fire particle hit the top.

Enjoy, and as always, we want feedback!!

We Finally Updated It!!!

2009-12-31T16:02:00.001-08:00

Yes, it's true. More than a month after it was promised, we finally got an update out. This update gives you:
-Speeded up burning
-Speeded up everything else
-Fixed many bugs
-Now applies to all Android devices
-Made use of OpenGL and NDK for more efficient code (meaning it uses much less processing)

Plans for the next update include many more elements, even more optimization, and eliminating any bugs that crop up. Please, please report any bugs, new features, and improvements you'd like to see.

Update is Coming

2009-11-21T17:30:00.000-08:00

Sorry about the delay, a number of things got in the way of the release. One of us realized that Area-Allstates for violin was this week and therefore had to use his programming time to practice violin. We both also received a ridiculous amount of homework from our teachers so there wasn't enough time to program what we needed to get done. We are working hard to get the release out soon though!

-IDKJava team

Small Update

2009-11-14T10:20:00.001-08:00

We should be releasing a small update later today after testing finishes.

New features:
-Connected line drawing
-Better burning

Bug fixes:
-Partly fixed bug where particles start not working properly when burning large amounts of plant.

We have made progress in OpenGL, and we hope to make the Nov. 20 deadline for this feature which will provide a large performance improvement.

-IDK Java Team

EDIT: Update may have to wait until tomorrow, currently fighting memory leak that won't go away!

Next Deadline: Nov 20

2009-11-09T15:52:00.001-08:00

We plan our next release (Alpha 2) to be on Nov. 20. This release will work to accomplish the following:
-Massive speed improvements
-Addition of more elements, including fire and plant
-Fixing a few minor bugs

Hopefully we will have many, many downloads! If you have the game, it if definitely worth your while to upgrade to Alpha 2!

Droid version out!

2009-11-07T12:31:00.000-08:00

Our sand falling game for android has been released on the market for the Droid! If you downloaded the old version and had a Droid, please uninstall and install this one instead! I do not have a Droid to test this on, but I have had one tester say that it runs very smoothly! Try it out!

Alpha 2 will be coming in about 1.75 weeks and will include

-major speed improvements

-plant element

-fire element

-pen size changing

-bug fixes

The only known bug right now is that water acts weird near the right side. If you find others, please let us know!

-IDKJava Team

Alpha 1 on market

2009-11-05T19:24:00.001-08:00

After a quick edit to the game to change the package from com.example.hellojni to a name google lets us use on the market, the alpha version of sand falling is officially on the market. It is currently set to be only viewable by g1 and mt3g users. More device support will be released tomorrow.

Alpha Release!

2009-11-05T14:14:00.001-08:00

The Alpha Release of our Falling Sand Game comes out today! Go download it via your Android Phone for FREE! Tell us what you think, what we need to work on, and most of all, enjoy!

A few things to note about the alpha release:
1. It is an alpha release, meaning that it has very basic functionality, and is not intended to completely accomplish the task. The point is to get the game and our name out there, so that you are aware that this is in development, and to get your input on it
2. It runs very slowly! As it says in the message when you run our game, it is very processor intensive, thus you may need to close other programs using your processing power before running it, and depending on the processor in your phone, it may run really slow and choppy. This is one of the main issues we are devoting our time to.
3. It only has Sand and Water! As we have stated above, it is an alpha release, and once we accomplish Step 2 and have it running fast, we plan to develop more types of sand, our first task being to develop fire, as that is one of the main tenets of our Falling Sand Game

For those of you who do go out and download this and contribute to its development, thank you all!

Hello Everyone

2009-11-01T06:19:00.001-08:00

Hi all,

This will be our temporary website for IDKjava until we have the time to finish our own website. We will be posting updates about our sand falling game for android here.