Finished the new generic isometric unit renderer. Mech is composed of up to 13 individual layers at current, and rendered in proper order depending upon facing direction.

Light day, RSI is flaring up again it seems.. But I managed to finish all the Lua stuff, and super basic support for defining items and their graphic IDs. So I can finally start work on the new unit rendering code.

Yeah, that makes sense. Though Project Zomboid did some interesting stuff with making 3D renderings look like pixel art. Real pixel art (like yours) still looks better though.

Hehe cheers! I guess one thing that also helps to set it apart is that none of our art is upscaled. Its all 1:1 pixel at current, unlike what a lot of pixel art games do lately where they target a low resolution and upscale like crazy.

This link also provides some decent insight into various game software patterns. http://gameprogrammingpatterns.com/

Makes a lot of sense, but you could still blog or post about development progress

I talked about it a bit in my DevLog: http://forums.tigsource.com/index.php?topic=14419.msg935394#msg935394 (Don't want to hijack your thread!)

With regards to making sprites, I imagine it's even tougher when making pixel art like you've got in your game. I use Poser to generate the characters in my game and can automate a great deal of it. I'd have gone insane if I had to draw each sprite individually. But I guess there are ways to optimize that as well? Scaling and rotating pixel sprites and stuff?

Its all done by hand, otherwise it wouldn't really be much in the spirit of pixel art

I suppose if we really wanted to try an optimize it, the best way would be to model everything in a 3D program, export it as images, and then pixel art over the exported frames. However, at that point we would probably just drop pixel art, and have made it with a 3D engine.

It's going great. I just decided to dev in the dark until I'm out of pre-alpha.

Nice any particular reasons for that?

Make more games, you'll get better at this with experience. Also its not worth over engineering it for small games really.

I mean basically every unit is constructed out of X possible parts which are visually represented. As such every part has to also be fully animated in every animation the unit will have. This is why just a walking animation on a mech, with a few options comes out to 180 frames for a single direction.

I feel your pain. I'm currently at ~40,000 sprites for the character animations in my game.

ARGH!! Yeah.. hows that going anyways? I haven't seen any updates on it in a long time I don't think. (Pretty sure the blog is RSS subbed to)

Continued dev, added in more support for proper animations now, including frame timings. Started up a wiki to document all of this junk Kawe is starting on attack animations to go to all the weapon configs we now have available.

Yeah if you just want to make a game, don't care about making your own engines/frameworks, or understanding a lot of what is really going on, than most anything can work assuming you also are using the right tools/frameworks/engines.

Continued to work on the whole unit definition and layering bit. Coded the Lua bindings for slots, render orders, and animations.

A complex unit definition is starting to come together as something like this:

Code:

RegisterUnitTemplete(1, "hvymech_sheet", 10);

-- slot defines

local ARM_RIGHT, ARM_LEFT, SHOULDER_LEFT, SHOULDER_RIGHT, SHOULDER_TOP_LEFT, SHOULDER_TOP_RIGHT,
SHOULDER_FRONT_LEFT, SHOULDER_FRONT_RIGHT, TORSO, CROTCH, TORSO_TOP,
LEG_LEFT, LEG_RIGHT = 0,1,2,3,4,5,6,7,8,9,10,11,12;

items = {0};

AddSlotToUnitTemplate(1, 0, ARM_RIGHT, 1, items);
AddSlotToUnitTemplate(1, 1, TORSO_TOP, 0, items);
AddSlotToUnitTemplate(1, 2, SHOULDER_TOP_RIGHT, 0, items);
AddSlotToUnitTemplate(1, 3, SHOULDER_FRONT_RIGHT, 0, items);
AddSlotToUnitTemplate(1, 4, SHOULDER_RIGHT, 1, items);
AddSlotToUnitTemplate(1, 5, LEG_RIGHT, 1, items);
AddSlotToUnitTemplate(1, 6, TORSO, 1, items);
AddSlotToUnitTemplate(1, 7, CROTCH, 1, items);
AddSlotToUnitTemplate(1, 8, SHOULDER_TOP_LEFT, 0, items);
AddSlotToUnitTemplate(1, 9, SHOULDER_FRONT_LEFT, 0, items);
AddSlotToUnitTemplate(1, 10, SHOULDER_LEFT, 1, items);
AddSlotToUnitTemplate(1, 11, LEG_LEFT, 1, items);
AddSlotToUnitTemplate(1, 12, ARM_LEFT, 1, items);

-- render orders

local ISO_NORTHEAST,ISO_SOUTHEAST,ISO_SOUTHWEST,ISO_NORTHWEST = 2,0,3,1;

AddRenderOrderToUnitTemplate(1, ISO_SOUTHEAST, {12,11,10,9,8,7,6,5,4,3,2,1,0});
AddRenderOrderToUnitTemplate(1, ISO_NORTHWEST, {0,1,2,3,4,5,6,7,8,9,10,11,12});

-- Animations

Although items would be defined in much more detail, and per slot. Some of this could likewise use a few more passes, but I'm becoming fairly happy with it for a first cut.

I'm able to rent a 2 bedroom house, with a large fenced yard, and garage for around 570 a month.

I'm paying this for a 2-rooms flat in a poor district... 

The house is probably about equivalent, old, no insulation, slum lordish landlord, and the lack of insulation causes the electric heat bills to be a bit high in the winter. Its far cheaper than my old 2k a month mortgage though.

Its certainly possible to live in cheaper areas in the US, although I do think 3rd world countries might be cheaper overall.

However, after moving out of expensive Portland, and out to rural Oregon, I'm able to rent a 2 bedroom house, with a large fenced yard, and garage for around 570 a month. (Utilities not included) I'm around a 4 hour drive to Seattle, and an 8 hour drive to SF. I'm pretty sure if I had moved to Texas or somewhere like Tennessee I could of reduced this cost further.

Tax wise Oregon doesn't have sales tax thankfully, but it does have state tax. If I could swing it I'd move to Vancouver, WA, as WA state has no state tax, and you can dip over to Oregon if you really want to buy things without sales tax.

C would be my recommendation. Much smaller than C++, very portable, will really teach you a good portion about memory, and will require you to write all your own data structures teaching you endless things.

Or maybe something like z80 assembly that would allow you to dev and play on a gameboy. Not portable at all really, but a very small instruction set, and it would teach you tons about comp architecture and so forth.

Of course both of these suggestions really are more oriented at learning computer science and hardware, vs just learning a language. If you have a good understanding of computer science fundamentals, algorithms, data structures, memory, and so forth most any language can be picked up fairly quickly.

Oh hey thanks! Thats quite cool.

I was just starting to write a variadic function to accept parameter types and do a big switch, but this seems great.

Just wondering if anyone knows any easier ways to validate arguments passed from Lua to C during a function call, other than simply checking for the number of parameters passed in, and then manually verifying each parameters type?

I'm getting a bit tired of doing something like this:

Code:

   int n = lua_gettop(state);
    
    if(n != 3)
    {
        LERROR << "Invalid number of arguments sent to lua_RegisterUnitTemplate";
        return 0;
    }
    
    if(lua_isnumber(state, 1) == false || lua_isstring(state, 2) == false || lua_isnumber(state, 3) == false)
    {
        LERROR << "Invalid argument types passed to lua_RegisterUnitTemplate";
        return 0;
    }

Oh well decided to end all the fussing about, and just start implementing stuff. Its minimum functionality just needed for the moment, which means I'll likely end up re-writing and expanding it 100x over, but it gets things moving.

Still defining units with Lua code, but its become a bit more expanded.

Essentially something like:
RegisterUnitTemplate(id, texture_name, etc)
AddSlotToUnitTemplate(id, slot_id, layer_number, requires_filled, items_accepted)
AddAnimationToUnitTemplate(id, anim_id, framecount)
AddRenderOrderToUnitTemplate(id, direction, order)
AddItemToUnitTemplate(id, slot_id, item_id)

But good luck with doing it all in 2D... To me it just seems like a huge amount of work for the sake of keeping things strictly 2D sprite based.

Thanks Konidias, your not wrong 3D would likely be much easier in areas, but that's not really what we're about

Congrats on the visuals! I've always loved isometric, especially when it's done in such beautiful detail as this.

Cheers! Glad you like it of the customization bit were doing approach B. I suppose my problems aren't really technical so much at the moment, but largely organizational and work flow based. There's just a ton of data that needs organized and figured out how to be defined and imported into the game.

Some of this is as simple as making sure every item has a unique id. and making sure layers in photoshop that are of that item match the id. This way things can export out as id_anim_direction_frame.png  but it means keeping track of all these IDs, keeping files in sync with art development and so forth.

A lot of it is because I don't want to code every item in the game, or unit. I want it all to be defined via data so its easy to tweak, mod, and expand. So like to render a unit I need a renderer that is happy to draw X variable layers in Y specific order and all of this layer and order data needs defined in nice ways and pushed into the engine.

I'm sure the pain will continue though even things like tiles really are likely to need data associated with each. Especially if trees, objects, and other terrain also end up destructible.

It sounds so complicated for something that looks so simple (no offense)

Yeah.. Maybe its just me? Dunno.

Its a somewhat complicated issue though I think.
 
I mean basically every unit is constructed out of X possible parts which are visually represented. As such every part has to also be fully animated in every animation the unit will have. This is why just a walking animation on a mech, with a few options comes out to 180 frames for a single direction.

Now thats just for a 10 frame walk animation, figure an attack animation per weapon, being hit animations, idle animation, death animation, and likely quite a few more. Anyways it results in a single customizable mech basically having likely a couple thousand frames once you figure in all the directions.

Likewise every part is really an item, which can only be possibly applied to certain slots in the unit frame. Each item/part also has to be drawn in a specific order per facing direction (and we'll skip the issues of mirroring).

Then you have the items themselves which just have a ton of possible values and properties. I don't have an exact count, but I believe its probably around 40 or 50, not including stuff like fire arc definitions.

I'm trying hard to keep 90% of this also data driven, vs coded into the engine, which causes extra complication.

I guess most of my struggle is really coming up with smart solutions that are manageable and don't result in tons of labor. Its like exporting that walking animation manually and then doing all the file renaming to match item ids and so forth would easily take an hour or so (Now what if i have 20 animations for a single mech, and 20 - 30 units? ). Then if something changes, it means doing it all over again. So spending a bunch of hours making a smart script to automate all of that, pays off hugely.

So when I also start thinking about how to define an item via data, and arrive at something like a "Jump jets" which essentially kinda have a lot of custom handling in ways, it really makes you think. Essentially its an item that gives a movement modifier when activated, but then it also has to likely trigger special animations, do some more special bits like flying the unit off the screen, or what not, and then more animations for landing. I don't really know how to do that with data only in any sane way at the moment.

Also just so much of this data stuff overlaps, like base units obviously need names and descriptions, same with items, and likely tool tip hover info, yet all of this really should be using like lookup numbers to allow for localization to different languages, which means I need more files and ID's to define all of that.

Just feels like I'm drowning in data a bit, and trying to come up with solutions that make it easily manageable, is a bit of a bitch.

In the end I need something very well architected and designed, as I'm likely dealing with this for the next 3 years minimum, and possibly next 10 years or more if its successful.