I gave a presentation about Flutter. It’s a lightweight overview, with a short discussion afterwords.
I learned Flutter for a client who wanted to explore it for a project they had in mind. They wanted someone with knowledge of Android, iOS, and anything else that might come up. Learning Flutter was a lot of fun! I have been on a few mobile projects since then where Flutter might have made a lot of sense. It would be great to get the chance to use it again in the future.
You can view the presentation below. I should note that I had to put it together on short notice. I would have liked to have had a more organized demo, but the presentation still works.
In my series of games you can’t lose, I modified a version of Flappy Bird and made it so you can’t lose.
This is an overview of the funnest parts of the project for me. If you want to see the details, review my code on github: https://github.com/jjerome00/FlappyGhost
I started with a clone of Flappy Bird called Flappy Cow, written by Lars Harmsen. I have never met Lars, but he seems to be a very talented developer.
His clone has a different theme than the original Flappy Bird. He uses trees and spiders for the obstacles, and a cow instead of a bird. You could also die. I had to change all these things.
Sprite sheet
My first order of business was to make the clone look more like the original game. This meant tracking down a lot of the artwork from the original game. I also got to play around with a sprite sheet.
The cow shown on the screen is using what’s called a sprite sheet. A sprite sheet is one big image that contains all the movements of a character. This way you only need to use one file for all your character’s movements. It’s easier to deal with.
I constructed my own sprite sheet for the bird using the same pattern in the sheet to make the bird’s wings flap. It involved lots of fun with Gimp.
Lining up the birds. Notice the wings moving from top to bottom.
Death becomes her
There are a few ways you could die in the game:
Touching the sky A side effect of not being able to die is that the bird can fly off the screen. You continue flying higher and higher without any repercussions.
I fixed this by modifying the collision checking and touch events. If you touched the top of the screen, that meant you were tapping too much. So I ignore the next tap. This gives the bird enough time to drop from the sky to avoid going off screen.
Touching the ground When the game detects a collision with the ground, I add an extra tap to keep the bird from ever touching the ground.
Running into a pipe When the bird runs into a pipe, I thought it would be funny to have the bird change into a ghost. It would glide right through the pipe as if it wasn’t there. That’s where the “Flappy Ghost” name came from.
Ghost Bird I wanted the bird to change into a ghost when it ran into a pipe. I thought it would be funny for the bird to look like it turned into a silly representation of a ghost. I added a little bit of translucency and a silhouette of a sheet over top.
It turns out the code already provided a nice way to achieve this. There was a feature to add accomplishments to the cow in the original Flappy Cow game. At a certain score the cow would get a hat or sunglasses. There was even a score that would change the cow to a NyanCat. I used that same logic to switch the bird sprite to the ghost sprite. After the collision with the pipe wasn’t detected anymore, I switch it back to the bird.
Clean up
There were a lot of features in the clone that you would want in a real game – such as an ads, analytics and Play Services. I had to remove everything without breaking the game. It was an interesting mix of learning how the APIs were added, and then figuring out how to remove them without crashing the app.
In Conclusion
I had a lot of fun breaking this app down and building it back up. I learned a few things about writing games, and made changes by leaning on existing features.
As a consultant, I am always writing, testing, and refactoring code to make it the best it can be. It’s fun to ignore most of that and make things work as quick as possible. I think the big lesson is that making something perfect does not always fit the client’s needs.
Recently I’ve been having a lot of fun playing around with other people’s code.
I’ve been forking games on Github to learn a little about how they work. I then change them so that they are impossible to lose. They turn out to be very short and completely useless beyond a couple laughs. Messing around with the code is almost more fun than the end result.
This started when a coworker was telling me that he had never won a video game. A few of us started coming up with ideas for games where it was impossible to lose. They seemed pretty funny, so I decided to play around with the idea a little bit.
I’ve only done a couple games so far. I’ve had some challenges along the way:
Most of these projects are stale and need a little work to get them working again. I spent a lot of time importing Eclipse projects into Android studio and working out the details
I had to pull apart a lot of conveniences: game options, number of lives, difficulty settings
I’m impressed how entertaining they are to put them together when I have no regards for playing it safe. Every hack is on the table as a possibility. I only have to worry about one thing – never lose.
“Tetris Can’t Lose”
I named this game after the old tv show “Parker Lewis Can’t Lose”
This was my first attempt at changing a game. It had a couple of surprises:
Tetris isn’t designed to win! You keep playing until you lose. So I had to come up with a way to win the game, and add it as an option in the game play.
I decided to add a funny “TaDa!” sound, so I had to add MediaPlayer and SoundPool. This change has become my exclamation point, and has made it into the other games as well.
I had to clean up some code, create a new launch icon, etc
One thing I regret is that I didn’t fork the repo correctly. I ended up losing some history that I wanted to show in Github. It’s not a big deal, but I wanted to make sure whoever ran into the project knew that I based it off someone else’s work. I ended up adding a note to the project’s readme.
I ran across this breakout game on Github. It had all the parts that I was looking for, and as a bonus it included lots of documentation. It was a sample game that explained a lot about how to write a game for Android.
It was rather stale, so it took a bit to import it into Android Studio and get it to work
It had a lot of game options I had to remove or change for my needs
I had to play around with the settings to get the most humor out of it
This one was different in that you don’t win immediately like in the Tetris game. You can move the paddle around and try to make the process faster, but it doesn’t matter.
Keeping the game play intact was a good idea – it makes the game a little more fun. The ball can’t fit past the paddle, but it looks like it could. It’s amazing to see people’s first reaction when they play. They have an initial sense of urgency to save the ball even though it’s impossible for it to fit past the paddle.
