Wednesday, 18 October 2017

Making Berth in Manchester: Bullion comes to Play Expo

When Replay Events announced about a month before their flagship Play Expo Manchester event that there were a number of indie zone spaces available, it presented us with a difficult decision. On one hand, Play Manchester is huge, with great possibilities for getting both feedback and exposure for the game, and thanks to our previous titles we have a great relationship with the Replay team; but on the other hand, it was at short notice - organisation with team members and families aside, the new build absolutely had to be ready - or we would be falling back our old demo from GEEK which we knew to have bugs and missing a lot of functionality...


"Indie Alley" at Play Manchester
Bullion alpha v2 ready to go at Play Expo Manchester
All ship-shape and ready to sail...

As ever, the Replay team were superb. On the whole, communications were above and beyond the call of duty, which was pretty much the deciding factor in our going - a few days later and we would not have had the new demo ready in time! The only issue was the late release of the exhibitor packs, leaving us almost no time to organise logistics. The indie zone itself was located in a prime position, right opposite where the people queuing to enter would come in - once again, Replay Events following up on their commitment to indies, so a big thumbs-up there. Unfortunately, the venue impacts the atmosphere - Event City is essentially a huge metal box with bright lights for the most part, and despite the Replay team's best efforts, it is difficult to evoke that grungy retro-arcade feel. At least the public wi-fi was working this time!

Due to the eleventh-hour exhibitor packs, we had to set up on the Saturday morning before the show. Not content with committing to a new, relatively untried demo, we decided to really push the boat out and run on our old budget Lenovo laptop - we did have other hardware available, but we figured that a bit of initial humiliation was better than an accident with a newer box! At ten o'clock, the doors opened and we took a deep breath as a small horde of people flooded in...


There were a few more people at this one...

... and the new demo performed almost flawlessly! None of the crashes or "oh god, that's embarrassing!" bugs (cough-teleporting bulls!-cough) that had popped up in its earlier counterpart. In fact, the vast majority of the issues we came across were design related, and mostly in the placeholder-heavy areas, and by the end of the event there was not one single post-it note on the back of the pop-up banner! Once again, visuals and audio received high praise; it was just a shame that Matthew and Ben H could not be with us to hear it. Ah well, there's always next year...

Thanks to the great positioning of both the indie zone and our booth within it (second from the entrance end - score!) we were consistently busy, with the jewel in the crown for the event being when indie legend Jeff Minter, whose games we had grown up with, came over to play. We also had plenty of press contact, loads of great feedback, and some absolutely corking ideas as to how we could polish the game up. As ever, it was both hugely satisfying and fun to watch people playing, and how they play... for some reason, it feels like there is a ritual that the mums of families can do to become absolutely awesome at Bullion - by hesitating and protesting that "they are no good at games" before picking up a controller, they suddenly gain mad gaming skills...


Mums have mad skillz!

Achievement unlocked - play with a legend!

To sum up - a great event, hugely positive and progressive, and re-affirming that the game is moving in the right direction. However, we now need to up our game as best as possible in the development process as the question we got asked the most was the one that we could not answer: "When will this be released?"


Keep 'em alive, Paul!

Jupiter takes the bull by the horns...

Thursday, 28 September 2017

Walk the plank!

Recently, Steam - one of the platforms we have been considering for Bullion's final release - kicked out over 200 games.

Why? Because they were quickly-made, low quality hack-togethers from a single studio (operating under a variety of names), designed to try and game the system.

Good riddance to bad rubbish. But this once again highlights a problem that has been growing in the "indie" market for some time - and it is endemic to the stores.

Back in the mid 90s, when Bullion developer Ben launched his first game, it was released through a Public Domain library - essentially a mail-order service that any developer could submit work to, and effectively the forerunners of today's online stores. The P.D. library in question offered a promotion scheme - if you submitted a game to it, the game was reviewed and if judged good enough, it was put into the "promoted" section - it appeared in adverts for the library, was pushed for magazine reviews etc. If it was not good enough, it went in with all the rest.

The trick that made this work was that the developer had to decide whether or not they thought there work was good enough to pitch at the promoted section - the risk being that if you got it wrong, you were stuck in the bottom tier.

Obviously there would need to be a lot of adapting for scale, but this may be the answer to the current flood of shovelware in the indie market - while at the same time giving discoverability to great games that might not quite have the visual polish or the marketing connections of those in the absolute top flight. This is how it might work:

The store divides into a number of tiers, each with its own promotional channels:

  • Triple-I - effectively AAA, but not released through a publisher
  • Contenders - highly polished both in appearance and game quality, but not quite Triple-I
  • Mainstream - lacking polish, or using a significant number of pre-made assets
  • Basic - reskins, asset flips, prototypes and higher-tier rejects

To submit, the developer has to create a pack that includes a number of screenshots, a one-minute gameplay video (including in-game sound), a list of any pre-made assets used, and a brief pitch as to what tier they want the game to be listed under and why - this allows rapid screening out of games that are obviously trying to get into too high a tier. Games that pass this first step can then be further reviewed if deemed necessary. If the game is not accepted into its target tier, it goes in "Basic".

Obviously this approach will require the online stores to improve their curation process and, most likely, bring in dedicated review staff. But ultimately, it puts the onus on the developer to be honest with both the store and themselves - shoot too high and you're down in "Basic" with virtually zero chance of promotion.

Idealistic? Perhaps. But when you have two grizzled old sea-dog programmers in the crew who date back to a time before microtransactions, before game engines, before the internet, this sort of thinking tends to creep in...

Sunday, 10 September 2017

Refitting & Repairing

A full reworking of a lot of Bullion's core code was never going to be a small task, made only greater by our philosophy that "life comes first" - which we have had to take to heart recently...

Sadly, due to day-job requirements, we have had to say goodbye to Winter - at least for the time being. And Ben Hill is returning to the USA having completed his studies - the good news is that he is determined to stay with the team, albeit remotely. We'll raise a tankard to both of ye and see where the winds take us...

As for the good ship Bullion herself - barring a few fittings and fixtures, the big refit is done! The hacks are gone, and we have embraced a lot more of Unity's mechanics (as opposed to rolling our own versions) - it's been a great learning experience as well as an opportunity to tidy up. We've also upgraded a number of the placeholder components from the original pre-alpha demo version to something closer to the production-ready vision, and adding features based on the feedback we got at GEEK. So far, new additions include:

  • Upgraded player status displays in-game
  • Power-ups have production models and are now activated on demand by the player
  • New title and character select screens
  • Block and special attack moves for characters
  • Improved enemy AI

... and yes, we've fixed the infamous "teleporting dead cow" bug!

The "heart beat" is beginning to take shape - one of the first applications we're looking at plugging in will be controlling the enemies response to the players, factoring number of its bretheren killed versus proximity into determining which player a newly spawned enemy will target.

We've also had more outings to Gamecamp, WeGeek and Aylesbury Comic Con, and had lots more great feedback and ideas for new features - we've even had suggestions for new game modes and challenge stages, which could put a whole new spin on the vision of the game. And, just as at GEEK, we have had lots of favourable responses to the visual and audio style of the game, so we suppose we must be doing something right!

Next big date on the Bullion calendar - Reading Comic Con in November, where we hope to be taking the newly refitted Bullion on her maiden voyage... and no doubt covering more surfaces with post-it notes as more bugs emerge!

Friday, 21 April 2017

Shiver me Timbers!

So it's been a couple of months since we first let the public loose on Bullion at GEEK, and given we are still very much in a pre-alpha-preview state, the response was overwhelmingly positive: third place in the indie awards at the show was the icing on the cake, and since then we've seen a few write ups either of the event (with Bullion mentioned), or about the game itself (this one is probably our favourite).

However, as every game dev crew is aware, the chances are that when you let the public loose on your game, a whole load of bugs you never saw before will come up. By taking the pre-alpha of Bullion to GEEK, we decided to embrace this; not only would we get feedback on what people thought was good and/or bad, we would also be able to find and hopefully kill some bugs before they became real problems.

... or at least, that was the theory. And while there were no real showstoppers on the day, there were certainly a few more deeper-rooted problems than we anticipated - the infamous "teleporting dead cow" bug, for example - and Ben managed to cover most of the back of the pop-up banner with post-it notes detailing bugs.

So we have had to take a step back and are currently in the process of re-working some large chunks of the game: not just to fix the bugs, but also to clean up the code, get rid of the blatant hacks that were put in to get us over the line for GEEK, and make things more maintainable going forward. Ain't agile development fun?!?

But this is also giving us some great opportunities too - for example, alongside the big code refactor, we are also looking at game's "heart beat" - an engine that we hope will make the game respond to how the players are playing, and possibly even give us the foundations for a single-player campaign mode.

And the crew has grown too! Last year we were joined by audio designer Ben Hill (yup, another Ben, just to add to the chaos), whose sound effects and epic title track added a huge level of life and depth to the game, and following this year's Global Game Jam, 3D artist Winter Mraz has signed up to work with Matthew in giving the characters and world of Bullion their distinctive comic flavour.

There's still loads to do, but given the response we've had so far, we've got high hopes for the future, and GEEK 2018!

Saturday, 25 February 2017

The Maiden Voyage

Paul talks about GEEK 2017 - Bullion's first expo...

Back to reality, exhausted but satisfied from our fifth year at GEEK - a festival of gaming culture held in the tired but re-awakening English seaside town of Margate. GEEK is unlike other expos that we have presented at - with the emphasis more on the fun of participation and creation, the event has a stronger family-oriented theme than something like PAX or EGX. With LARP and cosplay, model-making and arts and crafts, pinball and video games new and old, there's something for everyone. GEEK is a family, and it shows in the love everyone has for what they are doing - from the Pac-Man ghost logo for the event, prominently displayed in bedroom windows, to installing Mario Kart in dodgem cars, this is clearly an event arranged by our kind of people.

The Indie Zone was placed directly inside the main entrance. This I feel was a mixed blessing. The prominence was great - rather than being tucked away in a corner, the indie games were right there as people arrived. This showed a great deal of trust and belief on the part of the organisers for which we are truly grateful, and spoke to the theme of GEEK being as much about the fun of making games as playing them. It meant that everyone came past us at some point and knew where to find us when they wanted another go. But there were drawbacks. Once people were past us, they might not return until they were leaving - tired and perhaps not in the mood for playtesting; so we'd need to be on ouir A-game when doors opened, and things would get rather quiet by mid-afternoon whereas in previous years it would be madcap until end of day. Standing on a hard floor all day near the open doors in February made for a chilly and tiring experience. The brightly lit corridor lacked the classic arcade feel of the dingy grunginess of the old Winter Gardens venue - our screens somehow not as enticing in the new environment. It felt off somehow to be so separated from the classic, retro and modern video games which were oddly divorced from the main action, hidden away in a separate hall that meant visitors had to walk outside through the closed-up Dreamland park to reach. I found myself acting as unofficial steward for the event, directing disappointed people towards what for many is the main draw of GEEK. Let's hope this didn't put too many visitors off for next year. I anticipate better signage or a change of layout in 2018.

GEEK was the first outing for Leda Entertainment's latest game Bullion, and the first event for our new teammates Matthew (art) and Ben (sound). Nothing beats watching the joy spread on the faces of people playing a game you created, but seeing Matthew and Ben's reactions to that - the enthusiasm with which they interacted with the public, and their delight at people enjoying their hard work - came a close second. It was great to see that the lessons we learned with Bopscotch - bright, loud, colourful, silly rather than gory - carried across to Bullion. It was rewarding to be placed 3rd in the "best Indie" public vote with Bullion at just its pre-Alpha stage, compared against released titles.

It’s not just about gauging the reception of the game with the public, though. Watching others play, you see things - bugs and features - you might not otherwise notice when you play your own game. The controller has 2 joysticks and a D-pad, which do I use? The sword is in his right hand, so clearly it's the controller's right shoulder button to swing it, yeah? Standing back and being an observer shows affords you the head-space to discover the things you thought were obvious but aren't. During the first day alone, we covered the back of our pop-stand with bugs we'd not spotted ourselves, and aimprovements suggested by the public or that came to us watching others play. The feedback we received was unanimously positive, and it was heartening that nobody put down a controller and walked away mid-game.

A highlight of GEEK this year for me was the incredible camaraderie between the Indie developers. In past years we might have looked on eachothers' games, had a brief chat about our journey and maybe played for a few minutes. This year, as well as that, we not only had banter on the trade floor, but we booked out a local restaurant for an evening of great conversation and fellowship.

GEEK was again an overwhelmingly positive experience, and I can’t wait to return in 2018.

Wednesday, 4 January 2017

Believable AI

In this blog post, Paul talks about the principles, and some of the techniques, behind Bullion's in-game AI.

We've all played games with bad AI.

Games where the computer players flawlessly pull off impossibly accurate shots at the first attempt. Games where the computer players win not by being better, but by being faster, having more resources, or where the odds are stacked overwhelmingly in their favour. Games where the computer-controlled characters work on a fixed pattern, with the same movement and behaviour regardless of what the human players are doing. Or games where the computer players clearly know more about the environment than the human players could (e.g. Locations of randomised treasure, which could not have been learnt from previous playings of the game, but imply the AI can access internal game data that isn't visible on the screen to human players).

It is important to us that the enemies and computer-controlled players in Bullion behave fairly and sensibly. We'll want the AI to control both the enemy characters and also to provide opponent players when someone wants to play the game on their own, so it’s important that the AI can play the game and feel like another human player, not like a machine. It needs to react to what the other players are doing. It needs to bear grudges and extract vengeance. It needs to set goals and construct plans to achieve them - but constantly review whether those goals are still both achievable and sensible, and if not re-plan accordingly.

Movement


It would be very easy for Bullion's AI to directly set the position of the characters it controls. It might not intentionally move at warp speed, but it could still behave unnaturally compared to other human-controlled characters. The solution to this is quite simple: the AI is given a "virtual joystick", so the way it controls its characters is essentially the same as the way the human players can control theirs. This also simplifies the game logic!

So it is up to the AI to track its own progress against its plan, and direct its characters to move in the appropriate direction.

It would be unfair if the AI could react immediately. For a person playing the game, it takes time for the brain to process what it is seeing, decide what to do, and make the appropriate muscle movements. The latter in particular is where the lag is most prevalent. Therefore the AI also has a "lag" built in so that it takes a small amount of time for its intentions to manifest into a change in the input controls. Without this lag, it can appear to human opponents that the AI had foreknowledge of what was going to happen, as the AI is already reacting whilst the human is still processing the change in game state.

Path Finding


The most fundamental part of the AI movement/plan execution process is moving around the play arena. The islands are covered with impassable obstacles - some permanent, such as the trees and rocks; some temporary such as the chests; and some mobile such as other players and enemies. Not all terrain is created equal, either - different surfaces can be traversed at different speeds; the bulls walk faster over grass than sand, and slower through marshy ground or in the sea itself. The AI needs to route its character around (or determine it would be faster to pass through, where possible) these obstacles on its way to reaching its destination, in an efficient manner. It also has to do this in a way that looks natural - it shouldn't walk directly towards its goal and "bump" its way around obstacles. It should look at the arena, decide on the best route from A to B, then walk along it - and re-plan if something happens along the way to change the optimum route.

Path-finding algorithms are easy to find on the Internet, but need to be adapted to the circumstances. You'd use a different approach for a twisty maze than for an arena that consists mostly of open spaces with the occasional obstacle. In Bullion there are few walls, but the playing area can become quite crowded with rocks, trees and treasure chests.

In Bullion we do this by laying an invisible grid over the playing area - squares, hexagons, or octagons tend to work well for this. We calculate a 'cost' for travelling through each grid cell - those with permanent impassable objects get a high score; others are relative to the time it would take to pass through the cell according to the type of surface. We then compute a cumulative "cost distance" of each cell from the target back to the character's current position, and walk back along the resulting trail. The trick is in implementing this efficiently, in choosing the right cell size, and balancing the cost parameters correctly. Make the cells too big and the character moves unnaturally; too small and it becomes too expensive to come up with a path, and the character will keep bumping into things.

Reactive Agents


The AI has no "secret knowledge" about the playing area - we only let it "see" what the players can see. That doesn't mean we force the AI to look at the rendered pixels and detect what's happening, or analyse the audio. If there is a sound effect to accompany a change in the game (e.g. A new enemy has appeared) we provide that information to the AI - but it is up to the AI to "find" that new enemy on the map, and to keep track of where it is going. We don't share the plans of different AI-controlled players and characters with each other, as that would be unfair.

The environment is constantly changing, so the AI needs to react. A chest has popped up on my course: do I route around it or smash my way through? An enemy is heading my way - do I ignore, avoid or confront it? Another player is approaching the treasure chest I was heading for - are they closer than me, should we divide the spoils, or should I pick another?

The AI is constantly validating that its current plan is still achievable, and is the most appropriate thing to be doing. As in nature, the AI is first concerned with its own survival - so if it is attacked, it will abandon its current activity to flee or retaliate. The action it takes will depend on its own speed, strength and stamina levels compared to that of the attacker - and also on any "history" between the characters. Enemies and AI players will have their own characteristics that help proscribe their behaviour - speed and stamina, but also more esoteric parameters: cowardice; prevalence towards thievery; curiosity. Should I go after that unguarded chest, hover near players already attacking chests, or go for that weakened player who's carrying a lot of treasure already? If a player is already being attacked by several enemies, am I better to join them and take my share of the spoils, or go after another player and risk trying to take them out on my own and claim all the booty for myself if I succeed?

The last aspect of a reactive AI is to provide a fair and proportionate opponent for the human players. Players don't really want to have to choose between "easy", "medium" and "hard" computer opponents. Instead, you want the game to detect the skill level of the human players and adapt accordingly. This needs to be finely tuned. As noted in the introduction, this shouldn't be done by biasing where treasure chests appear (starving a winning AI, or showering a losing AI with gold) - players would soon tire of such tactics which seem like cheating. The AI should attempt to create a level playing field amongst the characters, to make the fight and the challenge as equal as possible. This might mean that an AI player that has gathered far more treasure will spend more time hunting enemies, and a losing AI might decide to go after more chests or attack a hugely-scoring player.

Whatever the AI decides, it needs to feel natural to other players - and not just pace on the spot, or pointlessly commit suicide-by-shark, while waiting for human players to "catch up". No-one likes being condescended to. This isn't a turn-based game such as chess or pool, where one might expect the AI player to be "perfect" and any deviation for that would seem comical (such as the AI hugely missing an easy shot to give the human opponent a chance) - open-field play such as Bullion offers more subtle ways of levelling the playing field.

Above all: play fair, because that's what's fun.

Sunday, 23 October 2016

To Your Stations!

Having announced our first playable character - Captain Long John Silverside - last month, and with the second coming soon, we thought it we should introduce the crew actually making this thing! At this time, our crew comprises of:

  • Matthew Isteed: Graphic designer, artist, 3D modeller & animator
  • Paul Harman: AI designer & programmer
  • Ben Pritchard: Game designer, game logic developer & post-it note wrangler (we'll explain!)
It's early days yet, but we're hoping to add at least a sound/music specialist to the team as we progress.

Bullion is the first project for which we've had a dedicated artist. In fact, it's the first time we've worked on a project as a team - previous Leda Entertainment titles have tended to be almost entirely the efforts of either Ben or Paul (including the artwork), with the other helping out if/when needed. On top of this, it's also our first project in Unity, so we've had a number of organisational challenges to resolve.

Our solution (well, Ben's solution)? Cover every available surface in post-it notes.



This is relatively tame - there have been pub booth walls, train windows... pretty much every planning session has involved more post-it notes. Okay, there's trello and the like online (which we do use as well), but (according to Ben) "there's something really satisfying about being able to take down a post-it note and adding it to the 'done' pile"...

Mild obsessions aside, we've found that good communication and a "slow agile" process is keeping things under control pretty well - we meet up about once a month (excuse to go to the pub! Yay!), review where we are and plan the next month. Rinse, repeat. On top of this, we normally have a couple of one-to-one sessions per month (which generate the bulk of the post-it notes!), and anything on top of that is via email, skype etc.

Marshalling the actual game itself has also thrown up it's own challenges. Github is the weapon of choice for our developers - but we quickly learned that Unity does not play nicely when it comes to merging scene changes! Unlike code and other text files, the .unity scene files cannot be compared for differences (or at least, we've yet to find a tool that gets us round this), so it's either take version A or version B - fortunately, there;s very little crossover in these files, and good communication has meant very few problems so far...

In short - we've all had to learn a lot very quickly, but it seems to be working for us!