So, evolutional recently challenged himself with his own personal game jam. In the process he created a simple clone of an existing game, 2048. He used the opportunity to work the rust out of some disused skills and learned a few lessons along the way. I've engaged in this kind of personal, on-my-own jam-style project before, and I understand how it can be a very good thing for invigorating the thought processes and firing the imagination. It's good to see him getting back into the swing of things.

I have one minor quibble with his takeaway lessons, however:

[quote]
Iterate quickly to playable, with horrid art all the way[/quote]
Perhaps it's simply the under-developed artist in me (I painted and drew LONG before I ever learned to code, even if I did let such skills lapse in the intervening years), but I simply can not work on a project for any length of time without spending at least a few hours with Blender open trying to make something that I can stand to look at. A lot of it is motivation: if the game looks good as I'm working on it, I'm more inclined to keep working on it, if for no other reason than I can post some screenshots and bask in the adulation of one or two random people on the internet. But the biggest part of it, for me, is that I really, really have to have an understanding of what will be involved in the asset creation process, so that I might better judge if it's a thing that I can stick with.

You see, though I once upon a time considered myself an artist, I'm painfully aware of my own weaknesses and shortcomings. I simply have not exercised those muscles sufficiently. The art that I create is done haphazardly, and with mixed success. The result of this is that it is easy for me to take on a particular vision for a project, get so far along with it, then realize that I either lack the skill or the time to create graphical assets in the manner required. Since much of the early groundwork of a game, for me, is tightly integrated with developing the "look and feel" of the game, it is important to discover whether or not it is too much before I am too deeply invested in it.

Much of my early inspiration came from games like Diablo and, especially, Diablo 2. I love the isometric look and feel (as you might know by now, if you have read my journal for the past several years). However, even given that D2 is a game from an older and simpler era, still the graphics for that game are phenomenally detailed. (Again, taking into consideration the era.) Tiles with detail: grit, dirt, dust, rocks, blood stains, smears, smudges, clumps, clods... Walls with carvings, etchings, protrusions, more dirt, more grit, more blood stains. Seriously, take a look at it (or at some screenshots) some time. It's a lovely game.

The graphics for D2 were modeled (using tools that are rough in comparison to what we have today) in 3D and pre-rendered, then processed to fit the 256-color specialized palettes developed for each Act. Look at the tiles for the town of Lut Gholein, with the various vendor stalls made of wood and hide, the palace, the sewers grate. Look at Act 5. Look at the bricks and stones and statues and carvings. The details. The advantage of doing the traditional 2D isometric look was that the artists could create scenes and tiles of phenomenal detail, and bake it down to simple, easy-to-draw bitmaps.

Such a process is only made worthwhile, in this day and age, if your tiles are of sufficient complexity that it would be otherwise unsuitable to try to render them in real-time, as 3D models/sub-scenes. If they are not that complex, there is no real reason to go with the traditional 2D format. Just render them as 3D. But if they ARE that complex... well, then, creating them can take a whole lot of painstaking work, work that a developer may or may not be capable of. And THAT is what you need to determine early-on: whether or not you are capable of the task you set yourself.

Not only are the tile scenes in a pre-rendered isometric likely to be complex and detailed, but they must also adhere to particular rules if they are to be used in randomly generating levels. Tile pieces must align with other tile pieces, with an eye toward eliminating the appearance of obvious repetition. You must cram sufficient appropriate detail into these tiles to evoke the theme, mood and appearance of the environment you are modeling. I have spent years working on techniques to accomplish this, and let me tell you that it just ain't easy. And it can be a painful lesson to learn if you have already spent weeks or months building the Killer Isometric Engine of your dreams, only to discover that the best you can do are some smeary, blurry hand-drawn images of a wall. In such an instance, I believe that you would probably be better off going with a simpler true 3D theme, something low-poly and more easily managed, undoing all your weeks of hard work on the isometric engine.

*

I've gotten to a point where a large part of the task looming before me in completing Goblinson Crusoe is the matter of data organization. I've obviously been attempting to tackle an RPG, something that it is common for veterans to warn beginners against due to the sheer amount of work involved. A lot of that work is organizational: how is your data represented, how is it stored and loaded, where do the various bits and pieces belong? At some point, you end up with a framework that has been consuming a lot of test data and that (you hope) seems to work fairly well. But you just don't know how well it works until you start formalizing your structure. And that's when the faults and cracks and mistakes manifest themselves. When you start building tables, and those tables require hacks and workarounds that force you back to the design table to rework some component or other.

That's where I am right now. How are the spell lists structured? Does a spell-cast accept parameters, or are the parameters queried at the time of casting? How are buffs/debuffs and equipment stat modifications represented? How are spell effects presented in the combat log? Where do enemy definitions live? How are structures and buildings organized? What does the talent tree look like? How is it structured?

There is just a lot of data to be handled in even the simplest of RPGs, and getting a grip on it all can be quite daunting.

Today, I've been trying to bring order to the spell list system. I've settled on a master list of spells, concentrated in the allspells table, and further categorized by type: combat, healing, building, buff/debuff. But I am working on a more sophisticated system that allows me to tag each individual skill with various meta-data that enemy AI can use in making decisions based on the skill loadout they are given. For instance, if a skill is tagged 'damage' and 'aoe', the enemy needs to act accordingly; given that friendly fire is a risk in the game, the enemy should try to wisely target the spell so as to maximize the damage against the player's units, and minimize the damage against the mob's buddies. Similarly, if a spell is tagged 'healing' and 'aoe', the enemy should try to avoid healing the player's units by mistake.

A part of the difficulty of this organizational process is that mistakes might not become obvious until you have already written or converted a LOT of data, forcing you to spend time re-converting or re-writing it all. But you can't always sit on test data forever; at some point, you have to start writing the official stuff that people will actually play. The risk must be managed, and really, only painful experience can teach you how to manage it all. I'm currently in the "painful experience" part of the cycle. I'll let you know how it goes. In the meantime, here is a shot of GC accidentally healing his enemy: