• entries
    436
  • comments
    1179
  • views
    763988

evo's Game Jam and thoughts on organization

Sign in to follow this  

1077 views

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:
0rNdYxC.jpg
Sign in to follow this  


5 Comments


Recommended Comments

Yep, Diablo 2, BEST GAME EVER!
I guess you know this article, but if not, check it out: Postmortem: Blizzard's Diablo II

I can easily relate to your first argument. Back when I was a teenager, 3D S Max was my thing, and those who made game art were the kings & queens. Later, I realized, that I'm not hard-working (nor talented) enough for becoming an artist, and got interested in- and started to enjoy- programming. When time came to select a field, compared to art I kicked ass in programming, enjoyed it and knew what I was doing, so that became the natural choice.
Still, as of today, art amazes me, both consuming and ~practicing~, and I take it as a fact, that most (if not all) people gets sucked in by atmosphere and looks into a game, for which good or characteristic art is inevitable. Most famous indie games too deliver in this regard, as big budget is not a requirement for achieving it...

Though, as a counter argument to yours, I find it much harder working on any kind of graphic asset beforehand having something playable and structured. Once a game has it's shell and plot it feels easier to "coat" it or to find it's own aesthetic more tightly coupled with it's mechanics (at least to me). Until I get the real feeling of the interactive parts, I find it hard to make real working art fitting the game, even if I had HUUUGE ideas about the looks; they work much better as only a figment of my imagination, than real bitmaps biggrin.png.

Maybe more talented ones, with larger artistic vein can give ideas or tell their experiences better in this situation...

*
 

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?


That is some cold-hearted brutal game design, and I guess, this is why common veterans warn beginners against RPG-s. Besides the ridiculous amount of content, painstaking attention to design, and thus the programming of umpteen rules are required.

Br, good luck and keep up, GC is looking better than ever (loved it's look and setting even in pre-rendered days ;))!

P.S.: cool pic from the past:

kqRu3.jpg

Share this comment


Link to comment

I empathize with you, also being in that period of trying to settle into the final formats, and figuring out how the logic accesses all the various data. I've rewritten my asset management stuff at least four times during this project, and am currently thinking through if and how to restructure my map data.

Share this comment


Link to comment
I believe his advice on using horrid artwork all the way is advice for game jam like efforts. And I think that's solid advice. Most developers completely lack artistic skills, and as such it takes us too much time to crank out pretty assets. We might be able to take enough time for two to three stabs at code for a game jam. But if we waste any time on going down the wrong path with art, we're pretty much screwed. smile.png

Share this comment


Link to comment

Using bad artwork might make it easier to recruit artists; "I can make better artwork than that!" - less pressure, potentially making it easier for them to join.

 

 

Another potential benefit of using horrid artwork and no background music is for motivation. As a programmer, most of my work is non-visual (usually I'm working on the 90% of the iceberg that's underwater). Anytime changes actually bubble up to the top, it's real motivating. By saving easy-to-do visual changes like swapping out a GUI texture or adding in a background song, maybe those could be held back for days when you're not feeling motivated in the project and need a boost of optimism. Maybe that might help with team projects, too - motivating the entire team.

 

A third potential reason is to give followers/viewers/managers/publishers/outsiders a visual cue of how far along the project is. By gradually replacing bad art with good art, it can give outsiders the indication that you are getting closer to release. Imagine mocking up your UI, but having all the unimplemented features grayed out with sloppy programmer-art icons. Then, as each feature is implemented, it gets a full-color nicely designed icon.

Share this comment


Link to comment
I agree with the sentiment. For a game my size, it was perfectly acceptable to look horrible whilst I got the mechanics working. If I were to rephrase myself, I'd say "focus on playability, using enough art to allow you do this". It's a subtle difference but it makes a solid point. On bigger a project using bad art may disguise a bunch of work needed and force you into a bad place later on. For example, you may not bother with your pipelines until too late, by which time you get slowed down dramatically when it matters. Also, it can be hard to sell your idea to others if it's terrible to look at. Servant of The Lord expresses it well in his post. On a bigger project I'd make art goals, so have it awful during initial dev, then incrementally improve it as you improve the game. I've seen (and worked on) projects which look amazing early on but have little playability most of their life. Polish too soon and it can hurt you, as can polishing too late. I guess it's all about pragmatism. Plus your own tolerance for looking at something bad all day ;)

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now