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.

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.

These last two months of effort for #1GAM have ultimately ended up being a lot of basecode building, but boy I’d like to think it is going to help in the long run. I’m already looking to put out another pretty low-key game this month, but beneath the surface things are getting in shape.

One of the things I was trying to figure out this month is how to unify game pieces in a way that facilitates seamless communication and interaction. More types of components means a greater amount of systems and/or more specialized code. Though some of this is probably a given, one of the beauties of the ECS is being able to streamline common code through systems. Having to write new systems for every edge case sort of defeats the purpose in my mind.

When the solution finally came to me it seemed kind of silly I hadn’t thought of it before. What I decided to do was define a set of low-level, baseline components that would function as “output” components for commonly passed data types (numbers, booleans, etc.)

Let’s take input for instance. You have mouses, controllers, keyboards, etc. Each of these carry their own set of nuances. Now the initial idea might be to manage these from separate input classes and have getter functions for each’s respective input. But now try to hook these up to an entity. If you want an entity to be compatible with all three types of input, you might need to write three different systems, and so help someone should they try to combine different forms of input into the same control scheme. Its not impossible, but it can complicate things.

So my solution was two steps. First, all these “inputs” were not to be specialized classes: they should be entities themselves. By making them entities, we put them on the same level as our other game objects, able to use the same kind of methods to store and manipulate data. That brings us to the second step: they are then each assigned something like a common “BooleanComp” meant for output. Entities who wish to read these inputs look at these components to determine their course of action. Internally these input forms must still be handled based on what they are, but the idea was that system code could focus more on manipulating output as opposed to how it was derived in the first place.

But wait! You might be thinking that a keyboard has multiple buttons but only can have one “BooleanComp” in its component map. How does that work out? Simple: the keyboard itself is made up of multiple button entities. But how does this not muddy our output process? Well, entities still have to know what they are looking for, but in this example once they find said input, theoretically they all plug in nicely to the same code because they all share the same form of output.

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.

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!

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:

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.

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.

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.