October 29th, 2013

Well, looks like I couldn't port the game to Android in time :/ The challenge was simply getting a "Hello World" test working on AGK, but documentation was just too plain confusing! I checked out the AGK forums and YouTube videos but it was of no avail. One page had about 75 steps you had to follow to get it working. I followed them but there simply was too many factors and variables that didn't make it work. Maybe next time...

I'd like to share my personal Lessons Learned for this project.

What went well?

• Breaking up tasks to small manageable pieces
• Consistently committing to git as much as possible.
• Getting a prototype of the game out as quickly as possible.
• Stop building features when the end is in sight, or else your game will never end!
• Finishing 10 days early allowed for enough time to fix bugs and polish the game.

What didn't go well?

• Porting to Android. Not enough knowledge or documentation on the matter. I should have tried a "Hello World" before porting the game.
• There was a frame rate issue I was not aware of until a comment was made on Game Jolt. Testing should be done thoroughly before pushing the release build.
• Technically, the "bullet" class was not implemented in the best manner. I have to research the best ways to implement "bulletManager" classes and "bullets".

Overall, pretty happy I finished this game. Currently we've got ~93 views and ~36 downloads on Game Jolt, a modest metric but great starting point.

And that's basically it! Stay tuned for news on my November game, there's some great surprises I cannot wait to share with you guys! ^^

October 20th, 2013

Release! "Donut Destruction" is available for download and playing at my Game Jolt profile. PLAY. IT. NOW!

Please let me know what you think about the game, leave a comment at the game jolt page if you like it. Or not :P

But with 10 days left, I can't just dawdle around. That's why I've given myself a BONUS MISSION. :O

Mission: Port "Donut Destruction" to Android before October 31st.

Yikes. Can I do this? Will YOU be able to shoot spinach and become Donut on your Android device? FIND OUT ON OCTOBER 31ST!

October 18th, 2013

I once read a question on gamedev on how does one go about developing a small game? What are the phases or cycles that you have to go through in order for the game to "bake" properly?

The SDLC, software development life cycle, of any program is important since it will determine the steps in which your program will grow. Typically you do the critical things for the programs in the beginning and leave the non-critical programming toward the end. As long as your foundation is solid, you can build upon it your features, enhancements, and what have you.

Different programs and applications will have different SDLCs. For example, a SaaS - software as a service - application will have multiple releases throughout the year, each subdivided into their own requirements gathering, development, quality assurance, user acceptance testing, and production line testing. This process continues indefinitely, maintaining the application.

But for games, it is different. The top answer for the subreddit post went something like this: first you do a quick programming prototype of your game, making sure the logic works. Then you do place holder art for the game. The art/sprites are just there as place holders and to show the logic is working. Then you build upon the programming prototype, putting in the fun features of the game. As this goes on, you gradually incorporate the polished art assets into the game. As they eventually mesh together, the game will be closer to a finished product upon release.

I don't know if this development style has a name (AGILE?), but we can call it the micro game SDLC for now. The micro is optimal for games that be finished in a "quick" time, so great for game jams and Ludum Dares. I would say it's not great for larger games since the merging of art/programming and other components could not be so smooth.

So, there you have it. For small games, try doing a quick programming prototype of the crux/essence of the game. Next, insert place holder sprites. Then refine and polish your code, adding in enhancements (not too many), and finally merge it with the finished art assets of the game.

Hopefully this development methodology will help you in your small gaming projects.

October 13th, 2013

Due to legal constraints, I was forced to remove the project from Github. Boo!

The problem was that the AGK source code was made available to the world illegally. So, I deleted those projects. Didn't wanna get arrested for a simple mistake.

So, how could I still use version control for these projects? The problem is I needed a way to store my projects in a remote server that is -private-.

I thought about using Bitbucket after some forums recommended that. But Bitbucket -> Atlassian -> JIRA -> reminds me of work. So hell no!

Enter Git and Dropbox. For those of you unfamiliar with Dropbox, it's a minimalistic cloud storage solution. Simple stuff; think Google Drive.

I followed the Using Git with Dropbox blog. Now, I have a private git repository! Totally free! :)

Now that the game exists in Dropbox, I can continue with the important stuff: working on the game!

October 7th, 2013

Computer programs are pretty complex beasts: they can exist in many different states, and one wrong piece of code can render your one's and zero's useless. It amazes me how huge programs, like the Windows Operating System or Halo, were made in a matter of years and came out to be successful products. How do you address the fact that computer programs are complex to write, fix, and maintain?

For Donut Destruction today, I wanted to work on the main player's bullet. I decided to use pre-existing code from a previous project of mine and use it for this project. It made writing the bullet logic of the game very easy. However, for this game I wanted to add another dimension to the bullet: a trajectory. Just as how a cannon is shot in the air, I wanted the game to replicate that sort of displacement for the bullet so it makes for interesting game mechanics.

Long story short, after unsuccessfully using pre-existing code, I tried working from the ground up.

There's the X-Direction of the bullet, then the velocity of the bullet depending on the angle of the cannon, followed by the Y-Direction of the bullet, then the velocity of the bullet in the Y-Direction, followed by the effects of gravity on the bullet.

To be able to break apart the whole problem, which in this case was replicating the trajectory of a bullet, into its smallest components is a very effective way to solve big problems. In addition, it guarantees that your code will run by the end since you've been running and debugging small parts of the program.

Hopefully this will provide some insight for projects that may seem insurmountable unless you break them up into their simpler components.

October 5th, 2013

When you're first starting your game, there's a bunch of questions you have to answer. What engine are you using? What's your game about? How are you going to start it? What version control are you using? It's a good idea to outline the basics of your game clearly and very simply. The closer the game is to your experience level, the more of a chance you'll be within completing the game on time. After learning that Unity 2D isn't even out yet (oops!), I went back to a familiar game engine library that I used in the past: App Game Kit. Pretty simple stuff I think. You can get the free Trial version of AGK, and follow along using the book Games and Graphics in C++. What's my game about? Thanks to October's Ludum Dare theme revolving around candy, I'm going to make a homage to the classic original iPod game "Helicopter", at least that's what I think it's called. It's a simple game where you have a turret and helicopters are flying around, and you simply shoot them. I remember listening to Eiffel65 and playing that game, so let's bring it back! If you're developing a game for the first time, or any project for that matter, you can get dizzy with what you're supposed to do. It really depends on what your work style is like. For me, making an outline of my tasks helps me to drop in and out of the project easily. It's also important in game development to try to get a working prototype *as quickly as possible*. This means do not worry about how cool your sprites look or how epic your music is. As long as your game has the logic working fine and the game does not crash, fixing the art and sounds of the game can be done later. Since I'm using a free version of AGK, I'm posting the code onto GitHub. Other options are subversion and Mercurial, but finding that a lot of programmers are using git for their projects its a pretty transferable skill to have. So, that's the update for now! Stay tuned for more updates later on! =)

October 1st, 2013

Today I was surfing the site meetup.com and found a cool meetup on Monday called "Deep Dive: Master 2D tools with Unity. I thought this would be the perfect chance for me to learn Unity 2D and start developing a game. I stumbled upon Jesse Freeman's blog where he talked about his gaming projects (which look totally awesome) and then found a cool website called onegameamonth.com. The point of the website is to ship out a complete game within a month. Motivation gained!

So, I've decided for my next project I'll be sharing with you the process that I go through as I try to ship out a game by October 31st. I think this will be an AWESOME side project and will really be a worthwhile journey. I'll be sharing the code onto GitHub and posting here as I make progress. You'll be able to play the game via desktop or web by the time I'm done.

So, make sure you bookmark this page to stay tuned on my game! Thanks for reading!