The Impossible Game

Literally.
By: Michael Matz and Peter Spettel
Computer Science and Software Engineering
October 2015

This documentation describes not what we created in MIT App Inventor 2, but
rather, what we didnt. Our original idea for the app was titled The MLG Impossible
Game. Quickly, it lost the MLG. Then, it lost the game. Simply put, it was the
impossible.
Materials Used:
MIT App Inventor 2, Computers, Paint.NET (graphics), Google, Skype, and Notebooks.
Overview of the Project
If you are not familiar with The Impossible Game, it is a simple side-scrolling
platformer in which you are a square. If you tap the screen, the square hops. The key of
the game is to avoid triangles that enter from the right side of the screen, because if you
come in contact with one, it is game over. This was the main premise for our idea. The
game needed graphics, and we needed to implement movement, triangle spawning, a
score keeper, and a Game Over screen. Ideally, we would also incorporate 5 themes,
all based around inside jokes and popular themes from the internet.

The Impossible Game, available on iOS and Android devices.

Initial Mindset
Coming from fellow programming languageScratch, this seemed like baby food.
Michael had created a fighting game complete with movement, attack, deaths, damage,
sound effects, etc. Surely, he could make a square jump. When fellow programmers in
our class told us they would make a soundboard, we gawked at their elementary
concept. We checked our genius idea with the instructor first, to make sure the project
would be carried through with. He informed us that every tool that Scratch had, is also in
App Inventor in some shape or form. That being said, we were filled with determination.
Our project was going to be amazing, and with our instructors input, we were ready to
go. So behold, our final result:

Fun fact: He lied.

Procedure
We started out with sketches and pseudo-code, written down in our notebooks.
We made a list of sprint tasks, objectives that we would orderly tackle in order to get
our app finished. For each of these tasks, we wrote down how we would successfully
get through each of them via pseudo-code. We also created a list of variables,
explaining what each one would accomplish. As for the sketches, Michael drew
concepts of the different themes, depicting multiple costumes for the square, triangle,
and background effects. He even wrote down different music and sound effects that we
could use. Of course, themes were our last priority, but it was fun to just imagine what
they would be like, even if we couldnt get to that point.

Our brainstorming process, including tasks, sketches, and pseudo-code.

With these sketches done, we began to dive into App Inventor. Sadly, this part
isnt long. As I hadnt made the graphics for anything yet, we started out by finding a
small red square on Google Images. We would use this square as a temporary graphic,
so we could program the game while the graphics werent complete. Initially, we actually
couldnt figure out how to position the square where we want it on the screen. After
consulting our problem, we found out that we must first implement a canvas on the
Designer menu of the software, and then within that canvas the square can be freely
dragged. Next, we resized the square to be 40 by 40 pixels, as the image was too large
prior to doing so. Then we began to form blocks of code.

We made 3 variables, global BlockX, BlockY, and BlockZ. These would

provide constant values for the square to be, since it wouldnt be moving anywhere.
This way, whenever we want the square to appear from the title menu or game over
screen, we could easily pull from these variables. The block on the right would set the
squares position to that exact spot using the variables. To make sure it only executes
once, we did something tricky. BlockX is initialized to 56, which triggers this block of
code. Once the block is executed, it changes the X value of the square to 57, to avoid
an endless loop of the block running had the square been kept at 56. The problem with

this block, though, is that you may notice there is no procedure tag surrounding it,
making the block incomplete. In Scratch, you could drag a forever tag around an
algorithm to make it constantly loop in the background, checking for the conditional nonstop. In App Inventor, there is no simple way of doing this, meaning our block would not
be constantly checking for the X position of our square. Seeing as we didnt need this
block immediately, we pushed it back to worry about later.

We moved on to animating our sprite. The concept of this block is simple. When
the user touches the canvas (essentially the entire screen), the algorithm will call
ImageBlock (our sprite) to move to the specified X and Y. X is pulled from the variable
BlockX, while Y is moved a specific value, 45 pixels above its starting position. After this
is done, the block executes another procedure exactly like the previous one, only
returning it to the original position. In theory, this would work easily. In reality, the square
did not budge no matter how many times we tapped the screen. We learned the cause
of this may be because of how App Inventor performs every action in the block at the
same time, as opposed to Scratch which performed everything in order. To solve this,
one of our fellow classmates offered us his algorithm that called a delay, allowing there
to be time between each action performed.

Basically, this algorithm takes advantage of App Inventors delay clock, adding
one second of delay and then finishing when the delay clock reaches that time.
However, despite this block being added to our program, the square still stood
immobile. We went through App Inventors various drawers, trying out different tags and

procedures, but simplynothing happened. At this point, there was nothing we could do to
fix our project. The Impossible Game became impossible.
Summary/What Went Wrong
Simply put, we bit off more than we could chew. Still in the Scratch mindset, we
thought we could still make a full-fledged game despite the differences. We may have
been able to make the game eventually, but that would have involved very complex
algorithms that we just didnt have the time for. Yes, our instructor misinformed us and
set us up for failure. But, in the long run, thats perfectly okay. We needed to realize that
we wont be masters at every programming language we pick up, and that we need to
adapt to new programs and design games/apps based around those programs. Looking
back at the pseudo-code, it is clear that we designed the game to be built in Scratch,
and simply disregarded the possibility of App Inventor not containing Scratchs tools. So
in the end, we may have not had a functional app, but at least we obtained a valuable
lesson in the world of software development.
Backlog of Errors
-Sprite was too large. (fixed)
-Sprite couldnt be freely moved around the designer menu. (fixed)
-Could not constantly check for the X position of the sprite.
-Block would not move an inch, despite the delay algorithm.
Personal Reflections
Michael: There are no arguments, this project was a bust. However, that is my fault.
After making complex games like Fox Simulator and Break the Targets, I felt on top of
the world. Well, that may be an exaggeration, but I was definitely confident in my
Scratch abilities. Tackling a simple jumping game seemed pretty easy, but I dove in
before truly considering the limitations of the app-building software. There were no
forever tags, no costume changes, no orderly procedures, but thats just how it is. I
could just blame it on my instructor, but honestly I feel I needed some sort of a slap to
the face to wake me up to reality. I am no programming genius, and I honestly did not
like App Inventor coming out of Scratch. But from now on, when I get introduced to new
languages such as Python, I will educate myself to the languages strengths and
weaknesses of the software and develop any future projects around them.
Peter: This task, I think, would have been much simpler had we chosen a smaller goal.
Choosing the Impossible Game as a goal is that in itself, impossible. At least for our
standards this goal was not reachable. If we were given more time then we could have

made this game but since time was the deciding factor, we could not figure out what to
do next. The only thing we could get working was the sprite of the square. The task of
making the square sprite jump was just too much to figure out in the small amount of
time we were given. If you touched the screen, the square sprite would move up but it
would not come back down and we had no idea of why it would not come back down.
The main thing to take away from this is that App Inventor has a very different
schematic than Scratch which is what made us not do as well as we could have done
with Scratch.