Please support Space-Base DF9 on Fig!

Not really, of course, but what if it had been?

Space-Base DF9 was released by Double Fine on Early Access on 27th Oct, 2014, with an ambitious and exciting list of planned features. By Sep 17th, 2014 they decided to pull the plug, and make the next official release 1.0, quietly editing down their planned features to a nub, and claiming they didn’t have enough funds to continue. Me colleague Binky wrote this awesome thing, and pointed out that perhaps Early Access isn’t right for everyone, and very likely not Double Fine given the cost of running their studio and the apparently huge sales figures they would need to justify it.

(SteamSpy reports DF9 has 123,630 owners, which you would have to assume the majority were pre-1.0, given the 24% score. Many Early Access developers with much more ambitious games would kill for these sales figures and yet continue on without them)

On the announcement of the 1.0 (I plead with PZ players to remember that long Early Access runs aren’t always a bad thing ;)) the steam reviews for Space-Base DF9 plummeted, as you can imagine. In this instance, when gamers invest their money into a product, and the return on that investment is purely getting a game they were promised, and they do not get that game, their justifiable reaction is to write a scathing review and tell everyone they know to avoid a purchase.

In the age of Early Access, as much as I wish I could say otherwise, this is very important. It’s important to call out the people who betray gamer’s trust, deceive their customers or treat them unfairly, just as its important to spread the word on those that stay true to their word.

However today I heard about Fig, an upcoming newfangled crowdfunding site specifically for games, but with a twist! Now the backers really are investors, and get royalties from the game’s sales!

I’ll admit I’m obviously only going on the scant information we have about how Fig will actually work, but its hard to see how the main issue would be circumnavigated, and that is from the sound of it, it would reduce the likelihood of your game’s backers ever being vocally critical of the game or the developers.

It’s fitting that Tim Schafer is one of the brains behind this.

At time of writing, Space Base has 647 positive reviews, and 2,029 negative. This has resulted in a 24% score. We may need to investigate these kinds of scores to see where they come from, and there are cases of unfair mass downvoting, but when dealing with steam review scores, it’s generally a case of ‘no smoke without fire’. I know we’ve been far from perfect ourselves, but now that people are routinely buying unfinished games, and with the many opportunities for people to lose money on misleading or ill-advised Kickstarter or Early Access projects, and for the more unscrupulous sorts to abuse the system, being able to trust the word of your fellow gamer is ever more important. This is why tensions between gamers and the games media have heightened in recent years, with more and more ways gamers can feel dicked out of their money and being angry if they had the game recommended to them.

So what happens when even your fellow gamers may have a direct financial incentive to sell a game they backed, EVEN if they are hugely disappointed and angry at the resulting game? Now at the moment it will only be accredited investors, and this doesn’t seem to be an issue for ‘initial projects’. But…

“The lead investor in each project will negotiate the terms of the investment — which will then be passed on to the investors who sign up on Fig and follow suit. Minimum investments will be high — in the thousands of dollars — particularly in the initial projects, but Bailey foresees a future where fans set up trusts to invest in games collectively.”

(source)

We’re not talking about launch day here. We’re talking about where this system is headed if successful. Star Citizen has shown that a lot of people are prepared to put thousands of dollars into a game, even with no chance of returns. This doesn’t reassure me. How many backers will there be on these projects? If Space-Base was on Fig, how many backers would it have had in total?

10?
100?
400?
800?
2000?

I guess it depends on the game. But given that Fig hosts ‘just one campaign at a time’ (though again, for how long until they scale it up?) I imagine the focus on it would result in higher numbers of backers than games lost in the Kickstarter ether.

So we could have cases of hundreds, if not thousands of backers. How many of these people would then have a free steam key for the game? How many of them would be inclined to leave a glowingly positive review even if they were seething inside, desperate to claw back as much of their ill advised stake as possible? How much could the backers alone directly influence the Steam review score?

Not all games get 10,000 reviews and hundreds of thousands of sales and while it would be trickier to game AAA releases, I suspect indie games could be massively cheesable. Even if that’s not the case, like Cylons hidden among the fleet, investors with their objectivity compromised could walk anywhere among us. We don’t know how many of them there are, what they look like, and before long we’ll be trying to get our neighbours flushed out the airlock.

That’s just one problem. Back to the media. How do you really know that a YouTuber or a games journalist hasn’t backed the game they are reviewing? Even if they wouldn’t ever do that, how would you know? We thought the trust between gamers and journalists was bad before. YouTubers and streamers would be open to the exact same temptation and suspicion whatever way they would go.

If Fig was a success, and became the go to site to fund game development, how could we trust anyone ever again when it came to any of the games funded on it? With community/company loyalties, stockholm syndrome, buyers remorse and other biases, not to mention games being inherently subjective medium, it’s already not particularly clear to many people whether a Kickstarter or Early Access is a sure thing or a disaster in the making. People are getting more wise to judging, but this has the potential to become a huge step back, as in this age of concern about ethics when it comes to money and game critiques, it stands to compromise the reliability of everyone in games as the very people who are currently the most critical of failed game projects would be encouraged to keep silent.

Posted in Uncategorized | Leave a comment

Steam Refund System: Advantages For Devs

As the dev negativity about Steam offering refunds continues, I thought I’d list a few of the many advantages to devs of the refund system. Enjoy!

1) More pleasant forums

It’s always been said that Steam forums are unpleasant hostile places. We’ve never experienced this really, as the Project Zomboid Steam forums have always been a pretty pleasant place to be, but we’ve certainly experienced extremely hostile forums in the past (when we lost a month of code due to a burglary of our home, delayed a version, and were discovered to have had (now much improved) sub par backup procedures. As unfair and horrible as it felt given what we were going through, we HAD demonstrably fucked up. The hostility was not from a vacuum, and it rarely if ever is.). People are hostile because they are angry, and they are angry rightly or wrongly because they paid money for a game and are unhappy for whatever reason. That reason might not be our fault as developers, but the reason will be there all the same and now that person only has one recourse: To complain, to vent, and perhaps turn others away from making the same regretful purchase they did. Now these people can scoot off with their refund, and will be a lot less angry and will certainly be a lot less present. Crucially, they may not be around (or feel the moral need), souring the forums and dissuading the next customer that comes along.

2) More adventurous purchases

This is for all us with games on Steam that may have some hurdle for prospective players to dive in. First off Early Access games. Early Access developers may see a few more people prepared to risk a purchase, since they can properly access the quality of what is available already. As well as this, games with a more niche appeal, or with retro graphics, may get a few more experimental purchases now that refunds are an option for the consumer.

3) Less turds in the punchbowl

Mean to say, but true: This is particularly important to any Early Access developer out there, or every developer of whatever the latest genre trend is (see survival games atm, or voxel builder games last week) as it will pretty much deprive oxygen to every one of those Jimquisition fodder ‘me too’ hastily put together and exploitative games that try and capitalize on current genre trends. You know the ones. They erode customer faith in the system we all share together, make many a ‘Early Access: never again’ customer. In this new environment there are less risks for customers, and less residual suspicion and bitterness about unwise purchases. Those types of games will now shrivel and die before they can do any damage.  Where the games that actually try to expand on the genre, improve it, push it forward, do something different, and are actually fun and well put together will still be able to sail high. Furthermore may even do better, as…

4) Extra money in the pockets of customers

So you’re obsessing about what sales you lose due to refunds? Or because this money will likely end up in a Steam wallet and thus Valve doesn’t really lose out anything? Well surely it should be a two way street? Presumably that money in that Steam wallet is going to be spent on something the customer will like more. Why can’t that be your game? And if it’s not your game, and you are the one losing money to other games via refunds, is that not on your head and something you need to improve? No one owes any of us a living. If customers have freedom to make sure their Steam spent money ends up on something they want the most, and it’s not our game, then that’s on us, not on them or on Valve. Simple as that. Strive to be the game that people are buying with their refunded money, not the game being refunded. It only stands to reason that this will mean better games.

5) Are We Not Gamers?

As well as a developer, I’m also a consumer. I gleefully wait for the day when the quality of releases on Steam starts to be like a bit closer to what it was in the good old days. The margin on shovel-ware has just shrunk significantly.

6) It’s almost certainly not as bad as it looks

I would put good money on our game having more Greenlight votes than every other game that’s been on Greenlight since, combined. Why? It’s simple. We put our game on Greenlight in the first day it was available. We were in the first batch of Greenlighted games (though we waited an ENTIRE year before putting the game up). We got a shit ton of votes because Greenlight was a new thing everyone was talking about.

Don’t judge your refund rates in the first week, when everyone and their dog are talking about Steam refunds all over the internet (just shy of a summer sale into the bargain) . I doubt the true refund figures will be even close to what they are like currently. If we’d have made assumptions about our future success due to our Greenlight campaign, we’d be assuming we’d have sold about 100 million copies by now. Extrapolating anything at all from week one of a new system is madness.

7) Morality

Because it was just not right that people who bought games from us did not have the same consumer protections that most people in capitalist countries have enjoyed for years. If we were making extra money because of this fact, then that at the end of the day feels shady to me. My conscience, at least, will be clearer from here-on-in. If we had a 75% reduction on sales, then that would be bad. It would however be just, as clearly there were more people out there dissatisfied then we knew about.

But how has this affected us?

As it so happens we’ve barely noticed a significant drop in sales at all. I should point out I’ve spoken in favour of refunds quite passionately well before we had any evidence of the impact it would have on us. Yet still there feels to be this bit of me that feels guilty for speaking in favour of refunds when it hasn’t affected us adversely, when it has affected others so.

However this is something specifically we’ve worked very hard at since we’ve been on Steam, we priced the game as low as we could justify, despite every single bit of evidence pointing at making it more expensive resulting in more revenues, we’ve tried to provide as many hours entertainment as possible for as low a price as we could justify, we prioritized modding support, we made every move we could to extend the time people can play our game, and to favour customer satisfaction as possible even if it were against any immediate benefits, and that’s paid off. That’s why despite us being extremely delayed with a few game features, our steam forums continue to be on the whole nice and friendly, and that’s why when the refund system came in most people seem to have decided to stick around.

…and if they hadn’t, then it would be up to us to determine why, and fix that. Not to start assuming that everyone who buys our game is being dishonest and abusing the system. If that’s your first and only assumption, then maybe that’s the actual root of the whole problem?

 

Posted in Uncategorized | 2 Comments

The Greater Good (The Greater Good!) re: Piracy and Steam Refunds

I’ve noticed something a few times in the past, and it always puzzles me a little.

This has been brought back into my thoughts due to the recent Steam refunds goings on, and the weirdly negative reaction its received from a lot of people. My instinctive reaction was ‘GOOD’, and no amount of concerns about how it could be improved, or how Valve lose out less than devs, will make me think instead ‘BAD’. It’s a step in the right direction, and even if it steps too far, it’s a step that needed to be made.

This brought up a lot of thoughts I’ve had about how gamers have been perceived lately, the way they are represented, and how things have stacked up against them more and more with regard to consumer rights, and how in particular gaming, or entertainment in general, doesn’t seem to be considered important to human well-being, when compared to any of the more basic needs. I’m not sure I agree entirely with this.

People on my twitter or Facebook feeds are often decrying the sharp increase in the use of food banks in the UK, cursing the Tories for increasing the wealth gap, watching troubling TV shows about families struggling to cope. Looking for any way to help. Such compassion, it warms my heart. When it comes to people living on the poverty line, you would donate money to charities, fight to keep the welfare and NHS intact, would forgive someone stealing food in a heart-beat and hearing of their plight would throw money by the tens of thousands at a justgiving, to make sure the person in question could support themselves. It happens all the time.

Despite all the rumours we’ve heard, humanity can be a lovely bunch. But somehow, generally, this philosophy doesn’t seem to extend to people’s general quality of living and capacity for entertainment, in which of this generation a vast majority of that is found on the internet. Feed yourself for free, and get medical care for free. It’s on us! We’re here to help!

But heaven forbid you take advantage of the internet to cheat your way to free entertainment. It’s like entertainment doesn’t count. You need to get off your ass and work, and buy the game, or get that Netflix subscription, buy that boxed set. Pirates are the worst. SCUM. Leeching off others hard work.

Okay, not everyone is that hard line, but in a world that’s just a few years past a pretty heavy financial crisis, conservative governments sticking the knife into the poor, bankers and corporate tax avoidance, food bank reliance on the rise, poverty on the up, welfare systems becoming more and more restrictive and exclusionary. Isn’t it a wonderful thing that no matter how shitty a person’s life may become on account of any of this, for the cost of an internet connection, they are provided with an almost infinite wealth of entertainment? What a time to be alive!

Sure, there are those in the middle, between the ‘try before you buys’ and the ‘can’t afford to buys’, who you would lose out on. That mythical hazy boogeyman that no one in the universe could likely put an accurate number on. And sure, yes, there are those who will try and abuse the refund system on Steam. These people exist. They will always exist. They always have existed.

But, it’s fairly obvious if you think about it for even a moment that pretty much everyone out there would much rather have a huge list of great games proudly displayed on their Steam profile, auto updating, Steam Workshop, and online play, than having a bunch of gold discs on a shelf burnt from malware infected ISOs and requiring 30 incremental patches to play. This is plain to see. Gamers have pride in their game collection in exactly the same way others have pride in their record collections, MP3 collections, stamp collections, boxset collections. Who out there wouldn’t much prefer a special edition Bluray boxed set of the entire of Game of Thrones series sat proudly on their shelf to a bunch of avis in a directory, no matter how they came to watch the show week by week? And once you watched the entire thing, how many of you would truly then return it to Amazon just because that was an option? Don’t underestimate the value people place on ownership of digital goods, when that’s pretty much all people have now. This is a pretty universal thing. The fact that half the games bought on Steam are never played, but are likely picked up in sales in a ‘gotta-catch-em-all’ frenzy, trading keys or appealing for a gift on reddit, crafting of badges and chasing of achievements goes to show how much stock a vast amount of gamers put in their gaming profiles and how much value a legitimate Steam copy of a game has to gamers.

This holds true for these phantom Steam refund abusers too. If your game’s good, if owning your game is an improvement to their Steam library, if their friends play it, it bears replays well, or if they use the Workshop in it, have achievements  and badges for it. Even just that they are proud to own it, most people will want to keep it on their game lists if they can afford it. And if they can’t afford it? Do I really want to go to bed knowing their money is in our bank account?

Let us not pretend that it’s anything but a minority who actually relish pirating games, and playing them for free, denying the creators any money, and enjoying that fact. There are many that are more apathetic about it too, for sure. They just don’t care, or think about it too deeply, and maybe they can afford to buy. There are also plenty out there who would curse the name of people downloading illegal copies of their game on one hand, whilst queuing up Game.Of.Thrones.S05e08.avi without a moment’s self-reflection. But then there are an absolute ton of people out there to whom paying even £3-4 on a video game is an unjustifiable expense, perhaps geeks to the core fallen on hard times, who without such things as piracy, or being able to get a refund on a game if it turned out to be a bad purchase, would not be able to enjoy life to a capacity that we all should have the right to. Just as an argument could be made that we just suck up the expenses of those exploiting welfare because it provides a greater good, a net gain, to society on the whole, and after thousands of years of strife and toil and pain, humanity finally has a way to entertain and preoccupy the ever growing numbers of people in the world who are capable of obtaining an internet connection.

What good is being able to continue living if the things you find pleasure in are out of reach, and you’re constantly maligned for bowing to the temptation to get it all for free anyway? These people wouldn’t have bought the game anyway, and personally speaking, I’d rather they were playing it, talking about it, enjoying it, perhaps even telling their friends about it. If we don’t treat them like criminals, they may even buy a copy to support us once they get past the hard times?

I look at my own life, and I edit all these, on the face of it trivial and non essential, things, the TV shows, the movies, the games, from my life, and it would be dramatically poorer because of it. A large chunk of my free time is filled with these activities. I can afford to buy a game when I want to buy a game. I can afford to buy a boxed set of Amazon at a moment’s notice. It’d be very easy to get on my soap box and state that ‘it’s only $5, you cheap skates!’

A few people making creative works may have to deal with making less money for their work, without actually knowing how much, if at all, for sure, maybe? Probably some.

We may be losing money. We may be losing nothing. We may be gaining money due to word of mouth? We have no clue. If people are losing out, then that’s a huge shame. It sucks.

However, if a million people who can’t afford to pay for any kind of premium entertainment, or trips or holidays, have a more enjoyable life because of it, at what point isn’t that a fair trade? Even if a few of them are sniggering and rubbing their hands while they do it?

 

Posted in Uncategorized | 1 Comment

Where Bethesda/Valve Went Wrong With Premium Mods

There has been a lot said already about the whole paid-mods lately. As an indie developer who came from the modding scene I have many thoughts, many conflicting thoughts, on the subject. I have both fears and hopes about what is pretty much a delayed inevitability at this point: Paid Mods. First, I’ll give a bit of background.

Despite working in studios within the a/A/AA/AAA industry beforehand, the first real contribution myself and fellow PZ dev CaptainBinky made outside our day jobs was in the modding scene. Our first stop was the Sims 3, where we worked on something called the Indie Stone Story Progression Mod. Basically it provided a framework for soap opera style events to trigger, causing other characters in the neighbourhood to get married, have affairs and rivalries. It became pretty popular, and our names still crop up from time to time in the Sims community. This is a massive source of pride for us to this day, irrespective of what we’ve done on Project Zomboid.

Next came Civ 4, and then Civ 5. Our Civ 4 mod, adding famous characters from history as advisors with unique events, had some decent interest, and when we started on Civ 5 we managed to work out a lot of issues with the launch of the Civ 5 mod tools, essentially fixing bugs within it, and we were the first to figure out how to get custom 3d models into the game, writing tools to allow other modders to do that. Again, to this day our names crop up from time to time. We were also working on a substantial religion mod (sadly uncompleted as we were waiting for SDK… then Zomboid) that we’re fairly confident influenced the Gods and Kings expansion in some ways. Again, this is a massive source of pride for us to this day.

Now comes the question: Butterfly effect style! Where would we be right now, if we’d never been involved in any of that? Do we owe our current incredibly fortunate situation, in some part, to our modding? Answer is, undoubtedly, yes. The roads we went down as modders lead to Project Zomboid, in some direct ways, and other completely indirect ways.

We didn’t charge a penny. We couldn’t have charged a penny. We were doing it for fun. We were modding the game to make the game the way we wanted to play it. It was for us. Any kind words or praise from players, acknowledgements in other mods, or respect from our peers was icing on the cake. This was our hobby. Done in our own time after work for fun. Okay there was likely an element of seeking validation there too, after years of feeling unappreciated in the games industry. Truth is at the time I had likely never felt more appreciated than we did then. While the money would have been welcome, and we had put a ton of work into our mods and tools, it would likely not have made any huge impact on our lives, and would almost certainly have been nothing but beer money. Beer money I agree that we would have deserved, but beer money none-the-less. Of course, we’re talking pre-Steam Workshop days here, so I’m not saying the same is necessarily true today, though I would be amazed if mod creators (especially with just a 25% cut) would have their lives changed by any income from their mods. Just by considering the average sales of games on Steam, to a market of some 80 million people, compared to the (admittedly more targeted) market of those who own the game.

Now another question: Do we know, for certain, that Dean Hall would have been in the same position at the helm of his own studio Rocketwerkz today, if DayZ was a paid mod for Arma 2? It surely would have impacted the downloads in a significant way, on a game that at the time was a comparatively niche military simulator. It was obviously worthy of the attention, but the Zeitgeistey, viral and sudden rise of prominence of DayZ that is in part responsible for its massive fame and 3 million Steam sales today? Would it definitely have happened that way if it was a paid mod? Is there not more potential for it to have been an under-appreciated paid mod, one its players think worthy of more attention than it gets, and for it to never break out in the way it did? Furthermore that alternate dimension Rocket may have made a few thousand dollars from it and felt that was a success?

I’m not about to predict either way, it could have worked out better or worse, and this is an obvious outlier compared to the majority of mods out there, but its worth thinking about how monetizing mods may affect the overall reach of mods and the mod creator, and the opportunity cost paid may unknowingly be orders of magnitude higher than what the modder may make from premium mod sales.

After all, unlike games on Early Access, all these mods are behind two pay walls, have a target audience only as big as the number of copies of the game out there, and yet would carry all the same stigmas as Early Access: of being unfinished, buggy, work in progress, and having the potential for failure or exploitation, but being something people have paid real money for. Using a more cynical dictionary, one of the most loved aspects of PC gaming now becomes ‘Early Access Unofficial DLC’ – After a few incompetents and con artists (who will come, once there is money to be made) hit the headlines and leave their shadow on the Workshop, this virtuous saintly things we called mods could be painted in those same dark colours as alpha-funding has been. Wouldn’t that be sad? I venture modders who feel unappreciated should perhaps ask a few Early Access developers how appreciated they feel.

From what I’ve experienced as a Steamworks developer along with my instincts and nosing about Steam Spy, it seems to to me that to make a sustainable full-time living it would encourage developers to create many small, quick to develop mods over large, ambitious and in many cases the more exciting mod projects. For the beer money modders who just want to see some kind of financial reward for their work this is less of a problem, but for those hoping to make a living from it it, donate full time development to projects that have more AAA demands etc, this may end up pushing them down dark alleyways and restrict what they do a lot more. There’s the potential to become slaves to small quick projects to keep you ticking over that will not only flood the workshop but not be especially inspiring to play or make. I’d like to hope that modders primarily.are modding because they enjoy modding, driven by imagination and ambition, or vision for an opportunity unexplored in the game,. That was, to my mind, the only real reason anyone would mod games. Money entering the equation does have the potential to corrupt and ruin. Beware of turning something you love into your day job.

This is not to say I disagree in any way that mod creators work are often under-appreciated. Especially as technology progresses,  and modders are undertaking mods of more AAA ambition, that the work put in compared to the reward may be stacking up vastly against modding. This is a problem.

But in a world where all mods are free, the cream does rise to the top. It’s not as hard to get attention for something substantial and good within a mod community, compared to paid games. I’m sure a truly free game on Steam that was as good as the greatest paid games on Steam would likely not be lingering with only a handful of downloads. There are fewer underdogs in the world of the free. Fewer under-appreciated diamonds in the rough, as there is no barrier for people to download it providing it sounds exciting or interesting enough. If you’re talented and hard working, and produce something genuinely good that excites people, then you will get noticed in the community, and by the developers. If you have ambitions beyond modding, you’ll also learn a ton of practical skills, and gain a ton of experience that will impact everything you do from there-on-in. When we were modding, nice comments and praise were our currency, and while it didn’t feed our bodies it certainly did our confidence and ability.

I simply don’t agree with the argument that there is no practical gain from making a successful free mod, that there is no form of compensation. (and to be brutal, if your mod is free, and you’re unable to get any downloads or attention whatsoever, then maybe that mod isn’t original/good enough to be on sale anyway?)

It’d be fair to say that modders who want to be modders, enjoy modding, perhaps particularly due to the particular game they are modding, and have no designs or desires of making their own game in future, and if they have the developers, publishers and Steam’s permission to do so, have just as much right to pursue a dream of doing it for a living as do indie devs, or anyone else. I don’t have any fundamental objection to anyone being rewarded financially for their hard work. Hell, every member of the Indie Stone we’ve recruited has come from within the community, mainly the modding community. Nothing excites us more than modders having doors opened to them, since that’s the very journey we went down. More ways to support modders financially should be a great thing in principle.

But they went about it all wrong.

So Bobby has logged 200 hours on Skyrim. It’s his favourite game of all time. He steam messages his friend Tommy and asks if he’s gotten around to playing it. Tommy tells him he’s been waiting for a few years, because he wants to mod it up to the max on his first play through. Bobby sends Tommy a PC Gamer article on the best mods on Skyrim, and Tommy is like ‘woah, I think it’s time. This looks amazing!’

So Tommy buys the Skyrim + DLC bundle, and goes to town on Workshop. Subscribing to thousands of mods, he goes to load the game, and it crashes. So he spends another two days tweaking the load order, until he finally gets everything working and compatible. Has a play for a few hours. He’s in love. This is so much better than the base-game he’d seen on Twitch streams, the hollow husk of Morrowind that it was, and he was so glad he waited…

The next day, Bobby and Tommy log onto Steam, launch Skyrim and continue their game…

Wuh….?

After that, Tommy’s game loads up fine, but it soon becomes apparent that the vast majority of the mods he subscribed to had mysteriously disappeared.

Bobby’s 200 hour save though, so reliant as it was on the heavy substantial mods that had mysteriously vanished, was less fortunate…

g

Fuuuuuuuu-

After investigation, it becomes clear that to get everything Bobby had before, to get his save working again, he would need to spend some $150 extra to resubscribe to those mods. It’s about now Bobby gets a very angry Steam message from Tommy, who bought the game specifically expecting to be able to play with stuff that is now behind an additional $150 cost.

There’s a huge difference between asking for money for something new, and taking something away from someone and demanding money for its return. Despite feeling the mod developers equivalent work deserves the same opportunities I have had as an indie developer, I cannot possibly say that Bobby and Tommy here wouldn’t have an extremely valid reason to post an angry downvoted review on Skyrim. I think their anger is completely justified in this case. Bobby has lost 200 hours of progress in his game, and is having his save essentially ransomed for a cost higher than he paid for the original game. Tommy has just bought the game based on what transpired to be false pretences where the content that attracted him to the game is no longer actually available on purchase. The fact the content was not created by the developers themselves is irrelevant to the justified disappointment I think, yet these two guys are, as days pass since the Skyrim paid mods were removed, increasingly painted as unreasonable or entitled, that they don’t appreciate modder’s hard work, or think they aren’t justified in compensation. There is more at issue here than ‘paid mods’ and I think this is a bit of a simplification of why people are angry.

If this exact same thing were introduced with the release of the next Fallout or TES game, I doubt there would have been close to the amount of the backlash. Sure, there would be backlash. People would still get grumpy about it. But you’ve not actively snatched things off their harddrive out of the blue, you’re charging for a new thing they can choose never to pay for or play. It gives them a choice in the matter, unlike what happened last week.

There’s something quintessentially PC about modding. It’s likely one of the top reasons a PC gamer would give for why they love PC gaming. Despite mod authors often feeling under-appreciated, mods and modding is one of the biggest jewels in the crown of PC gaming, one of the most, not the least appreciated aspects of it, and people are very protective over that. To the point where it almost feels like paid mods is an oxymoron.

The developers of the game get a sizable chunk of the revenue share for doing nothing but making the game (and admittedly adding modding support, so kudos for that) but essentially with very little post-release resources compared to the mod author themselves. This is despite the (free) mods themselves having a big impact on the life expectancy of the game. It would seem to me like mod authors should be entitled to a more sizable chunk if we’re going to go down that road. Frankly with F2P, DLC, Early Access disappointments, failed Kickstarters and non-refundable digital purchases, game consumers are feeling increasingly disenfranchised or even exploited by the games industry, so its pretty much to be expected that there would be such an instantly hostile reception to this. Another aspect of PC gaming thrown behind a paywall. Right or wrong, warranted or no, I find it bewildering that everyone involved didn’t anticipate this exact reaction.

I have other concerns, for one that it will potentially lead to a massive decline in free mods, lowering the potential audience of modding in general to those with the disposable income, and this may have larger ramifications for the attraction of PCs as a gaming platform. If XBox had announced ‘Community DLC’ as a thing for their next console, I doubt it’d be as an attractive ‘platform seller’ as the wealth of free game moddability available on PC. I also feel kind of bad for all those PC gamers out there without much disposable income, who for all intents and purposes this would potentially cut their enjoyment of PC gaming significantly.

It’s a controversial move, and one I have very mixed and conflicting feelings both strongly for and against. I could be convinced it’s a brilliant thing for the health and vibrancy of modding scene. I could equally be convinced the move will slowly rot the modding scene from its very core, malign gamers to modding, and make mod communities a more demanding, expectant and hostile places when money starts to change hands. I’m worried modding will fall down the same public perception problem as Early Access has, a system we’re now aching to get out of due to the stigma it has attached to us. So a lot of my concerns about paid mods are how it would affect the modders, not just the gamers, or PC gaming in general.

In short though, I have no idea how this will turn out, if it’ll be a disaster or a success. I just think its clear that this experiment was doomed to failure from the start, and wonder a little why it wasn’t obvious upfront. Paid mods will happen though, this is clear to me now. It’s just a matter of when.

Posted in Uncategorized | 10 Comments

The Last Great Plight Of Humanity

There is a great evil in our times. Innocent people who just want to browse the internet in peace are made to suffer greatly on a daily basis, and we must bring a stop to it before it’s too late.

Every year, billions of people suffer from a growing epidemic of being slightly uncomfortable, cringing, or sometimes–in the more serious cases–suffering from all out being offended by something. It spreads on social media, but is also a danger down the local bar. Even between friends! Here are a few real life testimonies from sufferers of being offended.

“Hardly a day goes by when I am not subjected to brutal feelings of being offended. Sometimes it’s mild, and passes in a moment. Other times, however, it is literally like being a bit upset for a while and feeling angry. Sometimes my feelings are hurt to such an extent I have to step away from my PC for a while to take my mind off it. Every day I sit down and hope beyond hope that I can make it to nightfall without being offended by something, but I doubt we’ll see such a utopia in my lifetime. I’m just so worried that one day I will get so deeply offended my skull will be spontaneously crushed in on itself by the sheer injustice of it all.”

“I remember this one time I went on the internet, and someone from another country used a word that people in this country find offensive, Further, this monster ‘claimed’ the word to be completely innocent in their own country. It made me cringe. I don’t need to tell anyone how unpleasant and traumatic an experience a cringe can be. Since that incident I’ve found great difficulty in functioning in life. Culture and context do not matter. When will people FINALLY understand that if I’m offended, then that means it is NOT OK TO SAY?”

“This one time I was talking to a Brit in a bar, and he said he was going out to smoke a fag. I immediately called the police to warn them a homophobia motivated murder was about to take place. It turned out he was just outside having a cigarette. Those disgusting Brits need to learn that even in private conversation, they need to adhere to the agreed international standard in language and communication. AKA American.”

“I get offended by dancing. It’s crazy I know! I have no idea why, but whenever I see someone dancing I fill with intense rage and melancholy that lasts for weeks. I don’t know what to do. As far as I’m aware I’m alone in this, and after a lot of research on the internet it appears I need to find at least another 100 or so people who are also offended by dancing before it is morally acceptable to move or preach to ban it globally. If you are offended by dancing, please get in touch. Life is pretty much unbearable in the night clubs I frequent these days.”

Have a heart. Have a soul. Remember that comedy or humour should never tread in any area that could possibly be construed as offensive by any person on the internet. Since there are billions of people on the internet, you should play safe and say nothing. How would you feel if you knew your comments offended someone on another continent, possibly resulting in them feeling a bit upset for a while? We’re still awaiting our charity registration number, but soon we can all get together to fight people who aren’t us saying things on the internet that we don’t like–before it’s too late!!!!!!!

PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE PC MASTER RACE

1HGZIpg

Posted in Uncategorized | Leave a comment

Behavior trees for AI: How they work

Introduction

While there are plenty of behaviour tree tutorials and guides around the internet, when exploring whether they would be right for use in Project Zomboid, I ran into the same problem again and again. Many of the guides I read focused very heavily on the actual code implementations of behaviour trees, or focused purely on the flow of generic contextless nodes without any real applicable examples, with diagrams like so:

      image06

While they were invaluable in helping me understand the core principles of Behaviour Trees, I found myself in a situation where despite knowing how a behaviour tree operated, I didn’t really have any real-world context as to what sort of nodes I should be creating for the game, or what an actual fully developed behaviour tree would look like.

I’ve spent a ton of time experimenting (for the record since Project Zomboid is in Java I’m using the fantastic JBT – Java Behavior Trees (http://sourceforge.net/projects/jbt/) so didn’t have to concern myself with the actual code implementation. However there are plenty of tutorials out there focusing on this, as well as implementations in many commonly used game engines.

It’s possible some of the more specific decorator node types I detail here are actually native to JBT instead of general behaviour tree concepts, but I’ve found them to be integral to the way PZ behaviour trees work, so they are worth considering for implementation if your particular behaviour tree does not support them.

I’m not professing to be an expert on the subject, however over the development of the Project Zomboid NPCs I’ve found the results I’ve had to be pretty solid, so thought I’d bash out a few things that if I’d known would have made my first attempts go a lot more smoothly, or at least opened my eyes to what I could accomplish with behaviour trees. I’m not going to dig into the implementation but just give a few abstracted examples that were used in Project Zomboid.

Basics

So the clue is in the name. Unlike a Finite State Machine, or other systems used for AI programming, a behaviour tree is a tree of hierarchical nodes that control the flow of decision making of an AI entity. At the extents of the tree, the leaves, are the actual commands that control the AI entity, and forming the branches are various types of utility nodes that control the AI’s walk down the trees to reach the sequences of commands best suited to the situation.

The trees can be extremely deep, with nodes calling sub-trees which perform particular functions, allowing for the developer to create libraries of behaviours that can be chained together to provide very convincing AI behaviour. Development is highly iterable, where you can start by forming a basic behaviour, then create new branches to deal with alternate methods of achieving goals, with branches ordered by their desirability, allowing for the AI to have fallback tactics should a particular behaviour fail. This is where they really shine.

Data Driven vs Code Driven

This distinction has little relevance to this guide, however it should be noted that there are many different possible implementations of behaviour trees. A main distinction is whether the trees are defined externally to the codebase, perhaps in XML or a proprietary format and manipulated with an external editor, or whether the structure of the trees is defined directly in code via nested class instances.

JBT uses a strange hybrid of these two, where an editor is provided to allow you to visually construct your behaviour tree, however an exporter command line tool actually generates java code to represent the behaviour trees in the code-base.

Whatever the implementation, the leaf nodes, the nodes that actually do the game specific business and control your character or check the character’s situation or surroundings, are something you need to define yourself in code. Be that in the native language or using a scripting language such as Lua or Python. These can then be leveraged by your trees to provide complex behaviours. It is quite how expressive these nodes can be, sometimes operating more as a standard library to manipulate data within the tree itself, than just simply character commands, that really make behaviour trees exciting to me.

Tree Traversal

A core aspect of Behavior Trees is that unlike a method within your codebase, a particular node or branch in the tree may take many ticks of the game to complete. In the basic implementation of behaviour trees, the system will traverse down from the root of the tree every single frame, testing each node down the tree to see which is active, rechecking any nodes along the way, until it reaches the currently active node to tick it again.

This isn’t a very efficient way to do things, especially when the behaviour tree gets deeper as its developed and expanded during development. I’d say its a must that any behaviour tree you implement should store any currently processing nodes so they can be ticked directly within the behaviour tree engine rather than per tick traversal of the entire tree. Thankfully JBT fits into this category.

Flow

A behaviour tree is made up of several types of nodes, however some core functionality is common to any type of node in a behaviour tree. This is that they can return one of three statuses. (Depending on the implementation of the behaviour tree, there may be more than three return statuses, however I’ve yet to use one of these in practice and they are not pertinent to any introduction to the subject) The three common statuses are as follows:

Success
Failure
Running

The first two, as their names suggest, inform their parent that their operation was a success or a failure. The third means that success or failure is not yet determined, and the node is still running. The node will be ticked again next time the tree is ticked, at which point it will again have the opportunity to succeed, fail or continue running.

This functionality is key to the power of behaviour trees, since it allows a node’s processing to persist for many ticks of the game. For example a Walk node would offer up the Running status during the time it attempts to calculate a path, as well as the time it takes the character to walk to the specified location. If the pathfinding failed for whatever reason, or some other complication arisen during the walk to stop the character reaching the target location, then the node returns failure to the parent. If at any point the character’s current location equals the target location, then it returns success indicating the Walk command executed successfully.

This means that this node in isolation has a cast iron contract defined for success and failure, and any tree utilizing this node can be assured of the result it received from this node. These statuses then propagate and define the flow of the tree, to provide a sequence of events and different execution paths down the tree to make sure the AI behaves as desired.

With this shared functionality in common, there are three main archetypes of behaviour tree node:

Composite
Decorator
Leaf

image02

Composite

A composite node is a node that can have one or more children. They will process one or more of these children in either a first to last sequence or random order depending on the particular composite node in question, and at some stage will consider their processing complete and pass either success or failure to their parent, often determined by the success or failure of the child nodes. During the time they are processing children, they will continue to return Running to the parent.

The most commonly used composite node is the Sequence, which simply runs each child in sequence, returning failure at the point any of the children fail, and returning success if every child returned a successful status.

Decorator

A decorator node, like a composite node, can have a child node. Unlike a composite node, they can specifically only have a single child. Their function is either to transform the result they receive from their child node’s status, to terminate the child, or repeat processing of the child, depending on the type of decorator node.

A commonly used example of a decorator is the Inverter, which will simply invert the result of the child. A child fails and it will return success to its parent, or a child succeeds and it will return failure to the parent.

Leaf

These are the lowest level node type, and are incapable of having any children.

Leafs are however the most powerful of node types, as these will be defined and implemented by your game to do the game specific or character specific tests or actions required to make your tree actually do useful stuff.

An example of this, as used above, would be Walk. A Walk leaf node would make a character walk to a specific point on the map, and return success or failure depending on the result.

Since you can define what leaf nodes are yourself (often with very minimal code), they can be very expressive when layered on top of composite and decorators, and allow for you to make pretty powerful behavior trees capable of quite complicated layered and intelligently prioritized behaviour.

In an analogy of game code, think of composites and decorators as functions, if statements and while loops and other language constructs for defining flow of your code, and leaf nodes as game specific function calls that actually do the business for your AI characters or test their state or situation.

These nodes can be defined with parameters. For example the Walk leaf node may have a coordinate for the character to walk to.

These parameters can be taken from variables stored within the context of the AI character processing the tree. So for example a location to walk to could be determined by a ‘GetSafeLocation’ node, stored in a variable, and then a ‘Walk’ node could use that variable stored in the context to define the destination. It’s through using a shared context between nodes for storing and altering of arbitrary persistent data during processing of a tree that makes behaviour trees immensely powerful.

Another integral type of Leaf node is one that calls another behaviour tree, passing the existing tree’s data context through to the called tree.

These are key as they allow you to modularise the trees heavily to create behaviour trees that can be reused in countless places, perhaps using a specific variable name within the context to operate on. For example a ‘Break into Building’ behaviour may expect a ‘targetBuilding’ variable with which to operate on, so parent trees can set this variable in the context, then call the sub-tree via a sub-tree Leaf node.

Composite Nodes

Here we will talk about the most common composite nodes found within behaviour trees. There are others, but we will cover the basics that should see you on your way to writing some pretty complex behaviour trees in their own right.

Sequences

The simplest composite node found within behaviour trees, their name says it all. A sequence will visit each child in order, starting with the first, and when that succeeds will call the second, and so on down the list of children. If any child fails it will immediately return failure to the parent. If the last child in the sequence succeeds, then the sequence will return success to its parent.

It’s important to make clear that the node types in behaviour trees have quite a wide range of applications. The most obvious usage of sequences is to define a sequence of tasks that must be completed in entirety, and where failure of one means further processing of that sequence of tasks becomes redundant. For example:

image03

This sequence, as is probably clear, will make the given character walk through a door, closing it behind them. In truth, these nodes would likely be more abstracted and use parameters in a production environment. Walk (location), Open (openable), Walk (location), Close (openable)

The processing order is thus:

Sequence -> Walk to Door (success) -> Sequence (running) -> Open Door (success) -> Sequence (running) -> Walk through Door (success) -> Sequence (running) -> Close Door (success) -> Sequence (success) -> at which point the sequence returns success to its own parent.

If a character fails to walk to the door, perhaps because the way is blocked, then it is no longer relevant to try opening the door, or walking through it.  The sequence returns failure at the moment the walk fails, and the parent of the sequence can then deal with the failure gracefully.

The fact that sequences naturally lend themselves to sequences of character actions, and since AI behaviour trees tend to suggest this is their only use, it may not be clear that there are several different ways to leverage sequences beyond making a character do a sequential list of ‘things’. Consider this:

image08

In the above example, we have not a list of actions but a list of tests. The child nodes check if the character is hungry, if they have food on their person, if they are in a safe location, and only if all of these return success to the sequence parent, will the character then eat food. Using sequences like this allow you to test one or more conditions before carrying out an action. Analogous to if statements in code, and to an AND gate in circuitry. Since all children need to succeed, and those children could be any combination of composite, decorator or leaf nodes, it allows for pretty powerful conditional checking within your AI brain.

Consider for example the Inverter decorator mentioned in the above section:

image00

Functionally identical to the previous example, here we show how you can use inverters to negate any test and therefore give you a NOT gate. This means you can drastically cut the amount of nodes you will need for testing the conditions of your character or game world.

Selector

Selectors are the yin to the sequence’s yang. Where a sequence is an AND, requiring all children to succeed to return a success, a selector will return a success if any of its children succeed and not process any further children. It will process the first child, and if it fails will process the second, and if that fails will process the third, until a success is reached, at which point it will instantly return success. It will fail if all children fail. This means a selector is analagous with an OR gate, and as a conditional statement can be used to check multiple conditions to see if any one of them is true.

Their main power comes from their ability to represent multiple different courses of action, in order of priority from most favorable to least favorable, and to return success if it managed to succeed at any course of action. The implications of this are huge, and you can very quickly develop pretty sophisticated AI behaviours through the use of selectors.

Let’s revisit our door sequence example from earlier, adding a potential complication to it and a selector to solve it.

selector1
Yes, here we can deal with locked doors intelligently, with the use of only a handful of new nodes.

So what happens when this selector is processed?

First, it will process the Open Door node. The most preferable cause of action is to simply open the door. No messing. If that succeeds then the selector succeeds, knowing it was a job well done. There’s no further need to explore any other child nodes of that selector.

If, however, the door fails to open because some sod has locked it, then the open door node will fail, passing failure to the parent selector. At this point the selector will try the second node, or the second preferable cause of action, which is to attempt to unlock the door.

Here we’ve created another sequence (that must be completed in entirety to pass success back to the selector) where we first unlock the door, then attempt to open it.

If either step of unlocking the door fails (perhaps the AI doesn’t have the key, or the required lockpicking skill, or perhaps they managed to pick the lock, but found the door was nailed shut when attempting to open it?) then it will return failure to the selector, which will then try the third course of action, smashing the door off its hinges!

If the character is not strong enough, then perhaps this fails. In this case there are no more courses of action left, and the the selector will fail, and this will in turn cause the selector’s parent sequence to fail, abandoning the attempt to walk through the door.

To take this a step further, perhaps there is a selector above that which will then choose another course of action based on this sequence’s failure?

 

selector3

Here we’ve expanded the tree with a topmost selector. On the left (most preferable side) we enter through the door, and if that fails we instead try to enter through the window. In truth the actual implementation would likely not look this way and its a bit of a simplification on what we did on Project Zomboid, but it illustrates the point. We’ll get to a more generic and usable implementation later.

In short, we have here an ‘Enter Building’ behaviour that you can rely on to either get inside the building in question, or to inform its parent that it failed to. Perhaps there are no windows? In this case the topmost selector will fail, and perhaps a parent selector will tell the AI to head to another building?

A key factor in behaviour trees that has simplified AI development a huge deal for myself over previous attempts is that failure is no longer a critical full stop on whatever I’m trying to do (uhoh, the pathfind failed, WHAT NOW?), but just a natural and expected part of the decision making process that fits naturally in the paradigm of the AI system.

You can layer failsafes and alternate courses of action for every possible situation. An example with Project Zomboid would be the EnsureItemInInventory behaviour.

This behaviour takes in an inventory item type, and uses a selector to determine from several courses of action to ensure an item is in the NPC’s inventory, including recursive calls to the same behaviour with different item parameters.

First it’ll check if the item is already in the character’s main top level inventory. This is the ideal situation as nothing needs to be done. If it is, then the selector succeeds and thus the entire behaviour succeeds. EnsureItemInInventory has succeeded, and the item is there for use.

If the item is not in the character’s inventory, then they will check the contents of any bags or backpacks the character is carrying. If the item is found, then they will transfer the item from the bag into his top level inventory. This will then succeed, as the success criteria is met.

If THIS fails, then a third branch of the selector will determine of the item is located in the building the character is currently residing in. If it is, then the character will travel to the location of the container holding the item and take it from the container. Again the criteria is met, so success!

If THIS fails, then there is one more trick up the NPCs sleeve. It will then iterate a list of crafting recipes that result in the item they desire, and for each of these recipes it will iterate through each ingredient item, and will recursively call the EnsureItemInInventory behaviour for each of those items in turn. If each of these succeeds, then we know for a fact that the NPC now carries every ingredient required to craft their desired item. The character will then craft the item from those ingredients, before returning success as the criteria of having the item is met.

If THIS fails, then the EnsureItemInInventory behaviour will fail, with no more fallbacks, and the NPC will just add that item to a list of desired items to look out for during looting missions and live without the item.

The result of this is that the NPC is suddenly capable of crafting any item in the game they desire if they have the ingredients required, or those ingredients can be obtained from the building.

Due to the recursive nature of the behaviour, if they don’t have the ingredients themselves, then they will even attempt to craft them from even baser level ingredients, hunting the building if necessary, crafting multiple stages of items to be able to craft the item they actually need.

Suddenly we have a quite complicated and impressive looking AI behaviour that actually boils down to relatively simple nodes layered on top of each other. The EnsureItemInInventory behaviour can then be used liberally throughout many other trees, whenever we need an NPC to ensure they have an item in their inventory.

I’m sure at some point during development we’ll continue this further with another fallback, and allow the NPCs to actually go out specifically in search of items they critically desire, choosing a looting target that has the highest chance of containing that item.

Another failsafe that could be higher in the priority list may be to consider other items which may accomplish the same goal as the selected item. If one day we finally code in support for makeshift tools, then looking for less effective alternatives and hammering a nail in with a rock may trump sneaking across town into a zombie infested hardware store.

Due to the ease of extending the trees during development, its easy to create a simple behaviour that ‘does the job’, and then iteratively improve that NPC behaviour with extra branches via a selector to cater for more solid failsafes and fallbacks to reduce the likelihood of the behaviour failing. The crafting fallback was added much later down the line, and just goes to further equip NPCs with behaviours to further aid them in achieving their goals.

Furthermore if prioritized carefully, these fallbacks, despite being essentially scripted behaviours, bestow the appearance of intelligent problem solving and natural decision making to the AI character.

Random Selectors / Sequences

I’m not going to dwell on these, as their behaviour will be obvious given the previous sections. Random sequences/selectors work identically to their namesakes, except the actual order the child nodes are processed is determined randomly. These can be used to add more unpredictability to an AI character in cases where there isn’t a clear preferable order of execution of possible courses of action.

Decorator Nodes

Inverter

We’ve already covered this one. Simply put they will invert or negate the result of their child node. Success becomes failure, and failure becomes success. They are most often used in conditional tests.

Succeeder

A succeeder will always return success, irrespective of what the child node actually returned. These are useful in cases where you want to process a branch of a tree where a failure is expected or anticipated, but you don’t want to abandon processing of a sequence that branch sits on. The opposite of this type of node is not required, as an inverter will turn a succeeder into a ‘failer’ if a failure is required for the parent.

Repeater

A repeater will reprocess its child node each time its child returns a result. These are often used at the very base of the tree, to make the tree to run continuously. Repeaters may optionally run their children a set number of times before returning to their parent.

Repeat Until Fail

Like a repeater, these decorators will continue to reprocess their child. That is until the child finally returns a failure, at which point the repeater will return success to its parent.

Data Context

The specifics of this are down to the actual implementation of the behaviour tree, the programming language used, and all manner of other things, so we’ll keep this all rather abstract and conceptual.

When a behaviour tree is called on an AI entity, a data context is also created which acts as a storage for arbitrary variables that are interpreted and altered by the nodes (using string/object pair in a C# Dictionary or java HashMap, probably a C++ string/void* STL map, though its a long time since I’ve used C++ so there are probably better ways to handle this)

Nodes will be able to read or write into variables to provide nodes processed later with contextual data and allow the behaviour tree to act as a cohesive unit. As soon as you start exploiting this heavily, the flexibility and scope of behaviour trees becomes very impressive, and the true power at your fingertips becomes apparent. We’ll get to this in a while when we revisit our doors and windows behaviour.

Defining Leaf Nodes

Again, the specifics of this are down to the actual implementation of the behaviour tree. In order to provide functionality to leaf nodes, to allow for game specific functionality to be added into behaviour trees, most systems have two functions that will need to be implemented.

init – Called the first time a node is visited by its parent during its parents execution. For example a sequence will call this when its the node’s turn to be processed. It will not be called again until the next time the parent node is fired after the parent has finished processing and returned a result to its parent. This function is used to initialise the node and start the action the node represents. Using our walk example, it will retrieve the parameters and perhaps initiate the pathfinding job.

process – This is called every tick of the behaviour tree while the node is processing. If this function returns Success or Failure, then its processing will end and the result passed to its parent. If it returns Running it will be reprocessed next tick, and again and again until it returns a Success or Failure. In the Walk example, it will return Running until the pathfinding either succeeds or fails.

Nodes can have properties associated with them, that may be explicitly passed literal parameters, or references to variables within the data context of the AI entity being controlled.

I’m not going to go into the specifics of implementation, as this is not only language dependent but also behaviour tree implementation dependent, but the concept of parameters and storage of arbitrary data within the behaviour tree instance are fairly universal.

So for example, we may describe a Walk node as such:

Walk (character, destination)

– success:  Reached destination
– failure:    Failed to reach destination
– running: En route

In this case Walk has two parameters, the character and the destination. While it may seem natural to always assume that the character who is running the AI behaviour is the subject of a node and therefore would not need to be passed explicitly as a parameter, it’s best not to make this assumption, despite ‘Walk’ being a pretty safe bet. As too many times, particularly on conditional nodes,  I’ve found myself having to recode nodes to cater for testing another characters state or interacting with them in some way. It’s always best to go the extra mile and pass the character the command applies to even if you’re fairly sure that only the AI running the behaviour would require it.

The passed location, as stated earlier, could be inputted manually with X, Y, Z coordinates. But more likely, the location would be stored in the context as a variable by another node, obtaining the location of some game object, or building, or perhaps calculating a safe place in cover in the NPCs vicinity.

Stacks

When first looking into behaviour trees, its natural to constrain the scope of the nodes they use to character actions, or conditional tests about the character or their environment. With this limitation it’s sometimes difficult to see how powerful behaviour trees are.

It’s when it occurred to me to implement stack operations as nodes that their utility really became apparent to me. So I added the following node implementations to the game:

PushToStack(item, stackVar)
PopFromStack(stack, itemVar)
IsEmpty(stack)

That’s it, just these three nodes. All they needed was init/process functions implemented to create and modify a standard library stack object with just a few lines of code, and they open up a whole host of possibilities.

For example PushToStack creates a new stack if one doesn’t exist, and stores it in the passed variable name, and then pushes ‘item’ object onto it.

Similarly pop pops an item off the stack, and stores it in the itemVar variable, failing if the stack is already empty, and IsEmpty checks if the stack passed is empty and returns success if it is, and failure if its not.

With these nodes, we now have the capacity to iterate through a stack of objects like this:

image01

Using an Until Fail repeater, we can repeatedly pop an item from the stack and operate on it, until the point the stack is empty, at which point PopFromStack will return a fail and exit out of the Until Fail repeater.

Next, a couple of other vital utility nodes that I use regularly:

SetVariable(varName, object)
IsNull(object)

These allow us to set arbitrary variables throughout the behaviour tree in circumstances where the composites and decorators don’t allow us enough granularity to get information up the tree we require. We’ll hit a situation like this in a moment, though I don’t doubt there’s a way to organize it so it’s not required.

Now supposing we added a node called GetDoorStackFromBuilding, where you passed a building object and it retrieved a list of exterior door objects in that building, newing and filling a Stack with the objects and setting the target variable. What could we do then using the things we’ve detailed above?

image05

Eek. This has gotten a little more complicated, and at first glance it may seem a bit difficult to ascertain what’s going on, but like any language eventually it becomes easier to read at a glance, and what you lose in readability you gain in flexibility.

So what does this do? Well it may be a little bit of a head mangler at first, but once you become familiar with the way the nodes operate and how the successes and failures transverse the tree, it becomes a lot easier to visualise. If necessary I may expand this section to show the walk through the tree, if my description proves insufficient.

In short, it is a behaviour that will retrieve and then try to enter every single door into a building, and return success if the character succeeded in getting in any of the doors, and it will return failure if they did not.

First up it grabs a stack containing every doorway into the building. Then it calls the Until Fail repeater node which will continue to reprocess its child until its child returns a failure.

That child, a sequence, will first pop a door from the stack, storing it in the door variable.

If the stack is empty because there are no doors, then this node will fail and break out of the Until Fail repeater with a success (Until Fail always succeeds), to continue the parent sequence, where we have an inverted IsNull check on ‘usedDoor’. This will fail if the usedDoor is null (which it will be, since it never got chance to set that variable), and this will cause the entire behaviour to fail.

If the stack does manage to grab a door, it then calls another sequence (with an inverter) which will attempt to walk to the door, open it and walk through it.

If the NPC fails to get through the door by any means available to him (the door is locked, and the NPC is too weak to break it down), then the selector will fail, and will return fail to the parent, which is the Inverter, which inverts the failure into a success, which means it doesn’t escape the Until Fail repeater, which in turn repeats and freshly re-calls its child sequence to pop the next door from the stack and the NPC will try the next door.

If the NPC succeeds in getting through a door, then it will set that door in the ‘usedDoor’ variable, at which point the sequence will return success. This success will be inverted into a failure so we can escape the Until Fail repeater.

In this circumstance, we then fail in the IsNull check on usedDoor, since it’s not null. This is inverted into a success, which causes the entire behaviour to succeed. The parent knows the NPC successfully found a door and got through it into the building.

If it failed, the same process could be repeated with a GetWindowStackFromBuilding node, to repeat the process with windows. Or with a little stack manipulation with a few more nodes, perhaps you could call GetDoorStackFromBuilding and GetWindowStackFromBuilding  immediately after eachother, and append the windows to the end of the door stack, and process all of them in the same Until Fail, assuming that Open, Unlock, Smash, Close operated on a generic base of doors and windows, or run-time type checked the object they were operating on.

Finally, you may notice I’ve added a Succeeder decorator parenting the close door node. This is because it occurred to me that if an NPC smashed the door, they would no doubt fail to close it.

Without the succeeder this would cause the sequence to fail before the usedDoor variable was set and move onto the next door. An alternate solution would be for Close Door to be designed to always succeed even if the door was smashed. However, we want to retain the ability to test success of closing a door (for example using the node within a ‘Secure Safehouse’ behaviour would deem a failure to close the door because it’s no longer on its hinges as pretty pertinent to the situation!), so a Succeeder can ensure that the failure is ignored if that behaviour is required.

Posted in Uncategorized | 9 Comments