Corona Quick Thought – Prototypes and Lines Of Code

Several recent posts on Corona’s forum have mentioned lines-of-code (LOC) metrics for some simple game mechanics, and it got me to wondering about what sort of metrics were “typical” of various little prototypes that I’ve tinkered with.

You can perhaps use these samples as rough guides for answering the question “what can be accomplished with x amount of coding?” Granted that not all coding styles are equivalent – the reader’s may be more/less verbose than my own – so take this as a rough guide only.

Note that all of the following prototypes were done with “plain vanilla out-of-the-box Corona.” None of the following prototypes use any other external plugins or libraries – the metrics given are for their entire set of code.

Also note that the genre of game can potentially be a significant factor to how much effort is needed to accomplish something minimally functional. All of the prototypes below are based on relatively simple genres to begin with.

Finally, note that none of these prototypes are full games.  There’s almost always way more work involved in all the other aspects of a finished game, and these prototype metrics make no attempt whatsoever to capture any of those aspects.

 

~1 LOC

A frequent source of frustration in the forum seems to be the loading Tiled maps since (at present) Corona offers no built-in support. Well, let’s put that to rest, shall we?
With one line of code you can have a tiled map loader. Seriously. Here it is:

Since Tiled will export to Lua format, loading its data is crazy simple.  Sure, it’ll take another 40 or so lines to actually render it in some minimal way, and maybe another 30 or so lines to implement a minimal camera for scrolling.  (and perhaps many hundreds more lines if you had the lofty goal of implementing every last feature that Tiled supports, rather than just what you actually need) But I’ll leave those as tasks for the reader, or a later post, because it’s off-topic, and there’s really just not that much to it.

 

~300 LOC

300 lines of code is enough for a skeletal RPG framework, with tiled map loader and renderer, scrolling camera, doors and room-based lighting and a simple character:

 

~400 LOC

400 lines of code is enough for a simple vertical shooter, with custom collision detection (you could perhaps do something similar, with less code, using the physics library, but it wasn’t appropriate here), pooled entities, and a scrolling camera/background (that really aren’t used here, but are present and ready just the same):

 

~600 LOC

600 lines of code is enough for a one-tap “dash” -type game, with generative level content, scrolling camera, parallax background, some player effects, an AI player for “demo mode”:

 

~1000 LOC

1000 lines of code is enough for a Lode Runner -type clone, with most of it being taken up by the enemy AI and supporting movement routines in Player (of which Enemy is a subclass) and Level:

 

~1300 LOC

1300 lines of code is enough for a fairly full-featured scrolling platformer, with a player character having multiple special moves (jump, double-jump, wall-cling/jump/slide), several special map objects (various spike hazards, lava hazard, springs, coins, stars):

 

Wrapping Up

My hope with this post is, to the extent that you might be aiming to achieve something similar to one of the prototypes above, that the reader might find these code metrics useful to give a reasonable guesstimate of how much effort might be involved. Happy coding! 🙂

ROBOT-SB dev blog – motivation, inspiration, and hacking

This installment is going to be a bit different. I thought I’d discuss some of the more “personal” aspects of development, using ROBOT-SB as the example. If that’s not that what you’re here for, I totally understand — feel free to skip this one, maybe come back next time for more coding talk.

Motivation

Why do I make games? Perhaps to make a load of cash? Hmm, sure, that’d be a nice bonus, but wouldn’t really keep me motivated. In truth, I do it because I just enjoy the creative process and technical challenges – this is a hobby, rather than a job. Further, and more importantly, I enjoy the fact that my kids like being part of the process, as it gives us yet another thing to do together, and they’re pretty good at thinking up game ideas.

What follows are some examples from ROBOT-SB…

Inspiration

Early on, ROBOT-SB with pretty “stingy” with its awarding of stars (the in-game upgrade currency). This was mainly due to not yet having tuned the cost curves – everything was essentially too linear and too cheap.

So the “quick fix” was to just make it harder to get stars. As the cost-curve developed, eventually I was going to need to go back and re-balance the star awards in order get it all working.

My son Nick noticed this problem before I actually got around to fixing it — he’s my in-house alpha tester. He came to me saying “It’s too hard to get stars”, and of course, he was right. So, the two of us sat down one day and brainstormed possible ways to award more stars.

As is often the case in such sessions, development decisions directed by an elementary school kid tend toward the “flashy” rather than merely “functional”, but we came up with a bunch of just-spawn-multiple-stars-whenever-you-would-have-done-just-one type solutions:

Some of these patterns might actually make it into the final game, but more importantly it was the “research work” needed to get multi-valued stars implemented. (not only was the early game stingy with stars, but they were only ever worth 1 each)

Hacking

Sometimes, rather than brainstorm interactively, I’ll take a collected group of ideas and suggestions, try to pre-implement them quickly, then show them off to my alpha-testers to gauge reactions. Most of this comes about from random comments of the form “it would be cool if it could…”. And you know how kids think, so finish the comment with things like: ..have a super-mega-ultra-gun, be invinvincible, ..look like Mine Craft, ..et cetera.

We call that “hacking”, and it goes something like this:

Wrapping Up

Anyway, hope you enjoyed a bit of behind-the-scenes, I’ll be back to technical stuff next time, cheers!

ROBOT-SB dev blog – control schemes

ROBOT-SB is essentially a “one-tap” game – tap to change direction, trying to dodge and/or shoot the various obstacles. But it need not be just a “one-tap”, as there are a number of control schemes that could work with it.

I debated long and hard whether to allow alternate control schemes, primarily because I felt it might unfairly tip the leaderboards in favor of one control scheme or another.

Plus, there was also a bit of irrational desire to preserve some sort of “artistic purity” imagined to be present in the one-tap scheme – but that was easily shed.

I had mocked-up various control schemes while “hacking” the game with my son (aside: actually, we’ve hacked in all sorts of wacky stuff, like super-guns, invincibility, even reskinned it with some ‘borrowed’ Minecraft art) but never truly tested them.

The only way to truly settle the issue was to properly implement and test these alternate control schemes. And you know what? The choice of control scheme doesn’t have that much effect on scoring potential after all, so the argument regarding leaderboard preservation went up in smoke.

So why not just give the users what they want? For example, here’s the “stick” control (the only one that needs a visual):

I figured I’d talk about how I structure the code to make this “easy”, as maybe it’d be of use to someone else.

The way the code works is that each control scheme is its own class, following a common interface and referencing a common “control state” where it’s “output” is stored. So all that’s really necessary to implement the various schemes is to just create an instance of the correct class.

The control classes are kept in a table, keyed in a way that matches the persistent user-preference value. (note: all of the below is technically “pseudo-code”, but functionally describes actual game code)

Then, when it comes to create an actual instance, it’s just:

Then, there’s a bit of wiring that needs to occur between the Player and the control scheme’s “state”. There are any number of ways to “connect” the two (event/message system, player-refs-state and “observes”, state-refs-player and “controls”, state passed to player as needed, etc), and I won’t get into the why of my decision, but Player get a reference to the control state and is wired up as so:

Another advantage of the tabled control schemes, and the way the player references the controls, is that it would be easy to drop in a “game.controls.DemoAI” control scheme, for example, if I later decide to do the “game plays itself in demo mode underneath the main title screen” thingy.

Then just create a game instance that overrides the user-preference setting with a request for the “demoai” controls, and presto! instant demo mode. It doesn’t do this at present, and probably won’t ever, mainly because of low-resolution “clutter” concerns, though it’s something that’s worked successfully for me in other games.

ROBOT-SB dev blog – bitmap fonts

One of the components that I needed for ROBOT-SB was bitmap font support.

I didn’t need anything elaborate – in fact, given the low-resolution that I’m working at, I hardly needed a proper “library” at all, just a few “helper functions” might have done the job.

So I began by exploring extant solutions, hoping to avoid reinventing the wheel if I could find something suitable already out there.

But the libraries that I found were either 1) outdated, and I had no desire to spend time updating someone else’s code that might not end up being what I needed anyway; or 2) a bit too elaborate, in that they weren’t focused on the particular issue that I needed to solve, primarily: proper pixel alignment.

I don’t need variable spacing, or kerning pairs, or tools for converting True-Type fonts, or styling support, or animation, et cetera. Primarily because features of that type tend to move characters around in a way that is not pixel-perfect. (or, at least, would have required a bit of patching to ensure pixel-perfect positioning in all cases)

So, in the end, I reinvented a toy-sized wheel, and I am oh so proud to now present you with.. wait for it… tah dah… SimpleBitmapFont!

I’m pretty sure that letters that look like fire are still cool, right?

You can get it from github.

Please note that it is definitely not intended as the be-all-end-all implementation of bitmap fonts! I’ll leave that to others with grander aspirations. But feel free to use it as a jumping-off point if it seems more-or-less appropriate for your particular project.

It is about as minimal as I could practically make it, something that just “gets the job done,” but not much more. (The version I’m using in-game is a bit different, with a few more specialized helper methods, but they aren’t of general-use enough to include.)