New project, Code 9, on Steam Greenlight!

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 :

Posted in Uncategorized

I’ve moved!

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!

Posted in Uncategorized

The Bane of Over-Engineering

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!

Posted in Uncategorized

What’s this? Ludum Dare 32!

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:

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!

Posted in Uncategorized

March 1GAM Entry!

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:

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!

Posted in Uncategorized

One Size Rarely Fits All

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?

Posted in Uncategorized

1GAM Update 3/15/15

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!

Posted in Uncategorized