I really don’t get how indies put so much time and effort into their first game. The ones who get into debt amaze me even more. the ones who mortgage/sell their house scare the crap out of me. Don’t do this.
I’ve made lots of games, here is how they went:

  • Asteroid Miner: Meh…sold a few hundred copies, was exciting to see it in a box.
  • Starship Tycoon…sold a few hundred copies, also some retail deals, tempted to quit day job… and does! That was a mistake!
  • Rocky Racers… mediocre flop.
  • Kombat kars… mediocre flop.
  • Planetary Defense…not bad considering development time was super short (a few months).
  • Kudos…surprise hit. did really well. 3rd party publishing deals that paid actual royalties!
  • Kudos 2… even better. Seriously good sales. hit $20k in one month. unbelievable.
  • Democracy…not bad, not enough to quit job, but really not bad.
  • Democracy 2: Really good, enough to quit job. *quits job AGAIN*. pays off mortgage.
  • Gratuitous Space Battles: OMG teh fountain of money. Buys new house.
  • Gratuitous Tank Battles. Meh: pretty good, but nowhere near as good as GSB.
  • Democracy 3: LOLLERSKATES. Orders brand new car & stupidly expensive laptop. Starts flying business class. Eventually buys stupidly flash electric car.
  • GSB2: Yikes, that didn’t go down well. Ouch. what did I do wrong?
  • Democracy 3:Africa. Fuck. Americans REALLY don’t care about Africa then? Barely breaks even.
  • Production Line: LOL. Almost physically crushed by stampede of pre-orders.

My point is…holy crap you never know what will happen next. Your next game could flop, it could be huge. I *really* think that GSB2 is underappreciated and am surprised it flopped. I’m still amazed at how many people like political strategy games. YOU NEVER KNOW. So be cautious, and experiment a bit. if I’d bet my house on Asteroid Miner, I’d be renting a bedsit whilst still working in IT support trying to pay off debts. I’ve never borrowed money to make a game, I’ve never remortgaged, I’ve never worked for more than 18 months on a single game before putting it on sale.

That might be a bit clinical and unromantic, but its worked for me. Your life is not a feel-good Hollywood movie starring Tom Cruise. Don’t get stuck in confirmation bias. Many indie games fail. Some fail HARD.

Wow its been a BUSY week, like crazy busy. I released build 1.07 for Production Line, and started on 1.08. The price went up to $11 today, and I also started laying out a list of coming soon stuff in the forums here. There has been a steady (and accelerating) growth in daily pre-orders for the game. 4,000 sales seems ages ago now, and I’m struggling to keep up with all the feedback. Anyway…here is the new blog video.

I shouldn’t really be surprised, but the pace with which people have got around to building REALLY BIG factories is kinda amazing. This meant I needed to do some optimisation for those cases, often totally revising my idea of how big I should make certain fixed size buffers. (640k is enough for everybody!). I know some programmers might say ‘but dude…variable sized data structures. Yup, know all about them, but they can be SLOW. Try comparing the performance of a list or vector and an array one day… its HUGE. What I tend to do is have fixed arrays of oft-used objects, and allocate extra arrays if I start to run out, meaning rare one-off frame skips, but silky smooth performance most of the time.

My day is just now a blur of checking email;, then twitter, then facebook messages, then reddit posts, then forum posts, then forum messages, and then going through my bug list and my features todo list until its time to sleep or blow off steam in Battlefield One. However…just in case you thought that made me sound lazy, don’t forget we are also publishing another game (Shadowhand) which is coming soon. Here is Jakes latest video about the game:

Before long it will be GDC, and before that I’ve agreed to speak at TWO(!!!) events, which means…holy crap. I should stop typing and get on with it.. I will leave you with the exciting changelist for Production Line build 1.07:

[version alpha  1.07]
1) Major performance optimization for large factories.
2) Much faster vehicle rendering when zoomed out.
3) Fixed bug where very high car output resulted in no market price for a car being low enough.
4) Fixed the 'No room to TrashLowPriorityResource from stockpile' bug.
5) Fixed the 'Route Pending!' bug.
6) Possible fix for corrupt efficiency graph.
7) Fixed bug where manufacturing slots showed as not connected to a stockpile until the first resources arrived.
8) Added game-clock to top right menu.
9) Quitting the new car design dialog now gives a unique default name and price to the design.
10) Fixed bug where the warning notices on cars would persist until they encountered an empty conveyor belt.
11) Fixed bug where right clicking on research screen could delete items in the factory.
12) When a car is unable to move to the next (connected) slot, the message now tells the player which requirement is not met.
13) Background sound FX in R&D screen reduced in volume.
14) Fixed bug where some conveyor belt placements resulted in multiple placement sounds on top of each other.
15) Fixes to the layout of some R&D and slot menu items.
16) The warning and error notices in the factory now shrink to icons when zoomed right out.
17) As a temporary quick balance measure, only 4 valves are needed for engines now!
18) Fixed bug where supply stockpiles would not always fill correctly.

 

There are no comments yet

Anatomy of a bug fix

February 09, 2017 | Filed under: production line | programming

I thought it might be interesting to just brain dump my thoughts as I do them for a Production Line bug.

The bug is an error message which I get triggering thus:

GERROR(“No room to TrashLowPriorityResource from stockpile”);

Which is handy, as I know exactly WHAT is happening, and where in the code. Thats 95% of the work done already. Amen to asserts! I know that inside the function SIM_ResourceStockpile::TrashLowPriorityResource(), I am not able to actually do what the function needs to do. So firstly what does this function do anyway? I can’t remember… Thankfully there is a comment:

//if we find a resource not needed by current task, destroy it (only one)

Which is pretty handy. So this is a stockpile at a production task (working on a vehicle) and it needs room for a new resource presumably. The code goes through all of the objects currently in the stockpile to check we really need them. here is the code:

    iter it;
    for (it = Objects.begin(); it != Objects.end(); ++it)
    {
        SIM_ResourceObject* pobject = *it;

        //is this object needed?
        bool bneeded = false;
        SIM_ProductionTask::iter rit;
        for (int c = 0; c < SIM_ProductionSlot::MAX_RESOURCE_QUANTITIES; c++)
        {
            SIM_ResourceQuantity req = PSlot->CurrentResources[c];
            if (req.Quantity <= 0)
            {
                continue;
            }
            if (req.PResource == pobject->GetResource())
            {
                if (GetQuantity(req.PResource) > req.Quantity)
                {
                    bneeded = false;
                }
                else
                {
                    bneeded = true;
                }
            }
        }
        if (!bneeded)
        {
            RemoveObject(pobject->GetResource());
            return;
        }
    }

Thats the first half of the function, it then tries to do a simialr thing with requests, rather thanm objects. However I think I see an issue already. That GetQuantity() is checking the total quantity, not for this single object. Nope…thjat makes sense. I guess I really need to trigger the error and step through it, so time to fire up a save game from a player and run it in *slooooow* debug mode. Ok… an immediate crash from a save game..where we have 16 requests and no objects. So there seems to be a bug in the latter code:

    //ok we need to destroy a request instead of a current object.
    reqit qit;

    for (qit = Requests.begin(); qit != Requests.end(); qit++)
    {
        SIM_ResourceRequest* preq = *qit;
        //is this object needed?
        bool bneeded = false;
        for (int c = 0; c < SIM_ProductionSlot::MAX_RESOURCE_QUANTITIES; c++)
        {
            SIM_ResourceQuantity req = PSlot->CurrentResources[c];
            if (req.Quantity <= 0)
            {
                continue;
            }
            if (req.PResource == preq->PObject->GetResource())
            {
                //sure we ordered it, but do we actually have enough for this task, when com,bining requests with objects?
                int stock_and_ordered = GetStockAndOrdered(req.PResource);
                if (stock_and_ordered >= req.Quantity)
                {
                    Requests.remove(preq);
                    preq->PObject->Trash();
                    return;
                }
                bneeded = true;
            }
        }
        if (!bneeded)
        {
            Requests.remove(preq);
            preq->PObject->Trash();
            return;
        }
    }

So what could be wrong here? Ok…well hang on a darned minute. This code is just saying ‘do we really need resources of this type right now???’ rather than ‘do we need ALL of these right now?’  which is more of a problem. We are clearly somehow ‘over-ordering’. The slot in question is ‘fit trunk’. presumably it only needs trunks… They do all indeed appear to be the same type. 4 are ‘intransit’ the rest are queued up at some resource importer or a supply stockpile or component stockpile somewhere.

So the ‘solution’ is easy. First kill off (delete) a request that is not in transit yet, to make room, or if that is not possible, kill one that actually is in transit. This then frees up the required place in our stockpile. But hold on? this is just patching over the wound? how on earth did this happen? The calling code is requesting new resources, when clearly 16 are already on the way! in fact its requesting a servo…

AHAHAHAHA!

what a beautiful bug. The player obviously upgraded to a powered tailgate, which means a servo is needed for every trunk, and yet 16 trunks were already on order. Error! error! I have special code that handles when an upgrade makes an existing resource requirement obsolete (climate control replaces aircon), but not code to handle this case, where additional stuff is needed. This is FINE, I can implement the above mentioned code without worrying how it happened.

That actually wasn’t too bad at all :D

Jake Birkett, one of the developers behind Shadowhand is going to be at GDC this year, shortly before the final (yay!) release of the game. If you haven’t already heard about it, check out the website or read the announcement on Jakes blog:

http://greyaliengames.com/blog/going-to-gdc-want-to-try-shadowhand/

Its a very interesting game, because its a sort of RPG/Card game/Visual Novel mashup with cool characters and a very interesting combat mechanic. I think it will appeal to casual card game players and Darkest-Dungeon lovers alike.

I’ll also be there, wearing a REALLY BRIGHT jacket, and pretending to be networking.

There are no comments yet

This week has been tough. I’ve been busy, also been ill, and been totally rewriting a core bit of code in Production Line to fix some obscure bugs. I think the code is way better now, but the proof is in the play-testing. I didn’t want to keep the improvements I *know* I’ve made hidden from people any longer so today I released 1.05 and also this video…

Here is the complete changelist:

[version alpha  1.05]
1) Resource conveyors now have feint shadows.
2) New design and car stock dialogs now prevent autosave from triggering.
3) Powerplant efficiency upgrade now works in a more obvious way.
4) Massive speed-up to the delay between a stockpile needing resources, and them being ordered.
5) Floating values and particles no longer visible when quitting a game.
6) Fixed crash bug when preparing to place a new slot over a conveyor belt loop.
7) Game now paused whilst in R&D screen.
8) Erroneous robot upgrades removed from make windows slot.
9) Changes to floating values rendering makes zoomed out GUI less messy.
10) Fixes for possible causes of crashing when saving really big games.
11) Some crude rebalancing of starting funds for the first two missions.
12) ‘R’ as well as ‘r’ now rotates.
13) Clicking current balance now acts as an on/off toggle on finance window, which is no longer modal.
14) Various minor GUI fixes.
15) ‘Make valve’ is now visible on the slot picker.
16) Save game GUI now much more consistent with the load game GUI.

This code has been hell to get right. Its all to do with the resource items that get delivered around the factory. They can be created new (nothing is actually new() for memory reasons) and imported from an importer (or held in an importers queue), then can be in transit, then can be used up, they can be created by manufacturing slots, or heading to/from a supply stockpile or in an export queue for either of those things. Thats all EASY to manage. The code hell comes from the fact that the player can delete ANYTHING at any time, or change any route which makes some of those items ‘stranded’. You can delete the source of a resource, or some part of its current route, or its destination at any point, and code chaos ensues.

I think its much better now… I really hoper so, its actually stressed me quite a bit.

Ultimately all bugs can be fixed, but its frustrating because a) I have a lot of people playing and want them to be happy and b) I have a long list of ‘cool things’ I want to improve and tweak and add, and I’m not letting myself do any of that stuff until I have little or no bug reports, so its been really frustrating. I’ll be sooo happy if people say I’ve fixed some of the bugs and I can go back to doing some GUI improvements and some play balancing and tech tree fun and games!

The alpha continues to be really, really popular, almost entirely by word of mouth (not much press has come our way), so that’s really encouraging and I’d like to thank everyone who has tweeted, posted in forums, and generally told their friends about the game, it is much appreciated. I’m really hoping next week my video will be all ‘look at all the coool stuff we added!’.