I have been a regular attendee at Manila Game Jam since I started in 2011. I was new to game development at that time and joining the event gave me the motivation to improve and be active in the local community. Nowadays, I help organize and host the event for IGDA Manila.
If you are new to game jams, here is a list of what you can expect to prepare you on what lies ahead.
Expect 48 hours of intense non-stop game development
Yes, you read it correctly. 48 hours, intense, and non-stop. Game Jams are designed to pressure jammers to make games under specific constraints which forces them to think creatively and make use of the time effectively and efficiently. It’s not for everyone but it is a unique experience any gamedev should at least try once in their lives.
Here are some game jam games that found success that you might have heard of:
I always try my best to structure my code according to the OOP way. It is a lofty goal that starts out great but then slowly becomes a mess the program gets bigger and new features (mostly unplanned) are added. It comes to a point where managing such messes becomes tedious and time consuming which forces me to rely on dirty shortcuts just to get things moving along. I always feel sad when I this happens. I always vow that next time would be different but, sadly, the same thing seems to happen every time.
My thinking is that maybe I just did something wrong or maybe I’m still inexperienced. While both a possibilty, sometimes I can’t help but feel encumbered by OOP rules where things become more complicated than it should be. Who am I to question things though? OOP has been around for a very long time and everyone seems to be using it everywhere. Surely it’s the best option that we have, right?
I eventually stumbled upon this video below titled “Object Oriented Programming is Bad”. It has a click baity title, but is worth checking out. It is informative, well-presented, and actually makes a lot of good points! The presentation tackles a lot of what makes OOP problematic in specific situations which validated my feelings about it. It also states a great case as to why an alternative (procedural and functional programming) are a better option.
My takeaway from the video is that OOP is not the only approach to programming. There are others out there worth discovering like functional and procedural programming, which I already heard about before but did not give too much mind. Maybe now is a good time to give it a better look.
I’m not ditching OOP entirely though as it has it’s uses. It would be nice to learn more about the other approaches in the hopes of helping me manage my current and future projects.
I have been using Emacs as my main development environment for my Haxe projects for quite awhile now in spite of the lack of helpful packages for the language.
To remedy this, I have made a number of tools and convenience functions that aid me with my everyday use. I have decided to package these in a repo so that it can be of use for other Haxe developers looking into using Emacs.
The Emacs Haxe Tools is a collection of code to help with Haxe development on Emacs. This package should be considered as a collection of random tools that may or may not be helpful. Most of the functions here were added because I myself need them in my work so do not expect this to be comprehensive.
You can get it or view the source code by going to its Github page.
I am planning to add a few more tools to this repository in the future. Mostly helper functions in editing Haxe files. Might even make a tutorial on setting up a working Haxe environment on Emacs. Hopefully, I can find the time.
When it comes to Haxe, a lot of developers prefer Vim over Emacs. This is simply because there is a lot of support for Haxe on Vim (Vaxe is an example) while there is almost none on Emacs (Aside from haxe-mode). I, however, personally prefer Emacs and I continued to use it for my Haxe projects in spite of the lack of packages and support.
Since I had free time over the weekend I decided to port the really useful Java Imports package to Haxe and uploaded it on Github and can be downloaded through Melpa.
Haxe Imports – Code for dealing with Haxe imports
This package adds the import-haxe-class function, which will prompt for the class at point, then the package, then add the required import statement for the class and cache a “class-name -> package” relationship for any future importing of the class.
This is my very first ELisp package and I learned a lot from slowly going through and understanding the original code. I am hoping I can use all the stuff I learned here to make more useful packages for Haxe on Emacs in the future. I have a couple of really useful Haxe development related functions that others might find useful.
Be sure to check them out and, if you have the know-how, please help me spread Haxe love on Emacs.
The article and video of my Casual Connect talk in Singapore is now finally up on the GameSauce website. In this presentation I talked about how I managed to juggle being a professional game developer by day and an indie game developer at night.
I recently realized that I will be needing an extra hand if I want my game to have the promised 100+ levels before the planned release date.
The solution to the problem is opening up development to level creators by having a system in place that would make level creation easy to set up and use.
After a lot of thought, I came up with a process that would make use of Google Drive.
The Basic Idea
A copy of the game is uploaded to a publicly shared folder in Google Drive. From here, collaborators can run and play the game on their browsers.
Each collaborator is then assigned their own levels folder where they could add and edit levels using their own Google Drive accounts. When they’re done, they can just refresh the game to see the new changes.
One of the coolest thing about Flambe is its animation pipeline. Using a tool called Flump, it takes animations made in Adobe Flash, converts them to texture atlases, and then translates the animation data into a json or xml file which Flambe can recreate the animations inside its engine.
This enables the creation of cool looking vector animations such as this:
Unfortunately, this is the only animation pipeline that Flambe has. Which means it does not support spritesheet animations out of the box.
I’ve created this tool as an alternative to using Flump. It is a fairly basic system that uses single separate images as frames for the animation. The structure was inspired by Flixel’s sprite animation system which I have used a couple of years back.
Like I said it is pretty basic. I’m planning to add a spritesheet support in the future but for now it does what it is supposed to.
Note: This game has already been improved and renamed to Pop Puff and Away! Check out the latest version here!
I cringe every time I watch people play my LD entry.
I saw people taking a long time to figure out what to do. Some never got it at all. Those who did, saw potential. Potential that could have been realized if it were not for the horrible design decisions that I’ve made in an effort to make it more fun.
I wished I had more time so I could have improved it some more.
But that’s the thing. I realized that without Ludum Dare’s really short time limit, I would not have finished a game, I would not have gotten feedback and criticisms, and I would not have learned anything at all.
The trick is to accept what you’ve made, learn from it, and move on.