BattleJuice Alchemist News

Hey folks,

we won an Emerging Talent Award sponsored by AMD at the the World Trailer Awards last Sunday! I'm really happy and proud about this great mention.



Technically the award was for our latest gameplay trailer, which I realize is quite outdated, but I'll get to updating it once we are feature complete. But the jury said that while awarding the gameplay trailer, it was our cinematic trailer that first caught their attention and they really liked it. It has been around for a while, but I never really talked about it in a devlog, so let's catch up on that!

[previewyoutube][/previewyoutube]

First of all, this cinematic serves double duty as both our cinematic trailer and as the intro cinematic for Act 1. There will be three more of these: two in between acts and one at the end of the game.

What I am probably most asked about is the voice acting. Our narrator is the incredible Dave LaChance, who also voiced our latest gameplay trailer. When searching for a talent, I got dozens of audition recordings, which I hadn't expected. Dave's was the one that I instantly fell in love with. It turned out that on top of that he is super professional and the most pleasant person to work with. So I'm really glad I got to work with him and will again in the future.

The second aspect of the cinematic that people seem to like a lot is the pop-up book.



The reasoning behind the concept was a quite pragmatic one. It allowed me to rehash in-game assets but present them in a unique and interesting way. When revising the cinematic, our illustrator Patrick helped me out with polishing the textures of the pop-up book pages. This was also an essential step for us to give Patrick a chance get familiar with the general visual style. Patrick can now create illustrations in the same style out of thin air and does not necessarily need an in-game 3d asset to base his illustration on, which means in the future we can be more creative with the scenes shown on the pop-up pages.

On a technical note, I am animating and rendering the cinematics in 3dsMax. It has been my to-go-to 3D tool for 20 years, so it is just the fastest for me to work with. The downside of this workflow is that of the total 650 MB of the packaged game as it is right now, 150 MB are taken up by the one video file for the intro cinematic alone. While this is not terrible and I expect the full game to still be less than 3 GB, we could save 600 MB by animating in the Unreal Engine sequencer and not include video files. Additionally, it would be the more flexible workflow regarding localization and making changes overall. When starting work on the next cinematic, I'll definitely give this alternative workflow a shot.

That's it for today. Thanks for reading and enjoy your weekend!

Alain

Hey folks,

in the last devlog I ended with teasing some kind of mystery cube. Here comes the explanation...



The cubes you see here are power markers. Corresponding to our damage types, there is physical, fire, air, water and arcane power. Power markers are the "output" of power generators. You place power consuming elements on them to be — you might have guessed it — powered.



The new power consuming building element you see here is an explosive flask dispenser.



This is where base building starts to tie into combat. If powered, the flask dispenser fires explosive flasks at enemies that are unlucky enough to be kited in front of the dispenser by the player.



Now, what's next for me to do is fleshing out the system with more buildable elements and connecting all of this to another already existing system, which I will talk about in the next devlog.

Thanks for reading! If you liked this devlog, maybe consider joining our Discord.

Have great weekend!

Alain

Hey folks,

so I'm still knee deep in implementing base building and will continue to work on it for the next few weeks. I'm happy with the progress, so let me quickly show you what has happened.

We now have a contextual UI for base building, it is the dark purple box on the bottom center of the screen. Also, I set up hotkeys that make the new building actions like placing, rotating and deleting easier. Speaking of which, here you can see those actions:



I also added a few more building elements and removed some. I'm trying to get to an efficient palette that is as condensed as possible, but still leaves room for creativity. For the first time, I am now able to build a tower how I envisioned it when planning the system:



You might have spotted an engine thingy in those gifs. Those of you following me on social media probably saw me posting about it already. Base building in BattleJuice Alchemist will not be cosmetic, but have purpose in fights as well, which is where things like the engine come into play. Let me end with a little teaser here, maybe you can guess what this going on in this last gif. It will be the topic of the next devlog ;)



Thanks for reading and I hope to see you on our Discord.

Have great weekend!

Alain

Hey folks,

many of you might be familiar with impostor syndrome, where people doubt their skills and have the (unjustified) fear of being exposed as a fraud. I don't suffer from it, but I am also not always completely confident that what I do is great.

I have a motion design background and don't consider myself a programmer first. Sometimes I fear that programmers might laugh at my blueprints and look down on me because of my lack of formal education in programming. So today I want to face that fear head on. I will tell you something that makes me feel stupid, but hopefully it will be entertaining and maybe even encouraging and educational.

Perhaps you have heard this quote from Michael A. Jackson before:

The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only): Don't do it yet - that is, not until you have a perfectly clear and unoptimized solution.

I always followed this principle quite closely ;) But I recently decided that in one specific part of BattleJuice Alchemist, I had to do some optimization. Let me give you a very brief introduction to those of you who are not familiar with optimization at all. So we have a game that we want to run at 60 fps in the end. This means we want a frame time of 16.66 ms, which is kind of a budget we can spend on calculations. I have recently spent a bit too much of my budget, so I decided to take a brief look at what I can do to reduce it. I quickly found out that my bottleneck was not the GPU, but the CPU. There is this fancy tool for Unreal Engine called Unreal Insight that allows you to find out where exactly your budget is spent. I took a closer look.



Turns out that the UI is what caused a quite considerable hit on performance of about 3 ms, so this is what I decided to tackle. I guess many of you who ever worked on a game can relate to what I am about to tell you. You are at the early stages of a prototype and all you want to have is e.g. this icon that shows that the player is low on health. Unreal has this nice drop-down menu that allows you to tie the visibility of your icon to a function that decides whether the player is low on health or not and then spits out "visible" or "invisible".



Unfortunately, this causes the icon's visibility to be set visible or invisible every single frame. No big deal, your prototype still runs perfectly. But fast forward 4 years of development and things start to add up when there are a bazillion UI elements and many are unnecessarily manipulated every frame. I was aware that I was doing something bad all the time, so why did I continue? It all comes down to this first icon...

Have you ever heard of the Broken Windows Theory? Let me quote Wikipedia:

In criminology, the broken windows theory states that visible signs of crime, anti-social behavior and civil disorder create an urban environment that encourages further crime and disorder, including serious crimes. The theory suggests that policing methods that target minor crimes such as vandalism, loitering, public drinking, jaywalking, and fare evasion help to create an atmosphere of order and lawfulness.



So when I used Unreal's option to quickly bind the visibility of my icon, I broke the first window, which I should not have done. Or at least, when I implemented the second icon, I should have fixed the first and done it right for every following icon.

Jackson's Rules of Program Optimization are great and you should not optimize prematurely. But this does not mean you should spend your frame time budget on unnecessary things because of your laziness like I did. And especially you should not knowingly do something stupid, decide everything is fine, repeat it a hundred times and still expect everything to be fine ;)

I hope you liked reading this unusually text-heavy devlog as much as I did writing it. If you want to chat about gamedev or stay up to speed with BattleJuice Alchemist, you can join our Discord.

Thanks for reading and have great weekend!

Alain

Hey folks,

I hope you had a great start into the new year! After a few days off, I committed myself to some interesting problems that came up while working on the new base building system, which I'd like to share with you.

BattleJuice Alchemist is mainly played in top-down view, so it is more difficult to deal with buildings, especially multistory ones than let's say in an FPS game. Our game has to set elements invisible in a clever way, here is how we handle it:



Now that base building comes into play, I did not want a floor/story based system, but one that provides more freedom for players who want to create things like this:



The solution is quite simple: blocks that are at a certain height above the player and obstructing vision on the player are turned transparent. But there is another problem to tackle that is related to movement. The common way to move in BattleJuice Alchemist is "mouse click to move", no problem here. But you can also move with direct input keys such as WASD. All movement takes place on a navigation mesh, which can pose a problem.



So with the possibility for all kind of weird structures that players can come up with, we can't simply move right, when the player presses the key for moving right. I came up with a solution that takes into consideration the angle between the player's current and target location, but also the ratio between linear distance and navigation path length. When pressing right, it is desirable that your character automatically navigates around a pillar instead of bumping into it and stopping, but you would not want the character to walk the way as shown in the right image above.

I hope this small peek into the everyday challenges of development was interesting to you. I'm always open to suggestions of which direction to take with this devlog. If you have ideas or suggestions, you can message me on our Discord.

Thanks for reading and have great weekend!

Alain