Wanted to let all of you who still visit this website know that I have a new project up on Steam Greenlight! Any upvotes you’d be willing to send my way would be much appreciated!

Steam Greenlight : http://steamcommunity.com/sharedfiles/filedetails/?id=880851449

Its been awhile. My game development journey continues, but on a different site:

The Gaming Observatory

A lot has changed since I originally started this site. I’m now a solo indie developer trying to get his first commercial game out into the wild. I’ve moved over to using OpenFL and Haxe directly via the FlashDevelop IDE as well.

The new site is in its infancy still, but I hope you’ll stop on by and continue following my endeavors moving forward. I will leave this site up for the foreseeable future, but I won’t be consistently maintaining it or the materials on it. You’ll have to come to the new site for new stuff, obviously.

In particular, I feel its worth bringing up that I don’t use Stencyl anymore. I know a lot of people still come here for my old tutorials and guides, but being more than a year removed from the platform I’m not in the best position to answer those questions anymore. I’m very glad though that so many people found my material to be helpful, and I hope that in some capacity I can continue to help aspiring developers (of which I am one) realize their gaming dreams.

So this certainly isn’t a “good-bye.” No need to get sentimental! Its just a figurative change of scenery, if you will. And I would be very grateful if you came over to my new site as well! Thanks again for all the support!

About a week after LD32 I decided to step back from the engine/gamedev for a week or so. It had really been something I’d been vacillating over and with the extra elbow room the early #1GAM entry had given me time-wise it seemed like a good idea, and I realized I was way more burned out than I’d originally thought. I was able to sort of “recoup” and get ready for May.

And the month of May. Now that I’ve managed to pull myself back into gear, I think something has become clear this month of May: stop over-engineering.

Its become clearer why people say to focus on making games as opposed to engines. True, I’ve used #1GAM as a way to keep myself on track, but ultimately a major focus has been the engine. I keep wanting to tweak and find that right balance between ease and usefulness. Its easy to say its about the game, but its another to actually put that into practice. Good night, engine-itis can really be a pain.

It might be nice if everything fit nicely into the gamedev box… if all my square pegs only had to go through square holes, that would make things easier. But its just not so. Innovation isn’t a bad thing, but trying to reinvent the wheel every month just gets tiresome. Take what you have and add to it or change it in small chunks. So far this month, it appears to be working rather fluidly.

Alas, its the beauty of doing #1GAM; being able to sort of find your game dev self emergently. I recommend it to any who are still on the fence about it!

It has been a bit of a challenging month. Yet somehow I found the motivation to power through Ludum Dare 32 and make a new game: Turbo Moon Hero! This was a throwback in the fact that I actually used Stencyl for this, but the important thing was to get something done and I was apprehensive that my base code wouldn’t cut it this time around. You can play the game here:

http://ludumdare.com/compo/ludum-dare-32/?action=preview&uid=7658

Please accept my apologies for not announcing it sooner! So did I learn anything even though I reverted to Stencyl? Of course.

For one, I felt loose. I wasn’t concerned so much about engine structure or what was going on underneath the hood. I chose a simple idea pertaining to time and complexity and made it stick with what I had. And what happened? Game in a weekend, that’s what. Graphics, sound, code… yep. If anything, it was a breath of fresh air to see it happen. It CAN happen still. If I keep at this Haxe and OpenFL thing, it could potentially happen using that! I PLAN to make that happen.

Taking the experience back to my engine will be important. Having done three quickies in it already has helped carve things out a bit, but even using Stencyl is part of what motivated me to get started with it in the first place. I’ve been trying hard to make the engine rigidly abide by a certain ECS standard, but it may be time to shake things up and throw a wrench in the mix. I want to get it to that point where it isn’t so painful to get simple stuff going (i.e. not rehashing code that really shouldn’t be, clean ways to set things up, etc.) Just try things and see what happens, even if it doesn’t look all that shiny. Just make it work.

I’ve already posted this game as my #1GAM for the month, so I’ve been able to breath a bit easier in that regard and take some time to think about the engine post-LD32. I’ve begun trying a new idea I had, so we’ll see how that works out moving into next month. In the meantime, scoot over to Ludum Dare if you haven’t already and give my game a whirl!

Thanks for reading guys!

As I continue to smash away slowly but surely at my Haxe skills and code, here comes my simple but perhaps best polished (relatively, mind you) entry so far called Pogo Joe:

https://www.dropbox.com/s/p8187hlqgdek2zh/Pogo%20Joe.zip?dl=0

With each iteration the vision of where I should go with this codebase seems to get sharper. Its true that progress may not be speedy, but hey, that’s why 1GAM works out so well for a busy guy like myself. On top of that, it can be kind of like watching the silhouette of my dream project slowly coming into view.

What dream project, you may ask? I’d like to share an idea or two here in the near future, so stay tuned!

Ah, the entity-component system. It was like (supposedly) finding the silver bullet I’d been dreaming about with programming in a way. It was a system designed in such a way as to throw off the shackles of multiple inheritance pitfalls and warmly embrace flexibility. Admittedly, I even felt a bit guilty! I mean, a system that can easily conform to be whatever it needs to be? Pinch me; it seemed too good to be true.

Well, maybe it was, at least pertaining to my lofty ambitions.

Three months into #1GAM and I was still getting rattled with trying to find that flexibility ultimatum for my game engine. Just when I think I have it figured out, another scenario pops in my head. Is my system able to cleanly handle this? And then… well, you know, right? That analysis paralysis deal…

It certainly hasn’t been a waste. I’ve at least been DOING SOMETHING. I could have sat on my hands for the next year trying to envision the perfect game engine and the year after that getting ransacked by the illusions of my idealistic visions. If anything, the silver bullet doesn’t seem to exist, because game to game things are DIFFERENT. Trying to engineer pure, unhampered flexibility into anything can be an exercise in driving one’s self nuts.

So what does that mean? It certainly does NOT mean that my engine is a throw-away endeavor. The entity component system is still fantastic. Rather, I think it may be time to narrow my design philosophy. “Flexibility” may be a bit too broad in terms of a primary goal. Flexibility how? In what specifically? Focusing harder on a couple facets of flexibility will probably be a whole lot easier than trying to promise the moon. As to what those facets are… well, at least I’ve got nine months left to figure it out, huh?

Hey all.

What can I say? Basecode, basecode, basecode… I spent pretty much the first half of the month working on ironing out what I’d taken away from the first two months. Now I’m stuck on what is probably one of the last major core mechanics of my engine, but whatever. I’ll figure it out.

The engine also has a new name: Aurora. I so chose this to be consistent with the “light” theme (a photon is a particle of light, for those who don’t know,) and as an Aurora often is a blend of many different colors, I chose this to represent the intended flexibility of the engine.

So let me explain the basic foundations of the engine. Very consistently with general ECS methodology, there are three main class types that form the backbone of the Aurora engine:

• Components (which when taken in groups are technically entities)
• Systems
• Nodes

Components represent data, systems represent logic, and nodes represent the passing of or associating of data to the system logic.

Now, beyond this basic setup, the door was kind of open for me to do what I wanted. How do I manage nodes? How do entities communicate with each other? How do I dictate the order in which systems run? Docs I’d read on ECS didn’t necessarily cover these things. I wanted to keep the engine simple. Introducing too many new “core” types into the foray could complicate things unnecessarily. I ultimately did add types, but they all revolve around or are based upon the three core types. In short, nothing else should usurp what the core types are meant to do:

• Components (store entity data)
• Systems (perform frame-by-frame updates on entity data)
• Nodes (associate related entity data through components with systems/other entity data)

Once these purposes were established, I then started tackling other areas:

• Streamlining entity and component generation
• Entity-to-entity communication/system manipulation
• System execution ordering
• “One-shot” immediate executions (is not and should not be deferred in the system pipeline)

For instance, I rigged a special child class of the System called a Connector, extended slightly to handle system logic that worked on multiple entities. This was assimilated into the system architecture so both could co-exist as systems in the execution pipeline. I’m still figuring out some of these, but for now things are progressing all right.

So that’s what I’ve got for right now as a brief overview of the engine. Feel free to ask questions if you’re interested!

RPG’s have certainly bled into all manner of game genres over the last decade and it has produced some interesting results. Whether it be completing an arena challenge or finishing a race, its not surprising to see these events tagged with EXP point value to them, based in proportion to the level of achievement. This often means even battling grunts or finishing last in a race still gives you some consolation EXP. But as I’ve played games like this, the age old problem being sounded by RPG enthusiasts for years comes to light.

And as I’ve thought about it, I’ve come to the conclusion that the traditional RPG is a rather dramatically flawed system.

The age old problem? Grinding, of course: the act of repeating the same, mundane, sometimes low-level tasks over and over again in an attempt to drive up your level. Its nothing new. That’s why trying to find or orchestrate balanced RPG mechanics can be so difficult. But its difficult because at the heart of the old system, its not really feasible.

Why? Observe the low-level killer ladybug and the high-level lightning dragon. The ladybug gives you 10 EXP point while the dragon gives you 10000 EXP. That’s a rather significant difference, with the obvious catch being that the dragon is much stronger and deadlier over its ladybug accomplice. Taking things at simple face value, this makes sense.

But a deeper dive reveals a problem. Namely:

1000 Ladybug EXP Gains = 1 Dragon EXP Gain

Again, nothing new. That’s the whole dilemna behind grinding. But the whole idea behind “balance” is that its just not as much fun to go on a ladybug killing marathon as opposed to fighting the big bad dragon. But its still there, silently sitting in the corner with its seductive eyes boring into you. And so its totally possible in some circumstances to reach level 100 under the guise of “Ladybug Master Slayer.”

Many of us may consider grinding a problem, but WHY is it a problem? That’s the point I’m trying to make: traditional EXP progression, more or less, is based on the quantity of what you do as opposed to the quality. It doesn’t matter if you hammered it out over ladybugs, dragons, saber-tooth tigers, four-armed robots… max level is max level, and it can be represented by X number of EXP points. It doesn’t matter where you got them. It basically says if you beat your head against the wall enough of times, you’ll get good at whatever it is you’re trying to do even with meager amounts of effort.

Contrast this with other games and you can see what I mean. Completing a platformer level 10% of the way 10 times does not constitute you beating the level. Earning three bronze medals in a race is not the same as earning a single gold medal. Yet in RPG’s it often boils down to whether or not you are willing to sink the time into whatever it is your doing. Skill can become irrelevant in the face of persistence. Not all RPG’s are guilty of this obviously and some do a better job of exposing the “fakes” than others (particularly multiplayer games where your competition is human,) but the problem still remains that the shiny “max level” achievement that everyone wants so badly isn’t necessarily a true reflection of achievement; it may mean nothing more than you played the game. A lot.

The flipside of all this is that the true acts of valor and skill are essentially lumped into the same category as the ladybug slayer. You reached gold level by besting the four mighty beasts of the world’s corners? And yet the game would’ve clapped its hands for you in the same way had you just sat in the field playing whack-a-mole with lesser ground burrowers until the cows came home. We don’t have to, but sometimes the option alone is insult enough to the player’s ability. There’s a big difference between fighting hard against a game and fighting to make a game hard.

I’m not saying we should do away with the traditional EXP point system altogether. It has worked before with its warts, and what game mechanic doesn’t? What I’m saying is that I’d like to see more distinct value placed on the actions done and less assignment of arbitrary values on a universal scale. Instead of all monsters blindly contributing to the same EXP pool without regard to the diversities of each, have them give distinct rewards or distinct stat boosts to their related strengths. Attacking ice monsters makes you more proficient against ice, destroying armored foes makes you a better defense piercer, and so on and so forth. One idea I’ve considered is objective-based leveling, where you level up, gain experience, etc. by completing specific tasks. Some of these ideas exist in some form alongside the traditional EXP system, but I’d like to see them take center stage much more prominently. Reward the players accordingly for their efforts instead of just throwing another blob of amorphous EXP points at them.

No doubt such systems would come with their own set of design challenges. But at least the dragons might feel less insulted from being equated in value to an army of ladybugs and moles.

Well, it didn’t turn out as splendidly as I had originally envisioned, but I’m still in the fight. For those interested in my simplistic game for this month’s #1GAM:

https://www.dropbox.com/s/27i194x1w2uib8n/Bad%20Squares.zip?dl=0

Seriously, I’m still pretty happy though. If its taken me this long to straighten out my basecode (and its not done yet!) then its a good thing I got started on it.

So what’s the plan for this month?

• Keep refining the basecode; hopefully it may even be ready for some heavier lifting for April’s Ludum Dare.
• On the same note, figure out how to display text in Haxe. It may not be difficult, I just haven’t really tried it yet.
• Figure out why the windows .exe builds appear to run at a lower framerate. Its runs fine but it looks just a touch choppier. I’m not sure if its some internal setting I’m missing or what, but its kind of annoying. Furthermore, if its a problem with my code, it should be fixed (but Flash builds being faster than Windows builds?)
• Set up a proper debug environment. I can sort of debug but its not really rigged to FlashDevelop. Again, another thing I more or less may just need to take an hour or two to figure out.

Month three is here. Let’s go!