ArdentKid is Now on iOS!

Good Friday to you! I’ve had an interesting relationship with app development recently (just read the last couple posts). But today, my mobile app was finally approved by apple! And so I present to you the app that helps anyone with a blazing desire to…


Now this app is not any of the games I’ve been working on, I initially started developing it as a response to the popularity of my tutorials and the demand for working examples; it’s a gateway for users to learn the concepts I’ve taught in game development. You’ll be able to play kickass game demos (as I create them) alongside the written tutorials, and also have access to download the project files.

I’ll admit, the first iteration of this release has some minor bugs and certainly isn’t everything I’d like it to be, but I will be updating it periodically. Also, give me a week or so to get it on Android.

Dance Eskimo Concept

Dance Eskimo is a rhythm game idea I had while travelling in Guadalajara, Mexico. I had been exploring the area with my scottish traveller friend Hamish, who had told me about a free ice skating rink in the central park. It was awesome to see that the government funding this bit of joy and entertainment, as it clearly builds community from what I could tell.

Ice skating with dance music gave me such a good feeling, I instantly knew I had to at some point to express it by building a game around the experience. My next game title, “Dance Eskimo: DJ on Ice Skates”.

While I”m super excited about the idea of it all, I’ve been forcing myself to prototype different ways of doing this as much as possible. I’ve also dabbled in the artwork and music a bit (with some help from talented individuals), and the gameplay’s already changed from what I expected it to be since I’ve started. The core concept seems promising though, for as far as I’m able to envision it.

Life Updates

It’s been a while since I’ve posted so here is a few updates on things.

First, the rather unfortunate news: Balloon Bazooka has been on hold for a while, as asset re-sizing is a time-consuming pain. My advice if you’re using sprites for your game on any platform is to always keep dynamic resolution in mind from the start. I don’t know when I’ll get around to fixing all of it up to be compatible with iPad and iPad Retina resolutions, but it’s not over till it’s over.

Second, I’ve invested some time in rebuilding my site with a Node.js backend, in addition to having a login and database to accommodate users, and created a mobile app with a demo included for game dev tutoring. The mobile app was rejected by apple in its first submission, but I will be resubmitting it soon. You can still download the game demo here.

The final bit is that I started work on a new game a few weeks ago in Flash. This might seem like a step backwards, considering I have yet to launch a game, and that it’s in flash instead of mobile. But these are my justifications for taking this route:

  • I have a better head for what I’m doing and am not repeating the mistakes I made with Balloon Bazooka
  • The game should be simpler, but will have the ability to expand complexity after it is launched.
  • I plan to kickstart it once I can make the demo available, and that will help me figure out if it’s worth porting to mobile or if I should move on.

I have been torn about whether to continue trying to do this, or if I should take the easy way out and get a job. It’s agonizing to not have anything to show for a year’s worth of work, and when being a cog in the wheel of industry yields so many benefits for developers nowadays. I keep asking if this is really worth it. Game development is a relentless monster.

My Favorite Travel-Phone Solution: an iPod

I feel more free than ever!.. $90 per month more free, that is! Since my 2-year plan with AT&T finally ended, I ditched their terrible service for a feature-enhanced one called Line2. Line2 is an app that’s challenged wireless service providers by offering a VoIP (wifi-only) calling service in addition to the 3G/4G capability, and they do it well. I purchased the iPod touch 5 (looks just like an iPhone 5, but even slimmer), and subscribed to Line2 for $10/mo. Now I can make calls/ text with the same phone number I’ve always had, over wifi. The downside of course is I can’t call or text when I’m out and about, but I’ve already become accustomed to this due to travelling (not to mention, free wifi is becoming more and more plentiful on this planet).

Getting Line2 wasn’t entirely necessary for me though, since iMessage and Facetime can be done completely over wifi as well (they’re tied to your apple ID instead of a number). But the biggest reason I wanted to retain my phone number was because certain texting services I use, such as GroupMe and KakaoTalk, have to be tied to a phone number to work. To me, it’s an excellent solution.

But the reality is that wifi isn’t available everywhere just yet. That’s why I also purchased the Karma 4G hotspot for when I’m back in America. Available by Clearwire towers, Karma provides 4G in may of the biggest cities around the US, at only $14/GB and no monthly or annual fees. So I keep my iPod online in most places (reception isn’t the greatest around San Francisco, but it usually works). Not only is it a cheap data plan, but karma has an excellent rewards system that is reputed by its name. It’s an always-open hotspot that can join up to 8 devices at once, and every time someone new joins, you both earn 100MB of data on your account.

OO-Lua Tutorials Revised & Combined!

It’s been a few weeks in the workings, but I’ve finally finished the re-write of my OO-Lua tutorials. It’s now more accurate and correctly applies polymorphism without any workarounds. Now go forth, and learn!

On the Road Again!

Well, I’ve never really been “off the road” per say, and it seems that going back home is more of a vacation than travelling around. But I haven’t posted about travels & minimalism for a while. My biggest fear has become getting stuck in the same place for too long, and I’m not even sure if that’s healthy. Anyways, I’m on a 3-week trip to Mexico as the opportunity to go presented itself through a good roomate of mine who’s parents happen to own a mansion and penthouse timeshare in Mazatlan. Here’s what I’m taking with me:

Yup, it all fits snugly in my small-sized dueter backpack. A minimalist’s dream come true!
- Dueter “Speedlite 20″ backpack
- Uniqlo down jacket (super warm, super compact, and water resistant)
- Beanie (excellent for sleeping anywhere, just wear it over your eyes)
- Travel Tupperware (seals and stays sealed in backpack)
- Black tank shirts [x2]
- Electric shaver
- Sports shorts (for working out, swimming in, etc)
- T-shirts [x2]
- Jeans
- Merino wool boxer briefs [x2]
- Cotton ankle socks [x3]
- Ultra quick-dry bath towel (it’s even light to pack!)
- Macbook Air
- Wacom Tablet (small)
- Toothbrush, floss, passport, pen, goo-tube, and other misc toiletries

For those who don’t understand how I can stay clean with so little, I hand-wash my socks, underwear, and shirt while i’m showering, then hang-dry it. So far it’s been a blast. As long as I can maintain a decent work/ explore ratio, I’ll be súper contento!

Don’t forget to like ArdentKid on facebook or G+ for more updates!

Shouldn’t it say “Nintendo”?

I was walking around a shopping mall in Vancouver and came across a nutrition store. My gaming mind was quick to think of Nintendo before I even knew what it was. Oh NEStalgia…

Would be cool if they added a Dr Mario logo next to that :P

Inheritance (OO-Lua, 4/4)

[2/15/2013: This tutorial has been re-written and combined into a single guide. Please click here to view the complete OO-Lua tutorial.]

Welcome to the 4th and final lesson of my OO-Lua tutorials (view the first, second, and third). A mashup of all four parts will be available on Corona’s blog as well, in a couple weeks or so.

Inheritance is a feature of OO-programming that can make your code much more concise and meaningful, by sharing properties and functionality between classes. Let’s stick to our cat and mouse game example.

Class Inheritance

This diagram shows the concept of Class inheritance:

When we create a new cat or mouse in our game, we want it to pick up functions and properties from each of its Parent ClassesDefinition: The 'Parent Class' is the next Class that a particular Class inherits from

Example: Animal.lua is the Parent Class of Cat.lua and Mouse.lua; Object.lua is the Parent Class of Animal.lua
. The Object Class would have code that all game objects share, such as show() and hide(). The Animals Class inherits these functions form the Object Class, but also may add move() or jump(), or properties like “lifeCount”. Finally, our Cat and Mouse Classes inherit code from the Animal Class (and thus the Object Class as well), but also may add squeak() and scurry() for the mouse, or pounce() for the cat. Here’s a side-by-side sample code of our Cat Class, next to it’s Super ClassDefinition: A 'Super Class' (synonomous to Ancestor Class) is any Class that is Parent to the current Class on some level, i.e. the Parent Class, Parent-Parent Class, etc.

Example: Animal.lua is a Super Class of Cat.lua, and Object.lua is a Super Class of both Animal.lua and Cat.lua.
, and Base ClassDefinition: A 'Base Class' is the bottom-most inherited Class.

Example: Object.lua is the Base Class for Animal.lua, Cat.lua, and Mouse.lua.
.

Hover mouse or click to view code full-sized

The Cat Class is required somewhere in our scene (when it loads), and it in turn requires the Animal class, which requires the Object class (line 4). But the important part is the setmetatable calls immediately following (lines 5 & 6). It essentially creates a new table (including the “Instances” table we’re used to), and attributes all of the Parent Class’s functions and properties to itself. This is similar to the explicit attribution we’ve done when creating New() instances around lines 12-17 (i.e. object.show = self.show), except it will attribute all functions and properties for you (we would not want to do this for New instances, because it would also attribute the Class functions like New and Destroy) . The purpose of line 4 is to allow Animal.lua to use all of Object.lua’s functions by referring to itself (self:show() in Animal.lua uses the code for self:show() in Object.lua).

Note: To re-iterate the purpose of lines 58-60, I defined these functions in the game scene, because I have several Classes (not necessarily children of Object.lua), that need to use these. You could probably even define them as global functions instead of scene functions, but it doesn’t matter too much (see OO-tutorial 2).

Instance Inheritance

Once our Classes have been fully inherited and available for use, the Cat Class creates 3 cats instances (line 63). This will call Cat:New(), which immediately calls Animal:New(), which immediately calls Object:New(). The object instance is passed the cat image name (all objects are a Corona display image in this case), and then it is attributed with the Object instance functions show() and hide(). It is returned back to the Animal Class on line 19, attributed with Animal’s instance functions, and then returned to the Cat Class to do the same. So the path that our instance follows is from the Base Class to the Final ClassDefinition: A 'Final Class' is a Class that cannot be inherited.

Example: Cat.lua and Mouse.lua are Final Classes
(bottom-up).

Why do we attribute “show2″ and “show3″? This is my remedy for a slight flaw in LUA. We sometimes want each instance to extend the functionality it’s inherited. If we defined show() again in Animal.lua or Cat.lua, then we would be overwriting the show() function we inherited from Object.lua, every time we create an instance. The easiest solution is to add a number at the end of each function name we know we will inherit, and then check for it at the end of its implementation (line 29 for example). If the Child ClassDefinition: A 'Child Class' is the inheriting Class

Example: Animal.lua is a Child Class of Object.lua; Cat.lua and Mouse.lua are Child Classes of Animal.lua
has show2() defined, then it will run immediately after show(). Theoretically, we should always do this for every instance function that is not defined in our Final Class (the Final Class is an exception because we know we will not inherit from it). This also seems different from the way we propagate New(), but it’s actually not! The function names just have to be unique because they are attributed to each instance, instead of each Class.

Conclusion

Using inheritance properly allows code to be re-used and easily maintained (pretty valuable).

That’s the end of the tutorial! If you have any questions feel free to comment and I’ll respond as promptly as I can! I was also asked to provide a working sample of these OO-tutorials, but I’m a bit torn as to wether I should do it or not. I don’t mean for this to sound douchey, but I’ve learned from my tutoring experiences that not everyone is deserving of shortcuts like that, especially if you don’t know why you’re doing what you’re doing. For those pursuing this knowledge for the right reasons, please take the time to experiment, and I’m confident that you will figure it out if you get stuck :)

Don’t forget to like ArdentKid on facebook or G+ for more updates!