Sunday, 24 June 2018

Going Krackerz!

The Bullion team is growing again! We are very pleased to welcome aboard new crew members...

This has been a huge boost to the team - we have been wanting to add more artists to the line-up since GEEK 2017, and as with Matthew and Ben before them, we feel very lucky and privileged to be working with such talented people.

On top of this - as those who have been paying attention to our social media will know - we will be exhibiting Bullion at Replay Events' new Play Expo London in August! We are very excited about this, and since our new artists came over as being so enthusiastic, we decided to drop Stuart in at the deep end and give him the first Bullion boss battle to design... which ended up with Cap'n Krackerz - an undead pirate parrot!

Raised from the dead to bring the wrath of the gods down on our bovine buccaneers...
Of course, this brings with it a host of new challenges, not least being how to integrate a boss battle into a game where the basic idea was to grab the most treasure in a timed round...

For the boss battle we decided to do away with the timer, but otherwise, the basic premise remains the same: be the one with the most treasure at the end of the round and if the whole crew wipes out, the round ends with no winner. To push the players towards fighting the boss, we set up the boss's health bar with a number of units - the player who scores the hit which completely depletes a health unit gets a big, fat treasure reward which - unlike the smaller treasures - cannot be stolen by other players. The stick to this carrot is that the boss's attacks will gradually increase in damage over time, so the longer the boss is alive, the greater the chance of the crew wiping out becomes. So once again, our players are faced with the choice: do they collect treasure? fight each other? fight the boss? Compete or collaborate - the key concept behind Bullion's gameplay.

"BFD"s (big fat diamonds) drive both the boss sequence and the player actions
As expected, the boss battle has brought a host of new coding challenges: Krackerz has multiple "special moves", including summoning minions and projectile attacks (what, you thought that cannon under his arm was just for decoration?) which his AI has to be capable of choosing, and then the game front-end has to deliver. The latter of these has actually proved a lot more straightforward than anticipated, largely thanks to the massive rebuild that took place after last year's GEEK - once again, time well spent! Similarly, following the debut of our computer-controlled players earlier this year, we are expecting to see similar returns on the planning and effort that went into building the AI framework.

Meantime, Deanna has taken on the job of taking the Salty Swamp stage from the current placeholder-heavy demo version up to production-ready. Building the island arena stages presents its own unique challenges, which we will be looking at in a future post - along with some before-and-after and other showcase images.

So - exciting stuff! And while we don't want to count our parrots... sorry, chickens! before they've hatched, we're pretty confident we'll have a boss battle to show off at Play London... and maybe a few other additions besides!

Friday, 30 March 2018

Software Pirates, Bullion Style!

Paul discusses the updates and improvements to the AI since the last blog post...

It's been just over a year since the last posting about the AI. Since then we've learnt a lot more about how Unity works; we've had several planning sessions about how we want the AI characters to react to in-game events; and we've substantially rewritten the player framework.

During the events we demonstrated at during Autumn 2017 (Play Manchester and Reading Comic-Con) it became clear that we needed to have the player AI ready in time for GEEK 2018. This was partly so that single players could enjoy Bullion, but also so that the game could demonstrate itself to people walking round the event rather than being just a title screen, or needing us to play it. People are attracted to activity and want to see what the game is like before sitting down to play: crowds would gather to watch other players but not to watch the title screen. Having the game play itself would attract people whlist leaving us free to talk to expo guests, press, and anyone else interested in the stand.

Show me the way to go home...

An early casualty of our learning experience with Unity was the AI navigation subsystem. We were in any case having some difficulties with the grid-cell-based algorithmic approach outlined in the previous blog post - it looked slightly unnatural. Shortly after writing the post, we discovered Unity's NavMesh and NavMeshAgents which made our code somewhat irrelevant! So part of the player character refactoring was needed to introduce NavMesh behaviour into the AI player characters and the enemy characters. The net result was smoother behaviour from the AI players and smarter rerouting when obstructions such as chests popped up into the AI player's path.
This highlights one of the benefits from our agile development approach - we learn as we go, prototyping new behaviour and swapping in new components as needed or as discovered. (For example, we're making a similar change now to use the ReWired controller manager rather than Unity's own controller mechanisms).

Different engines for different behaviours

Another change we made was to separate the enemy and player AIs. We decided that the range of behaviour for enemies was significantly different to that of the players, so splitting them out would avoid compromising one for the other. Perhaps we will re-integrate them in the future, particularly when we start considering the behaviour of the Island Gods characters in the boss battles.


How an AI pirate thinks...

Enemy AI is quite simple - choose a player to target, chase them down, and kill them, then re-target. The choice of target can be based on proximity, on which player has the most kills, or on which player has the most treasure; each enemy type will use a different blend of these parameters. With the newer enemies on Salty Swamp we're also introducing a "run away" dynamic (if they are ganged up on by the players) - which required the development of a proximity detector that will prove useful for other player AI behaviours. The current enemies are simpler than human players - they don't become ghosts, they can't swim, they don't have Bull Rush, they don't collect treasure or use power-ups. Rebuilding the enemy AI first, using NavMeshAgents for navigation, proved an important precursor to tackling the player character AI.

Player AI developments


Fight, flight or something else?

No code was taken from the GEEK 2017 player AI into the 2017-18 development phase, but the concepts have all carried over. We started with a cleaner codebase rid of the bugs on the infamous "popup of post-its", and freshly built on top of the new player framework. The ghost behaviour is split from the live character behaviour; ghosts have no need for AI behaviour since all they do is return to their respawn point.

So the AI is part reactive and part plan-oriented. Firstly if the player finds itself in the water it will abandon any existing plan and instead get back to dry land (which will need fine-tuning when we introduce environments with multiple islands where the player will need to risk swimming from one to the other). Then, if it has no current plan, it will create one; and it will then follow that plan until completion, until the plan is no longer viable, or until it gets interrupted.

A typical plan involves choosing an appropriate target, moving into proximity of that target, and then (depending on what type of target it is) either collecting it or attacking it, and then finally collecting any treasure released by that target when it was destroyed.


What does an AI want the most?

Targets are managed by the game framework. Anything we want to be targettable - treasure, chests, enemies, other players, power-ups - contains a component derived from a parent 'targettable' interface. We can then find and manage pools of targets of various types. It's then up to the AI to look at these pools of targets, how far away each one is, and assess the risk/reward balance for approaching each. Simplified, the algorithm for ranking targets against eachother is (reward - risk)/(distance + difficulty)
  • Reward: The simplest reward is tangible: how much treasure will I gain by choosing this target? This is known for loose treasure; we can guesstimate for players (the richer they are, the more they drop if they die); and we know on average how much we can get from chests and enemies. But there are other rewards. For me personally: Is that power-up valuable given my current situation? And for the team: Is the enemy count building up to an extent that presents a danger of stalemate if all the players die?
  • Risk: Should I attack a player or enemy if they have significantly more health, speed or strength than me? Are there other players/enemies guarding my intended target?
  • Distance: the longer it takes me to get to a target, the less appealing it should be. Firstly, while I'm walking to a target I'm not collecting treasure; secondly, the target may have moved or been taken by another player by the time I get there.
  • Difficulty: picking things off the ground is effortless. Smashing chests takes time, and attacking enemies or other players takes longer still depending on their health and defensive capabilities.

Alpha/Beta testing

We actually developed 2 plan choice algorithms. The first algorithm was fairly simple - it chose the highest scoring plan every time, and it had a strong bias towards targetting richer, weaker players. In initial team testing this felt too difficult to beat (3 AI players all relentlessly tracking and attacking a richer human player), especially given the players at the expo would be new to the game. So we developed a second flavour that would more randomly choose between a range of behaviours, and would try to avoid joining an existing fight. The team played both but eventually decided that the second cut of the algorithm was too 'cowardly', so we took the original blend to the expo. If we'd had more space on the stand we might have run both and taken feedback from the users, but as it was we limited our A/B test to just the team. We're now revisiting the second algorithm and adjusting the balance, as it better lends itself to the player characteristics for the different crew members.

Power-ups

Sometimes, chests contain power-ups - extra speed, more health etc - which affect the gameplay. The AI now spots these on the map and collects them as it would loose treasure. It then has to decide when is the best time to use the power-up without it being wasted. No point triggering the extra strength power-up if we are a long way from our attack target; the extra speed power-up would be more useful in that instance. The extra health power-up shouldn't be used when we're already pretty healthy. Should I save the Voodoo Curse for when I'm under sustained attack from multiple enemies? Do I use the resurrection Water of Life chalice when I'm critically low on health, or should I allow myself to die (so the enemies choose a new target), escape as a ghost, then resurrect myself - or just walk back to the restart point if it is nearby?

No plan survives contact with the enemy

The AI is constantly monitoring its plan to make sure that it still makes sense. If another player takes the treasure/chest we were going for, or if the player/enemy we were chasing is killed by another player, we need to re-plan. Changes in the environment can also affect our plans. If we're going after a chest and a new batch spawns close to us, maybe we should switch to them instead. Similarly if we are culling enemies, a closer target might present itself. Opportunities might open up as we travel across the map - if we are passing close to some loose treasure or a power-up, we should collect it. Or we might be attacked, in which case we should switch plans to either run away or stand and defend ourselves. The best defence of course being offence! So the AI has hooks into events fired by chest/enemy spawners to be told a new potential target (or threat) is on the scene, and oversized colliders envelope the AI player to notify it when potential threats and opportunities have come within range.

Reacting to environment changes is an an area in which we want to make the AI more human-like. Humans take time to notice and to react to changes, which the AI could detect immediately. We want our AI to have more human-natural reaction times so that it plays more like a person would play. To do this, we are using the Unity Coroutines feature - which defers the handling of those incoming events by an appropriate lag period.

Developing a personality

Currently all the AI players perform the same way. They judge threats and rewards using the same algorithm with the same parameters. The differences in actual in-game behaviour arise because of environmental factors - where the treasure and threats are relative to each AI - and due to a small amount of randomisation when choosing which of the high-scoring plans are going to be executed. This works for us since currently all of the AIs and human players are controlling the same character - Captain Long John Silverside - so there's no distinction necessary.

However, work is ongoing in the current development phase to add more of our pirate cast and crew to the game. So we are preparing the AI so that it will take the personalities of the characters into account. Each pirate will have its own metrics - moving speed, attack strength, etc - which should affect the decision-making process: can I outrun, or catch, my target given our relative moving speeds? Who is more likely to do more damage to whom if we fight? Does my character have a grudge against the other character? So we are borrowing 'player stats' concepts from role-playing games, and the AI will 'roll against' those stats when making choices about how it will react to changing events, and when making new plans.

Each member of the crew will have its own special move for attack/defense. They could also all use the signature Bull Rush move to charge and take out a row of targets in front of them. Currently the AI doesn't use either of these game features. We will be adding logic to detect when each of these would be most useful - e.g. do I have multiple targets in the attack zone for my special move or bull rush? This is likely to make more use of Unity colliders. There is also the Block capability for defense. The AI should consider whether Block will help - triggering it before it is attacked so that it is effective, and knowing when to release it to counterattack or to flee.

So there's a lot of work going on in the AI over the next couple of phases of Bullion development - not to mention the boss-battle AI for the Island Gods characters! We hope that all our efforts result in a more enjoyable game for you to play!

Sunday, 25 February 2018

Back to Maaaarrrr-gate - GEEK 2018 in review

Lead artist Matthew's thoughts on Bullion's second visit to GEEK expo...

Bullion is back from GEEK 2018, held at Dreamland in Margate, Kent. For Bullion’s second outing at GEEK, we were greeted by some familiar faces at the indie dev area, as well as a few newcomers. This year, Bullion brought a plethora of new features to the event. For starters, we have a second playable map in development, Salty Swamp, which players could test out along with Paul’s magnificently clever AI players, allowing individuals and smaller groups to get the full Bullion experience for the first time. We also debut an overhauled menu screen, featuring my pirate ship model.


Our little bit of GEEK...

With the stand set up Friday morning, I took a glimpse at the entrance to see a queue right up the hill, almost onto the street! Players of all ages flocked to the stand to try out Bullion. Young players were grasping the gameplay quickly, and with some brief explanation from us, even less gaming-inclined parents were picking up the controls and having fun with their families, and occasionally grabbing surprise wins over their kids!


First "full crew" of the day

Paul preps a crew for action

Unlike the publically untested build from GEEK 2017, this version of Bullion proved much more stable, with only a few minor technical issues, most quickly vanquished by Ben in the evenings while the event was closed.

The indie people’s vote returned once again, and despite competing against more than 10 titles, most much closer to release, we still scooped 3rd place like last year! Even with the friendly competition between titles, the indie developers were very supportive of their fellow creators, trying out and giving feedback on each other’s games, as well as going out for dinner together on the Saturday night like one big indie family.

Bullion continued to prove popular all weekend, with players bring along friends to experience the game, guests from last year returning and remembering us, and even small queues and crowds forming, waiting patiently for the next round. It is incredible to see that Bullion can hold attention this well, with less busy games, an amusement arcade, and even Nintendo game setups not proving enough to distract them from trying Bullion.


We got the Stormtroopers' attention...

Young buccaneers take on Salty Swamp

Our guests provided valuable feedback on the game, letting us know what they enjoyed, and any suggestions they had. We were glad to see that most critique we received is already in the pipeline to be dealt with, such as requests for faster movement already planned for the faster moving Bovy Jones, our next bovine buccaneer to be playable.

We knew that Bullion was on the right track when we saw how often players would sit and enjoy multiple matches. Not just kids, but kids at heart, parents and fellow developers all were invested enough to go for rematches against their friends and our computer-controlled cattle corsairs.


Age doesn't matter - smiles do!

Our 6th GEEK - awesome as ever!

With plenty of praise, much fewer bugs experienced, and lots of happy players of all ages, the Bullion team set sail for home from another successful GEEK show. Seeing how much joy the game brings to players young and old makes all our hard work worthwhile. With our most common question being “When will this be released?” we are dedicated to continue developing Bullion, with lots more content planned, including new characters, new maps and modes. Our ride home was filled with brainstorming for the next phases of development, and we are just as excited as the players to see what we can get ready for next year, as well as any other shows Bullion may visit in 2018.

Massive thanks all around to the GEEK hosts, Dreamland’s staff, our indie developer family, and most of all the players who took the time to give Bullion a try.

I’m looking forward to GEEK 2019 already!

This year marks six consecutive years of Leda Entertainment exhibiting at GEEK Expo - once again, thanks to all the amazing people who work so hard to make it happen!

Tuesday, 2 January 2018

Setting Course for 2018!

As we boldly voyage into the waters of 2018, it's time for a good old review-and-reflect on what last year brought us, and hopes for the year ahead...

Last year was Bullion's debut year in front of the public - okay, we announced it back in September 2016, and for about two-thirds of the year we we running on what was effectively a prototype of the first island, polished up and wrapped in enough placeholders and hacks to be demonstrable. But the feedback we received from the various events we showed it at proved that the "slow-agile" process is working; we have been able to revise our plans and expectations on the run and continually improve both the concepts and the technical sides of the game (even if it did mean several large rewrites of the code!)...

GEEK was definitely a highlight of 2017, and also where we started realising just how fortunate we were having Matthew and Ben H on board; both stepped up and ensured that we had all the 3D art, animation and sound/music assets required to get us demo-ready, and then joined us on the stand at the show. And despite a large number of bugs being found (prompting the largest of the aforementioned rewrites), pretty much everyone who played that first demo had only positive things to say. Taking third place in the show's Indie Awards was an added bonus!

Our other "big" show of the year was, of course, Play Expo in Manchester, by which time we had had a chance to address all the issues that had come up at GEEK (albeit by the skin of our teeth), and also start replacing some of the placeholder sections with more finalised work. Again, loads of great feedback, and we fulfilled a long-standing dream when Jeff Minter - creator of games that inspired us back in the 90s when then-Ledasoft Developments was first starting out - came and played. It was just a shame that Matthew and Ben H could not be there this time, but given the situation (Ben H having returned to the USA and the short notice of the decision to go), it was not a surprise. Maybe this year...

We also had a number of smaller events: WeGeek in London resulted in a highly-polished video interview, and Reading and Aylesbury Comic-Cons gave us a chance to catch up with Noaksey - indie affectionado extrodinaire and friend of Leda Entertainment since our breakthrough with Bopscotch at GEEK 2014. These smaller shows were no less valuable than the "big" ones as they offered plenty of opportunity to network with other developers, and also spend time chatting with those who had played the game, getting more detailed feedback to fuel the next wave of development.

However, 2017 also brought its share of frustrations, mainly related to the speed that the project is going at and team communication. Bullion is Leda Entertainment's first 3D project, and by the start of 2017 we had already learned enough to significantly revise our rather insane initial expectations (four fully animated characters and two islands in six months!) into something more realistic. But thanks to the team maxim off "life comes first", we ended up having to re-plan in such a way that various pieces of work were left dangling in limbo, rather than being completed and plugged into the game. Nobody's fault, but none-the-less, very frustrating, especially when the most-often asked question at the expos had been "when will this be coming out?". At the same time, we had also realised that we were going to need to find Matthew some assistance, and we do have a number of other artist/animators in various states of engagement with the project - but with the high bar set by Matthew's work to date, it is proving challenging to meet that need! Again, maybe this year we will get a breakthrough...

Life events had a huge impact on the team: Ben H had study commitments for a number of months in the first half of the year, following which he ended up having to return to the USA - however, he had made it clear that he is determined to stick with Bullion and is just waiting for his situation to settle down... once again, we realise just how fortunate we have been with those working with us on Bullion! And similarly, Winter's job situation meant she has had to step back before she could really get involved - so that's another hope for the year ahead: that she will the able to join back in at some point. Add in family, health and other employment/work related issues, and 2017 ended up being considerably more challenging than anticipated! But once again, the slow-agile process has allowed us to revise our plans and keep things moving.

So what's next? Well, GEEK 2018 is looming on the horizon, and once again it looks like it will take a big push to get the next round of features ready in time... but we will keep on adapting, revising and updating, and see just what can be done in the six-and-a-half weeks we have left. In the longer term... well, hopefully we will have the people in place to pick up the pace and forge ahead into 2018. Ultimately, we hope to have some kind of early-access preview available at some point this year... here's hoping that the winds and tides favour us!