Starting work on a new unit renderer to deal with layered based units. Unfortunately this has brought back front and center a ton of data issues, such as how units are defined, equipment, layers, and so forth. I'm considering dropping M.E.A.D and really just going full blown Lua, but I'm not sure.

Managing all of the data for this project sure is turning into one of the toughest problems to solve of the entire project. This and dealing with thousands of frames of animation potentially per unit.

I think I'm starting to envy Ultima Online and how they only had player bodies handle layers of equipment. It really is much simpler when you only have a single unit, with a single set of layers that can nicely be defined. Something like an infantry unit vs a mech frame is hugely different in the M.I.N.T universe. Ah well

another thing to consider is that modern gamers are simply worse at games

Sadly signs and experience point to a resounding yes.

[*VICTORY*]

8 hours of writing a photoshop script to export animations for M.I.N.T... *VICTORY*

Still though it will save countless hours to come, and its quite awesome clicking a button and watching 180 frames of the mech get spit out of a single PSD that has a 10 frame animation.

So yeah, was off Friday, and have been mostly mucking about design thoughts today. Fun questions like "How to represent jump jets, or drop pods as only data, and integrate into the game correctly.", but I also went ahead and coded in Texture Packer Pro support into the framework.

Implementing stuff yourself is a two edge blade though. Sure you understand it (hopefully) but your also missing out on software that has had years of use by possibly large user bases, bugfixes, unit tests and so forth. Obviously there is risk assessment at work as well, but this is why something like SDL still ends up used in major projects. Likewise for better or worse the STL and even boost.

Of course I can understand the other side to especially when it comes to services vs released products. I'm still a bit sketchy about using ASIO instead of rolling my own cross platform async networking code.

I've fantasized about living here for a year or so. Watched a documentary on it. Rent for a NICE place is 30$ a month.

http://en.wikipedia.org/wiki/Aogashima

Of course food is probably a little expensive since they boat in a shipment to its only store once every fortnight.

Good luck getting internet out there.

I imagine satellite would work fine. That was going to be my solution, when I was considering just buying a sail boat, and roaming the seas and ports while making games.

but even that isn't absolutely necessary, i could probably do without either and use the worst of both words and still make games i'm proud of. and again i wasn't saying that those nice things aren't nice, i was saying that they aren't *necessary*. the earlier claim was that if you are going to make indie games you "need" to spend something like $1000 on a computer, and i was saying that it could be done on $400. not that it should be done on $400, but that it could be done on $400. if someone wants to spend thousands of dollars on a computer every two years they can do so, but they shouldn't delude themselves into thinking it's some kind of necessity

If we're purely talking about "need" than ya sure I agree. It's just certainly not what I'd recommend if one wants the most productivity and efficiency. So when talking about laptop options for development, and the laptop being the sole dev machine, I'd certainly "want" something higher end. Which really goes back to my point that at that price range your likely going to be far happier with a used or off lease laptop that has much nicer specs.

 *shrug* I suppose I'm likely also quite entitled and picky about my tools after almost a decade of being employed as a developer.

Anyways as to the rest of the topic, it really just comes down to discipline, no gimmick is likely to get you to stay focused and work on something if you don't want to.

I'll simply have to disagree with you. Yes you don't need in i3 or i5 but you'll wish you had an i7 and a SSD the moment you do anything more involved. It's a long standing practice to obtain as much development power as possible for productivity reasons. Especially when talking about compiling in visual studio, 3D rendering, and video rendering as well. Even just editing and saving large photoshop files is helped a ton, and this is super common in mobile dev where your base resolution now is often 2048x1536 resulting in psd files often hundreds of mbs in size a pop.

The HD cards have come a long ways no doubt, I even helped bring them to market along with nehalem, sandy bridge, and ivy bridge. However, they are still quite limited, often simply thanks to memory bandwidth since they lack dedicated high speed VRAM and instead use up system ram. I've also ran into shader development problems in the past with the HD 3000, though to be fair some of that may have been driver and OS related. Drivers were always a bit sketchy alas.

However the card can certainly struggle to render a game out at 30 or 60 fps and also do a full HD recording at the same time without dropping frame rates, which I've found is a pretty common process during development.

We'll agree that testing on lower spec machines is important though.

That's a terrible laptop for the price, and the integrated video card may cause problems if your trying to do anything with shaders. I'd recommend looking at the used/off lease market really though if wanting good deals. Anyways laptop mobility is great if you actually use it, but it also doesn't come with multiple monitors and so forth either which can be extremely helpful.

Edit: I guess that's not as bad as I thought at first. Seems like Intel decided to reuse the pentium dual core name, when in fact that CPU is ivybridge based. Although I'd still shoot for an i3 or i5 at the least and ideally something with a non-intel integrated GPU.  (although the HD series is far improved)

It's a great move IMO, though can be complicated to do (visa requirements for just a start), and can of course have many downsides as well. I would of left the states years ago though if I hadn't become trapped with various family issues.

There are certainly som lower cost of living areas in the states to though.

Yeah Texturepacker Pro it is, looks like they earn some of my money finally. (So much more cost effective than updating the in-house texture packing software to have these features.)

Just confirmed that its alias creation keeps the offset positions per file name even when trimming aliases.

So 10 frames of an animated leg ends up as being just a single image, but with 10 aliases like so:

<sprite n="leg00.png" x="2" y="2" w="32" h="50" oX="29" oY="50" oW="128" oH="128"/>
<sprite n="leg01.png" x="2" y="2" w="32" h="50" oX="27" oY="53" oW="128" oH="128"/>
<sprite n="leg08.png" x="2" y="2" w="32" h="50" oX="34" oY="53" oW="128" oH="128"/>
<sprite n="leg09.png" x="2" y="2" w="32" h="50" oX="29" oY="50" oW="128" oH="128"/>

Alternative approaches would be to use our own in-house parts based animation editor, or a now commercial alternative like Spriter. However I don't believe either of those approaches at current would work as easily as the above when it comes to allowing the scope of visual customization we have going on.

I think that, of all the games with devlogs on this site right now, this is probably the one I am most excited for, or at least tied.

Hopefully it won't disappoint then

Been going at it light yesterday and today as the wrist is a bit blown out again, to much excitement and work in the last week I guess.

So instead of coding I have been doing mostly design work. Trying to figure out how exactly all the visual customization will work along with defining equipment. Which I think has given way to an established work flow. Basically a photoshop file/timline animation per animation per unit that has every possible piece of visual equipment for a given unit as a seperate layer. Then every layer of the animation is exported out as an indivitual file with a naming scheme like "itemid_animationid_frame". Each file exported is exported at its full frame cell size. (Hugely wasteful but it means all offsets are automatically correct)

Finally using texture packer pro or a custom tool if need be, every file is automatically trimmed (while preserving original size and offset info) and any graphical duplicates are removed just creating lookup aliases and associated offset info per duplicate. All the files then are packed into a single master texture atlas for that unit.

Rendering then becomes simply a matter of item IDs, an animation number, and a current frame. Minus of course the problem of draw order, which needs specified per unit and per facing direction. However max layers is likely around 10 or so, and many units are likely to have far less. So it shouldn't be to bad, just a few lua calls during setup.

whats rsi

Feared enemy of programmers and artists.
http://en.wikipedia.org/wiki/Repetitive_strain_injury

Just watch out for RSI damage from laptop keyboards, after 4 years of laptop typing with no external keyboard, I ended up having to switch back to a desktop and to a Kinesis Advantage to get rid of endless bouts of tendinitis.

the idea of code as an end in itself doesn't really make sense to me though.

It's actually not that uncommon with programmers. It often goes along with chasing bleeding edge programming bits and obscure languages at times to. Often most of this goes against getting stuff done, but its semi understandable from a craft/art perspective. I suppose in ways it's the mark of a good programmer, but perhaps not always a good developer

It's more valuable to me to implement something that works exactly the way I want it to than to add some completely unneeded dependency to my project, one that forces my code to adapt to the way some other guy decided to do things.

Yet in terms of productivity it's typically worse, and in terms of maintenance often has a higher cost associated with it, especially if anyone else has to ever update or inherit ownership of it. (Open source and commercial solutions often have various support available, etc)

I'm not against remaking the wheel at times, but it usually ends up with more costs over the long run.

It's like custom tools, I have quite a few which I made when nothing decent was available on the market really. Yet in the last few years, tools with far greater features and with dedicated developers have emerged. Suddenly spending time updating the custom tools to add new features that already exist else where, deal with bugs, and so forth starts to have a lot higher cost that just buying a commercial alternative.

looking gorgeous 

Cheers!

Mooore environmental updates



Full Size Map

The other big factor to consider here is that 10-12 lines a day is suppose to be good code more or less. It doesn't take into account all the lines written and thrown away as you experiment, and so forth. That number doesn't really surprise me all that much if your talking about large projects. Tons of time is spent in design, testing, code review, and approval.

Obviously you can hack out code at much greater rates than the above, and at the start of projects lots of new code is often written. However the average LoC/Day drops over time quickly once you reach some significant complexity and size level.

Rebuilt all the tiledata, and fixed several height map issues that was preventing this new level of map detail to be rendered properly in-game. Re-wrote deployment code to support multiple unit previews, and use all of the Lua data vs hardcoded bits.

Also redid the whole movement and path grid overlays.