Heya everyone, Dani here again... but only for a bit. Our Kickstarter campaign has about a week left, so please head on over there if you haven't already.
This update will actually be in the hands of James (the developer, who handles the techy side). First off, thanks so much for all of the support! We are just around the corner from reaching the goal, so please keep spreading the word and we can push through :)
To help things along, I'm also happy to announce a special print add-on for our Kickstarter campaign.
Small Print - An 8.5" x 5.5" art print! ((Note: This is not the final version, I will be doing several versions and a vote will decide the most popular TWO to print. So if you get two of these add-ons, you will get both different prints)).
Also, we just made it into the top 10 on steam greenlight, so things are definitely moving in the right direction!
Anyhow, take it away James.
............
Outside of the amazing artwork and beautiful music of Bloom, there is something equally impressive and it’s almost invisible unless you know where to look. Because this is a passion project, every team member has poured their heart and soul into Bloom – and I am no different.
I am James, the lead (and only) developer. My job is building the game engine; to pull all the amazing assets together to create the game.
While many programmers view code as a means to an end, a tool… I see it as an art form. To produce beautiful code, to achieve the impossible, to turn a bunch of unconnected stuff into an amazing experience for the player.
The Core:
When I joined the Bloom team, I was given an EXE of the existing game engine. It was fairly ‘complete’ but had a long way to go. There was also a bigger issue. The previous coder had never given over source code and then disappeared. In a way, this was more to my liking. I could do this *my* way. Properly.
The core of Bloom is a totally custom engine termed ‘bloomCore’ based on monoGame. I chose monoGame partly due to experience with it and XNA, but mostly because of how portable it is without it defining how you work. Outside of the ‘game loop’, monoGame lets you do things however you like – and then will work on just about every platform you can imagine – good for a small team to keep in mind.
Our new engine, created over the period of around 7 months (and ongoing) is designed to be totally flexible. It supports our own custom scripting language (called ‘brainWorm’) that binds events. We have a complete ‘actor’ system where anything on the screen is an actor. We tell the actor which ‘character’ they are playing, such as ‘main character’ or ‘archer guy’ and then with the AI, player control and script control, we tell them what ‘act’ they are playing, ie ‘walking’ or ‘investigating’. This actor system is super flexible and extendable.
Also pretty amazing is that the engine that drives all this is totally autonomous. When building out levels, new characters etc, we don’t need to concern ourselves with things like organizing animations, events etc – everything just works – and this is a theme throughout the project.
The Tools:
To go along with this actor system we have a tool that automagically takes the output from maya, trims it to eradicate wasted space, create config files, rename, convert to WEBP format (like png features, but with jpg sizes) and then pack it into our custom format.
Once we have run through this tool, the assets are ready to ‘use’ but still need some love. For this, we have the character editor. This tool allows us to set alignments, hit areas, animation event triggers – all sorts of fun!
And just when you thought we had dealt with everything character related, we have the mob placer tool. This allows us to place mobs – but the level of control is awesomes. We can set AI systems (we have several), scale of the character, their default ‘act’, if they block the player and so on.
The end result of these tools is that most of Bloom can now be created without programmer input – I’ve created systems and tools that are super user friendly and flexible meaning Dani has the power to just convert the ideas into gameplay – no limits from our engine.
The Code:
Beyond that, I’ve ensured the code is written in the way that everything is modular, reusable and easy to understand should another programmer come on board. While I don’t expect this to happen, it means whenever I need to rework something, add something or such, everything is instantly obvious. A great example being when I added the advanced AI system, I first programmed a prototype. Once that worked, it took less than 20 mins to get it in Bloom and being used. Beautiful code is something no one ever sees – and most games don’t have the luxury – but when you can achieve it, the benefits are many fold. If anything, just for the self pride!
The Graphics Core:
Something that isn't invisible is the graphics, everyone sees that – but often they don’t appreciate what is behind the scenes. Bloom is a TRUE 2D game, despite where the graphics come from. Despite this, like a lot of 2D games, we have 3D effects… just about everywhere. We have an offset above view, so objects stack vertically – we also have several layers of trees – and even multiple heights that mobs can exist (underfoot, standard and flying). That itself has been host to immense challenges.
We also have some pretty clever graphics tricks that are mostly hidden in the demo. Some are partially visible, like the pixel shaders on the trees, simulating the breeze or on the water rendering out water flow.
Then, we also have a fairly complex particle system. We started out using mercury particles but in the end decided to roll our own for portability sake and you’ll have to trust me on this… It looks amazing.
Beyond that, we have an on demand image loading system that streams content as required, and as memory gets short, things are unloaded as no longer required. This kind of memory management is rarely seen in games (GTA being one of the exceptions) and means specs are low and loading times don’t exist.
The Audio:
The audio engine is the least mature of all of our systems but already has some pretty special stuff in it. It can handle mp3 files without external dependencies (great for multiplatform), the music handles interactive fades and has provisioning for true dynamic music and far far more.
Personal Joy:
For me, Bloom has been an amazing experience, and it’s only going to get better – I’ve had the freedom to concentrate on doing things well rather than doing them quickly. And time and time again, this has paid off. And hopefully, with kickstarters help, I can hopefully work on Bloom for a few months without worrying about anything else. And that will be mind blowing.
.............
As you can see, everyone on the team is pretty passionate about what they are doing. We are creating our own path, with your help. Thanks so much for the support everyone, and lets make something special :)
