The Guelph Seven

Beginning March 5th, 2011, 7 University of Guelph students will take up the challenge to make 7 awesome applications in just one week.

After following the previous Seven Cubed Project, where 7 University of Waterloo students attempted to write an app a day for 7 days, we were inspired to try the experiment for ourselves.

Join us on our adventure!

Follow us! Like us! Fork us! Email us!

Our original intention with this second game was to try to allow control in a way that is more physically representative and involved than most. The idea was a one-player circular version of the classic game Pong, where you would control your paddle by rotating your entire phone, rather than by using some kind of push button or touch.

We began intending the game to be played flat, where the phone would be held with the screen pointing straight up and the paddle would decide it’s location based on readings from the compass. By keeping the paddle on a single point in relation to the real world, like say magnetic North, then rotating the phone would allow you to move the paddle on screen.

After getting the paddle control working using the compass (pointing South instead of North, but that doesn’t really matter) our testing found that it was not very precise. Trying to get the paddle in place to reflect the ball needed more precise readings than we were able to get from the compass. That was when we made the decision to instead use the accelerometer, and fix the paddle to the bottom of the screen, by using gravity to locate the phone’s orientation. This gave much more precise readings, and allowed enough control for the game to be played.

After getting the paddle control to work, we figured out the math to make things bounce off the walls accurately, and then to check if the ball was trying to leave the circle within the arc of the paddle or not. With that, the mechanics of the game were largely figured out. Then all we had to do was add a scoring system, and we had a working product.

As an after-thought we added a slow start to the ball so that there is time for the player to react to the starting of a new game randomly placing the ball.

While we had produce a minimal product that we felt was adequate given time constraints, we knew that to really polish the game we should add a start menu, and a high score tracker. To make the game more interesting, we considered the two options of advancing the difficulty of the game by either progressively shrinking the size of the paddle, or by speeding up the ball.

Brainstorming

The game from Day 4 wasn’t finished, and the people who were most involved wanted to keep working on that. So the rest of us had to figure out what the new day’s app would be. 

Given that we earned a bit of proficiency with Android from the day before, we decided to tackle another problem on that platform. We had an idea for free local voicemail, and we immediately went searching for existing solutions on the Market. We couldn’t find any, but we did find individual components, so we decided that it was feasible enough to pursue.

Auto-Answer

We found this open-source app available on the Market. It automatically answers phone calls on behalf of the user, and so we thought it would be the perfect place to build on top of. The code can be found here: http://code.google.com/p/auto-answer/

Functionality

The minimal viable product was defined to have the following functionality:

• answering and closing calls automatically
• recording the call stream
• saving the recording locally on the phone

The bulk of the day was spent making the existing project play nicely with Eclipse. Once that was done, work began on implementing the rest of the features.

Recording wrapped up really easily, and storing the files was also implemented quickly. All our issues came from handling the call stream. There’s nothing in the Android API available to end a phone call; odd because we were able to answer in the first place. We wrote code to toggle airplane mode on and off as a workaround to end a call.

So where is it?

We’ve achieved all of the features we wanted to when we set out. That said, there are limitations to the app, and we wanted to work on those before releasing it.

Limitations include:

• In order to play a recorded greeting to the caller, the speakerphone will turn on and then play the recording. We have been unable to find a way to play audio on top of the phone stream.
• During a call, the phone’s mic will be on. This means that the caller will hear background noise, which may be undesirable.
• Currently, the code is only functional for Android 2.1 and 2.2. From 2.3 onwards, there’s no way to access the phone stream, effectively crippling this app.

We’re still happy with the result of the day’s work. We’re just making things a tad prettier and we’ll release it soon. The code is available on github [here].

Brainstorming

After enjoying success with 3picStory, we started Day 4 on a good note. We quickly decided to make this ‘Android Game’ day, though we didn’t have many ideas on what type of game to make.

Discussions arose about making a simple tower defense game - making that in a day would be reasonably impressive in itself. But we wanted to go further than that and establish something unique about our project. We jokingly tossed around the idea of incorporating a shake sensor and maybe voice-activated mechanics into the game. Over the course of half an hour, we had fleshed out basic use cases for the mechanics and we were off!

Brainstorming

After a long Day 2, we wanted to work on something a lot more lightweight and simple. We didn’t look to our existing list of ideas, rather, we began to bounce ideas off each other. We debated jumping on the Charlie Sheen meme bandwagon, but decided against it. We looked at other simple picture sharing apps and poster generation sites for inspiration. The hard part was establishing something unique that would set our app apart. We decided on a slot machine type of mechanic to generate the images, and then we went to work.

CouchDB

We didn’t use it.

Google Images API

At present, our images are being served via Google’s deprecated Image Search API. We chose to go this route in the interest of time because it seemed a lot easier to use. There are limitations in that we can only return 8 images per query. We added some code to randomize the results so that we don’t only display the top 8 results for any given search. Future improvements to 3picStory might include changing to the new API, or even pulling in from Flickr for more accurate results based on their tagging system.