Its been a about 3.5 years now since I made the decision to “just make games” (that counts time before I started blogging) instead of waiting for the perfect time to get adventurous. It was a good decision; I’m busier now that I’ve ever been but I’ve slowly but surely pushed myself. I finally made public releases, participated in jams, and most recently even started working on my own personal framework in Haxe with OpenFL. Being busier, arguably, has made me more disciplined in my time usage (more time != more productivity, FYI.) Sure, I haven’t rocked the world with anything insane… yet. But I’m farther along now than I was 3.5 years ago, easily.

Its been good. Things have been up and things have been down. But one thing that hasn’t seen much attention as of late: this blog.

Honestly, a lot of my major game dev achievements up to this point have come in stints. I’ll participate in a jam or contest and you’ll see a little bit from me here and there. But I don’t feel like that’s good enough anymore. And now that I’m trying to pull together multiple years of fragmented experience into the #1GAM experience, now seems to be a better time than ever to infuse some new energy into this blog.

I’m saying I think its time to re-haul the blog.

Its easy to develop on an island. After all, a lot of “ugly” stuff goes on behind the computer screen as you try to clean up haphazard code or struggle with character art that looks like a vacuum cleaner holding a banana. But this kind of vulnerability may be more of what people should see. The game dev life isn’t all flowers and chocolate, and if I sit in my coder cave and only come out when I have a finished product… well, the world may have another game and I hope to produce stuff that really does make an impact, but there’s a whole window of opportunity I’m missing for one of the things I want to do: to reach out and help people through my coding and game dev. Even if its just a blog post detailing my struggles for the week, maybe it’ll at least console someone that their problems aren’t unique.

I have to make some decisions on how to reorganize this thing but as I wrap up this month’s #1GAM endeavor I plan to fire this bad boy up again. It may still take awhile to beat things into shape, but I’ve already been sloshing through this stuff for over three years, so why stop now? Its incredible to think about how long its been, actually, and perhaps even more so to think about where I’d be had I not started when I did. But we all have to start somewhere.

So get ready. Get ready for quick drive-by looks at half put-together projects. Get ready for code snippets resembling hieroglyphics. Get ready for whatever, whenever, wherever.

Get ready. 🙂

Hey all! I completed my first game for #1GAM. It didn’t go quite as planned but the experience with my new ECS-based engine was definitely worth it. Looking forward to the next project!

Here’s the game if you feel so inclined to play: https://www.dropbox.com/s/ctlsim4i5ptaztd/1GAM%20Jan.zip?dl=0

Well, I made the decision. This is the year I finally make a serious attempt at 1GAM. Can I pull off 12 games in 12 months? Who knows, but BRING IT ON.

My plan is to keep a TIGSource devlog on the year-long journey, and that is where most of my posts relating to this will probably end up. If you want the full lowdown on what I’m up to, cruise on over to the devlog.

And keep an eye out here for any major updates such as finished games. For now, check out the nitty-gritty at the link above. Until next time!

Hope everyone had a Merry Christmas!

In my last post, I mentioned something about logging my programming time. I’d like to expound on that a bit more.

I’ve only been doing it for a little under two weeks, but basically I have some priorities (like Flux) that I am tracking the time for on a calendar. I am carving out discrete amounts of time to work on things and then putting the time spent on the calendar via colored sticker, where the color represents the priority worked on. I’ve made some interesting, personal observations thus far on the usage of this method:

1. Measuring your own consistency and discipline is less nebulous. You can see as you go through the week and month where your time is being spent and on what. Its not a “I did some work off and on throughout the month” but a “I spent X minutes working on priority Y.” Its a much better measurement to work off of when it comes to adjusting your schedule and gauging productivity.
2. Time becomes better spent all around. Sometimes, I would just kind of dabble here and there on this or that. Now, I’m trying to spend a continuous block of time working on a certain thing. So now instead of sporadic ten minutes sessions that just kind of poke and prod at the problems, I’ve had better focused thirty or more minute sessions actually being productive. Plus, who wants to put a five minute sticker on the calendar? C’mon.
3. Analysis Paralysis STINKS. Seriously, there was one project that I didn’t really work on for three days because I was mulling over how to implement something. I can see that on my calendar now. Momentum can then end up getting sheered and it can be harder to actually get the motor running again. Now that I’m tracking things, hopefully I can see the warning signs more clearly and power through when the need arises.

In short, accountability (if only to a calendar) and structure are very good! Hopefully this will continue to help me along.

The ginormous engine rewrite has been underway from the LD31 experience. Currently, my ECS is going by the name “Flux,” a name that is meant to reference the transformative nature of game objects and ECS in general.

As part of getting things in order, I’ve added two of my own object types into my engine. Beyond the traditional entities, systems, components, and (for some implementations) nodes, I’ve got these two:

• Hub: Hubs are for managing game flow, namely ordering system execution. You could call them system-management systems, perhaps. Basically, I group systems together based on function and order of execution and the hub is responsible for running updates on all the systems under its responsibility. Hubs can also contain logic to dictate which systems run and which don’t on a particular pass.
• Role: Roles are for expanding entities. When you make a new role object and give it an entity (id,) the role will initialize (empty) components and assign them to the entity’s component map. The role itself is an object, so after automating standard component dirty work, they retain local references to the components they just initialized so the calling code can actually assign data. They can also switch targets and consequently initialize and assign fresh sets of components to multiple entities. Finally, they provide a great way to group components that are associated by a common functionality.

I went through an iteration or two of “new types”, but these are what have emerged. So far, I think they help out general structure without convoluting the paradigm too hard.

Things are still early though. My plan is to do something simple like a checkers game to test things out and see how it goes. It shouldn’t be too involved and it’ll give me a good opportunity to keep refining the engine design as it needs it. I’ve started logging my programming time too, so I can get a grip on a more disciplined programming schedule. So things are moving!

Thanks for reading!

The game-making period for LD31 has drawn to a close. And the results?

Well, unfortunately, I didn’t quite make it. The major change in my development approach really slowed me down. Its disappointing for sure, as Ludum Dare really is something special when it comes to the community and the feedback afterwards.

Nonetheless, I was able to take a lot away from this Ludum Dare, and I don’t consider it a total failure by any means. Let’s break it down:

• Base Code: Oh wow. Yes, have good base code. Now, in my defense, I’d spent a good week or so prior hashing through the basics of the entity-component system and making sure I could at least do simple things like get a graphic on screen, move it, and play sounds. But in the end, I was still firing way too much from the hip. Combine that with my relative lack of inexperience with OpenFL and it meant getting through even simple tasks could chew up time. Had I not had the base code I did have, I would have been sunk probably right out of the gate. So now I’m taking away a lot of ideas for what I can do to polish my WIP engine up and get ready for next time.
• Paradigm Switch: Oh wow again. When you switch from object-oriented practices to more data-driven practices, it can be a bit jarring. Again, I got slowed down as simple tasks were no longer encapsulated in single objects but managed by multiple objects. Since I didn’t have much in the way of base code and I’m not supposed to use member functions as adamantly, it sometimes meant I was writing more code and the same code more than I wanted to. This will hopefully also be covered in my engine polish, so that I can still keep things neat without heavy encapsulation.
• Momentum: I did have other things going on over the weekend. But this combined with basic functionality taking longer-than-ideal times meant building any sustainable momentum was tough even when working over longer spans. It meant breaks became more appealing and I ended up having trouble garnering motivation. So for the sake of momentum, taking even more time to wrap my head around the other two things above is crucial.
• Experiencing Something New: I used to think people were mildly crazy when they would say things like “I’m going to try learning a new engine/language over Ludum Dare.” O_o. And guess what? I’m not convinced that its NOT crazy to some degree. But if anything, it exposes you to new ideas and ways of doing things. Being able to walk away with a little more experience and familiarity with my new toys and use it to get stronger is so big. So I get the appeal now. Be crazy people. Try something new. Just be prepared for increased mayhem over the weekend!

So there’s my LD31 experience in a nutshell. Hopefully you found it helpful for yourself in some way. Thanks for reading, and hopefully we’ll be right back at it for LD32!

Been over a day now since things kicked off so I think its appropriate I give an update.

Yesterday involved a bit of indecisiveness and concern. Having not really dived into a hard-coded game project in awhile, it started pretty slow. My base code was far enough along that I wasn’t sloshing through super basic stuff but it was still pretty generic nonetheless. Plus, when you switch from one programming paradigm to another, it can REALLY jar you. All that being said, I’ve taken some notes about what I want to change with my new “engine” moving forward, and I already feel like I’ve learned a lot. I can expound more in a later post.

I did consider going back to using a game development tool; I really want to finish the game idea I have, and its simple enough. I toyed with the idea and even replicated most of my work for the day in my previous tool of choice in probably close to 30 minutes. Yeah…

But then I considered I was taking the easy way out. It’s not just about finishing the game but about growing as a game developer. If I bail on my current aspirations because its too hard, how far will I get that way? The tool in question wasn’t a bad choice by any stretch, but it was dodging a primary objective of participating in the jam. So I’m sticking it out with my new base code…

Don’t have a whole lot to show on the game, but I’m aiming for the jam (72-hour) and things are starting to click on the faster gears (I hope?) Not giving up, and for those others of you participating, hopefully you’re staying at it too!

The theme this year is “Entire Game on One Screen.”

http://ludumdare.com/compo/

Gotta keep it interesting, don’t they?

I wanna come up with something that’s not simply on one screen to be on one screen, but something that makes sense/thrives because its on one screen. Here are some of my concepts/ideas:

– A game mechanic involving a magnifying glass
– Claustrophobia as a game mechanic
– A polymorphic game mechanic (i.e. level parts rearrange themselves to make new levels)
– A game mechanic where you have to delegate/prioritize screen space to different elements/tasks

Well, let’s see what I can come up with…

Three days in a row! How about that! But tomorrow’s the dreaded Monday, so… anyway, I’m actually gonna keep this brief because… yeah, tomorrow’s Monday, so…

Today I realized that I didn’t have proper runtime debugging set up; that’s a pretty big no-no. I poked around with FlashDevelop some but ended up being able to at least get things running by selecting my built .swf and opening it with the Debug Flash Player. I have a feeling FlashDevelop has a more elegant way of doing it but for now the process is only slightly more painful with just a few clicks. It’ll do.

On a more positive note, I made another interesting realization about something you can do with an ECS: just how useful “delayed” system functionality is. In an ECS, systems typically run in a linear fashion, ordered by the priority they have. Makes sense: you wouldn’t update the sprite positioning system before updating the physics system first, right?

Sometimes you may know you want to do something based on the conditionals you just checked but you haven’t yet derived all the data necessary to do it. In object-oriented programming, this could cause you grief. Calling a member function that immediately calculates things won’t do if the data isn’t ready. You could set flags or something, and that definitely can work, but…

When you work with systems under the right circumstances, so long as the proper components are initialized (they exist but don’t necessarily have filled data fields,) you can forward them to the systems anyway; just make sure their fields get filled before that system gets reached in the execution order. It something so simple, yet so profoundly incredible (to me, at least!) And its a near seamless perk that comes with working with the ECS. Just queue it up and keep firing through code.

So there’s a nugget of information for you. Well, Monday is approaching (and Ludum Dare is on the horizon too,) so time to jet. Later.

(Please excuse the poor code formatting; WordPress acts a little funny about spacing.)

Last time, I gave a brief, non-exhaustive intro on what an ECS was, and also talked a little bit about pros and cons.

One thing I didn’t discuss was nodes. Nodes are containers specifically for components needed by a system. For instance, a PositionUpdateSystem class could have a PositionUpdateNode class associated with it for holding position and sprite related components. Something simple like this:

class PositionUpdateNode
{
public var position:PositionComponent;
public var speed:SpeedComponent;
}

One thing that struck me about this though is that this can lead to some stacked memory references when writing system logic that uses these nodes:

for (var:node in system_nodes)
{
node.position.x += node.speed.x;
node.position.y += node.speed.y;
}

Maybe this isn’t a big deal to some, but I personally don’t like these kind of multi-layered reference calls (yeah, its only three layers, but still.) They look kind of ugly and they can hurt readability. And this is just a simple example. This of course can be the price you pay when you choose to manipulate data directly as opposed to local member functions.

Why not just a few member functions on those components then? No. Although I’m not an ECS purist, the data/logic separation is a key facet of the ECS for good reason (at most so far, I’ve used simple constructors for setting up more complex data items that need initialization.) The more you attach to a component, the more that gets passed around and the more strain you can have on memory. Systems should be able to quickly and cleanly cycle through its list of nodes/components on standby. For smaller games it’s probably not such a big deal, but I don’t want to start any inefficiencies now.

So what to do? Just live with it? Well, I wasn’t quite content. Efficiency AND readability are important in their own right. I could do something like use temporary variables:

var i = node.image;
var p = node.position;

i.x = p.x;
i.y = p.y;

But this is also kind of shoddy and, frankly, may not help readability (or efficiency) all that much either. So how do we get clean code and still keep our data-oriented approach?

After some looking in Haxe, I found my solution: static extensions.

Think of static extensions as member functions that aren’t actually attached to the class themselves. What? Yes, you heard me. Consider the following:

class PositionManipulator
{
public static function move_by(comp:PositionComponent, d_x:Int, d_y:Int):Void
{
comp.x += d_x;
comp.y += d_y;
}
}

In and of itself its just a class with a static function, but if you utilize it as a static extension with the “using” keyword, now I can transform our original code into this:

using PositionManipulator;

for (var:node in system_nodes)
{
node.position.move_by(node.speed.x, node.speed.y);
}


I won’t go into all the details (click the link I provided instead,) but basically invoking the static extension causes its functions to attach themselves to the type that matches their first parameter. In reality, the call is transformed back into the static function call later, but for now its presented in a much more readable format. Of course, we still have the multi-layered speed references; we could clean that up to in some way, but for now I think it already looks better.

Now isn’t that easier on the eyes? That’s what I got for you today. More to come, but until then, keep trucking away on the code, games, and all that good stuff.