Game Design, Programming and running a one-man games business…

Production Line blog:#11 The motion-captured cat edition

I apologize in advance for this. I am normally less easily amused. Maybe. This is in no way an attempt to distract attention away from my failure to have many big ticket features to show off this week:

Next week might be more noticeably ‘different’ because I have grand plans to get some ‘expandable lots’ in the game. That means your initial factory size might be 30×30, but it will be bordered by a bunch of additional lots of different sizes which you could take over (thus increasing your hourly rent costs). I think a lot-based system is more interesting than the standard ‘$x/square meter take whatever you want approach many tycoon games use. This is a real-world concern. How often are you able to phone up the farmer who owns the field next to your factory and specify exactly how many square feet you want to rent next year? That sounds way too easy :D.

Hope you enjoy this rather stupid video of dubious informational content.

For those interested, you can find out all about Production Line Here.

Production Log Dev Blog#10 Level Editor and Upgrades/Font change

You may have thought I’d give myself a week off doing video blogs for Production Line, but you would be wrong. That line of thinking leads to failure, mediocrity and generally not succeeding, whereas doing it anyway is more in the tradition of Elon Musk and other stupidly ambitious people…so here we go.

To be fair, it is a day late. A lot of tiny things got fixed, mostly calculation bugsĀ  and GUI layout stuff. The whole GUI style is very much placeholder, but I’m deliberately prioritizing design and gameplay, the GUI can get some shizzle later. I think most Sim/Tycoon gamers are far more interested in mechanics and balance and features than they are in shiny stuff.

My big dilemma, (But I think I’m sorting it as I type), is to whether upgrades should be things that happen to existing slots, of stuff that unlocks *new* slots. I think a goods compromise is to do a bit of either, when it makes sense. For example ‘leather seats’ and ‘heated seats’ are definitely an upgrade to the existing ‘fit seats’ slot, whereas ‘satnav’ is more likely something that gets installed as a totally new thing in a dedicated slot. This might lead to some confusion on the part of the player, but as long as I explain that some research unlocks new upgrades, whereas others unlock new slots, that should be simple enough.

The big problem is do I allow the player to do stuff like ‘heated seats’ before they have unlocked the dedicated ‘fit seats’ sub-slot. I am thinking maybe no… you have to have broken down the production line at least as far as ‘fit seats’ before you can get the option to fit fancy ones…surely? What do you think?

Production Line video blog: #9 Researching robot upgrades. MORE ROBOTS

Can you believe I have made it to NINE video blogs and still haven’t set up an alpha purchase date yet? Neither can I. Here is the aforementioned bloggage:

Work seems to be progressing quite nicely on the game. I added some placeholder music, fixed a bunch of relatively minor GUI bugs, and now have those floating currency things back (working better), and proper locks on researchable stuff. I also switched from reporting daily sales to hourly, and also to a system where if you don’t produce power it gets purchased for you 9expensive, but necessary at the start).

I’d love to know what people think, and happy to answer questions in the next video even if I don’t do so in the comments.


Production Line blog#8 R&D and Car Sales

Another week…another video blog. This is number eight. I suspect thats more video blogs for any game I’ve ever made, and all before release. Just call me cliffski: the god of social media marketing eh? Maybe not… but at least I’m trying. I wish I could stream on twitch but with a 75k upload speed, that isn’t going to happen. Anyway, it would just be me swearing a lot and drinking tea, who honestly wants that in their life eh?

Here is the exciting new video! it features never before seen dialog boxes and more!

My plans for next week include seeing Star Wars: Rogue one before all you peasants in America, and gloating. I may also get some work done on the game. I aim to get some tutorial style hints on the screen to make it more obvious where all the conveyor belts are facing and what slots can, and can not go next, to make it easier for people to put together their first few Production Lines. I also need to add some cursor hints for when you are dropping conveyor belts and resource conveyors, and I need to get those floating text things back in and looking nice so you can see when you spend money.

In short, I’m going to be concentrating on getting gameplay & usability stuff in there, and not any more graphical features. Ultimately I want a lot more animation and ‘life’ in the game, which will mean a lot of flashing lights and little micro-animations on some of the props, but thats filler for later, after I have some people playing the alpha build and telling me what they think. I *still* have no idea if I will do a closed invite-alpha or an open, pre-order alpha, or some other hybrid. I suspect I’ll go the ‘pre-order and get alpha builds’ route around February next year which is not *that* far away now.

As always I implore you to share, link, tweet, instagram, snapchat, facebook, reddit, square, uber or tinder these videos. I have no idea what half of those are.

Rolling your own 2D Animation compressor in directx FOR FUN

This is the short ‘story so far’ on animation compression for Production Line, my next game. I use my own engine that runs on directx9,a nd the game is isometyric in style, so uses a lot of spritesheet-style animation frames. In short, this is about how I enable animations like the one below (excuse the crappy gif compression, actual image is less pixelated in the real game), to fit into tiny amounts of video memory. (The disk version of that anim is 4MB, compressed for download its 355k). This is an ‘idle’ anim of a marketing manager in the game checking his phone to make all-important marketing related phonecalls…


You might think that cannot possibly be a 4MB animation, but you would be dead wrong. The actual source graphic is 128 wide by 256 high, after cropping, meaning that a frame of it gets delivered from the artist looking like this:


Thats no problem, but a complete animation cycle is 300 frames long, and I need two versions, one to look towards, one away (I can flip in X axis for the others). 128 x 256 x 300 is 9.8 million pixels, or a 4096 x 2,400 pixel sprite sheet, which takes up 39MB of VRAM. Assume both directions are in use = 80MB, 3 different characters is 240MB. Thats with one skin color and one gender. Ouch. So obviously we need to compress it.

I rolled my own compression system for fun, and to give me total control over how it works. The first step is to cut out any dead space and remove any duplicates. When our little dude is on the phone, the image doesn’t change, so we have a lot of duplication in that colossal theoretical sprite sheet. How did I approach this?

I decided upon a 64 chunk ‘grid’ for any image that would be animated, dividing it into 8 sections horizontally and vertically. With the raw image I get given, that gives me this:


Actually this is annoying because his hair only just clips into another row, which is inefficient… never mind. The most obvious thing here is that a lot of the animation frame is just empty space. In order to kill both the ’empty space’ and the ‘same as last frame’ problems in one go, I work out a CRC (basically a unique signature) for each of those grid squares, for each frame, and store it in a great big list of data as a pre-processing step.

With all that data in memory, I then go through each chunk of each frame, and look for previous frame chunks with the same CRC. If I don’t find any, I mark it as a ‘used’ chunk. if I do, I just make a note of which earlier chunk to use, and increment the use count on the old chunk. Once this is done, I can go through all the chunks and discard the ones that have a zero use count (or are blank).
Stage two is to create a whacking great spritesheet of all of the chunks that I actually *do* use, which looks like a weird mashup of imagery like this:


(It also has an alpha channel). I can then go through all of those ‘used’ chunks and make a note of the UV values for each of them in my new spritesheet. Now, the final stage is to go through every frame of the animation, and make a note of which chunks actually get drawn, and the index into my list of ‘used’ chunks. This means I now have a big text file for the animation that tells me which of the 64 maximum chunks of the spritesheet I need to draw in each frame. In the case of this phone-dude, that shrinks the actual texture memory usage by 95%, meaning I can easily have a bunch of different animations.

Thats where I am right now, and its pretty fluid, and works without bugs. The next step will be optimizing the code, rather than the source. An optimisation I managed today was to actually successfully only draw the non transparent chunks when I do the rendering of each frame, which reduces the number of polys and draw calls. The next obvious optimization is to spot when a chunks ‘source id’ is the same as the previous frame, and then not bother updating it at all. Right now, I redo the UV lookup and apply the values every frame for this dudes legs, even though they don’t move during the whole animation. Thats a bit too much processing for my liking.

I’m sure middleware *does* exist that does this, but I like to code stuff myself so I know 100% how it works, 100% how fast/slow it is, and can ensure compatibility with all the rest of my code and workflow. I’ve probably spent a week doing this, maybe a bit more, but I have a pretty cool system now that lets me knock up a 30 secon text file when I get a new bunch of animation source files, then hit the launch button and the game will do all the preprocessing and give me the compressed data automatically. Yay.

This also means that with only 4MB+4MB of VRAM for an animation for a character, I could double the characters, and have both genders without running out of VRAM. This also makes the game more usable on low end PCs. Now the limit is my art budget, rather than the hardware :D Anyway here is a reminder of the final video, and also that this is for my car factory game: Production Line