Jul 302018
 

Hey guys, we have a big update for you today!

Vaporum is now available on Mac! We have also added a few game tips to clarify some game mechanics and fixed quite a few bugs.

Patch Notes

  • Added Mac support.
  • Added a few game tips to clarify some mechanics & interactions. This is also due to the upcoming controller support.
  • Added a “Toggle HUD” button (default: F4). You can use this to make HUD-less screenshots.
  • Fixed issues in Slovak, Japanese, and Chinese localization.
  • Fixed: While you’re in the process of dying and a game tip shows up, the game crashes.
  • Fixed item container size.
  • Fixed tooltips for Fumium Capacitor, Combat Fuse, Tech Fuse, Toughness Fuse, and Cicruit Upgrade.
  • Fixed other minor bugs.

Enjoy! 🙂

Apr 112018
 

Dungeon Master was a defining game of this type, but many of us have also spent a lot of time playing one of its successors. We could even say that it is the second best known representative of this sub-genre of RPGs. Eye of the Beholder is very close to our gamers’ hearts, and, several decades later, it definitely was one of the strong examples we were drawing inspiration from while creating Vaporum.

Perhaps if it wasn’t for Legend of Grimrock, nobody would even think that this old type of gameplay could work in modern times. But, as Grimrock has proven, and we hope that Vaporum has too, a system based on the legacy of Dungeon Master and the likes works like a charm, even today. So it’s no surprise that while working on Vaporum, we sometimes talked about Eye of the Beholder and its appeal. What could this game look like in this age, with today’s possibilities? Dressed in modern 3D graphics, yet at the same time staying true to its original style?

During the winter holidays, we created a small visual homage to this big piece of inspiration of ours, and now we want to share it with you. 🙂

Mar 012018
 

Hey guys!

Just a small update with a few important fixes that were found on some OS and locale combinations.

Patch Notes

  • Fixed: On some combinations of OS and HW, reading string data is incorrect, resulting in super-long cooldowns of weapons, for instance, making the game unplayable.
  • Fixed: News messages don’t show up in the main menu when subtitles are turned off in the game options.

Enjoy! 🙂

Feb 232018
 

Hey guys!

We are rolling out a new patch with a new language, few bug-fixes, and some small tweaks based on your feedback. Yeah, and one tiny detail: Linux! 🙂

Linux

The Linux build is finally here! We tested it on Ubuntu 16.04 LTS and once we worked out all the quirks, it pretty much worked fine. There is one known issue: volumetric lights look weird on Ubuntu with AMD cards, and there doesn’t seem to be anything we can do about it. 🙁

Hungarian Language

Apart from Linux, we are adding Hungarian language to the game, thanks to Zsolt Brechler, who took it upon himself to make the whole translation with the simple localization tools we added some time ago. Big thank you, Zsolt, we appreciate it! 🙂

Patch Notes

Here are the obligatory patch notes:

  • Linux build! 🙂 (Tested on Ubuntu 16.04 LTS.)
  • Added Hungarian language, thanks to Zsolt Brechler!
  • All consumable items can now stack. This was inconsistent where some did stack (e. g. Repair Kits) and some did not (e. g. Fumium Cells).
  • Fixed: Reinfusor & Overcharger modules have buggy interactions. You can activate gadgets for free, basically.
  • Fixed: In some rare conditions, the game can crash when unable to load & parse the EnemyShowcase.dat file.
  • Fixed a few typos in game tips.
  • Fixed: Item comparison tooltip option does not save correctly.
  • Fixed: Some shaders and materials do not work correctly on Linux.
Jan 032018
 

Nowadays, the fact that many people play games in their free time hardly ever surprises anybody. Long gone is the time when playing games was the domain of a small group of strange people. Today, we can bump into all sorts of videogames on basically any device, and nobody wonders about it any more.

But who creates these games, do you ask? There are as many answers as there are games. This piece of information is not hard to find. Footage from conferences, “making of” posts and videos, or the whole slew of post-mortem articles. We may not be able to see into the souls of game developers, but we know very well what drives them, how they create, and how they think, creatively.

On the other side of the work, a videogame in this case, is the player. Someone who gets to lay their hands on the result of years of work, with everybody hoping that the game catches their fancy. Will they enjoy it, or possibly (if the ambitions were a little greater) take something good out of it? But who is the player? What does it even mean? Aren’t we all players after all?

For game developers, players are often a shapeless mass of statistical data. Collected via research and surveys. We’re inquiring into how many of you liked which game mechanic. Why did you find this specific part of the game problematic. How far did you get in the game, where did you encounter issues. All this is seen through the optics of statistics. Sometimes you don’t even think about all the places your game could reach. At which places it could be played and by whom. It just doesn’t cross your mind that somebody might be playing your game, say, at the North Pole station, right? Why would they? But when you think about it, why not? Games are wherever people are.

That’s exactly why we were so glad to learn that one of the players waiting for Vaporum’s release was Mateusz Mandat, meteorologist, who is currently working at Svalbard.

It surprised, pleased, and definitely intrigued us! So if any of you Vaporum players work or reside at an extraordinary place, or have an unusual job, and want to share your experiences with playing the game, we’ll be glad to learn more about you via an interview.

Today, we’re going to talk to the aforementioned Mateusz about his passion of playing games and his work that has led him to the cold, distant North Pole.

Hi, Mateusz! Tell us briefly about yourself.

Hello, I’m Mateusz, 26 years old and I’m from Poland. I’m a member of the 40th Polish Polar Expedition on Svalbard.

How does a gamer like you get to live at the North Pole?

My father was here back in 2004 and I had the opportunity to come here for 2 weeks. It was a fantastic experience. I said I would come back, and now I am here for the third time. I was here before for a year in 2015-2016.

How long have you been there and what exactly do you do every day?

I’m staying here until June, which will make it one year. I’m one of three meteorologists. Every 3 days, I have a 24-hour duty. While on duty, I need to make an observation every 3 hours and send data for forecast. Every day is a new adventure. Like a visit from a polar bear, reindeers wandering around the base, polar days and polar nights with auroras…

Since we know you play games, what games have you played during your stay out there and which ones are your favorites?

I have finished about 4-5 games since I came here. I enjoyed South Park: The Fractured But Whole and its type of humor. I played it on the hard difficulty so the fights would feel more satisfying. When I played Prey, I almost felt like being in one of my favorite games, Bioshock. I’m a huge fan of board games, and Hand of Fate was a fresh experience with the mix of card game and RPG / hack & slash elements. Batman: Arkham Knight was also solid, I had a lot of fun with that game. Hearthstone is one of the few online games that work here. I’ve been playing since beta, and I’m waiting for each new expansion.

What game do you keep the fondest memories of? Feel free to expand on this.

I have finished Tony Hawk Pro Skater 2 over 40 times because it’s so enjoyable every time I play it. The original Bioshock was something new with good gameplay and an interesting plot. Witcher 3 is one of my favorite games. Not because it was made in Poland, but for the world and story.

Is there any funny moment / experience in your life connected to gaming?

I played a lot of the original DOTA and I met awesome people thanks to the game. Meeting people who you only know by their voices in real life for the first time and seeing what they look like was weird. Every one of us has a life, but we maintain contact and try to meet every year.

One day, I’m playing WOW at my friend’s house, as he shares his WOW account with me, and I die in-game. I don’t want to walk as a ghost back to the place where I died because it’s a long walk. So I think to myself, “Okay, I’ll lie in bed here and just wait for my team to resurrect me.” And then my friend’s father comes into the room, asking, “What are you doing?” And I say: “I’m waiting for resurrection!” This makes me laugh so much every time I see him. I believe there are many more moments like this one, but I can’t recall them now.

What device did you play your first game on and what was the first game that blew your mind?

My brothers had one of the Atari machines, I can’t recall which one exactly. I remember some games, but I mostly remember Bang, where you have to shoot bandits who open doors in a bank. My first PC game was some kind of pool, and then the original Diablo.

What’s your opinion on Vaporum?

One of my favorite types of games are dungeon crawlers. Dungeon Master 2 and Stonekeep remind me of my childhood. When I heard about Vaporum, I was excited because there aren’t many dungeon crawlers nowadays. I enjoyed Vaporum, also because a dungeon crawler in steampunk is something new in the genre. No wizards, dragons, or ghosts all the time. Gameplay is solid, with good mechanics, beautiful graphics, smart puzzles, and an interesting story. One of the best DCs I have ever played.

What games do you plan to get your hands on in the nearest future?

One of the games that look interesting and that I’m waiting for is Vampyr. I am also curious about Cyberpunk 2077, although there is not much information yet. I’m also waiting for what Fatbot Games comes up with next!


We would like to thank Mateusz for sending us the photos and the answers to our questions!

Last year, just before Christmas, Mateusz unlocked one of the important achievements in the Game of Life — he got married. In style! Not every man can claim that his bride took a helicopter to fly over to her husband, to the North Pole! We wish all the best to the newlyweds! 😀

P. S.: If you play Vaporum at an extraordinary place, or you have an unusual job, let us know!

Dec 182017
 

Hey guys!

This post is about how to avoid Unity’s coding pitfalls you will inevitably fall into if you follow the official tutorials.

Don’t take me wrong. Unity is an exceptional tool for creating games, and I love most of what it does for you! Especially now that I know what I know, after 4 years of using it in making Vaporum, I wouldn’t want to change my precious little engine for anything! But that’s exactly the issue — you have no way of knowing in advance that you’ll get slapped plenty of times going the “Unity” way of doing things.

The Unity Way

So, Unity teaches you to create game objects, slap your components on them, have your components listen for the “magic methods” like Awake, Start, Update, and the like, and the meadows are green and roses are red. Yeah, that surely works for the mini-projects their tutorials take place in. Issues start to pop out the moment your game grows in size and complexity though. Especially if you implement some kind of full-state save system with multiple ways of loading scenes (more on that later).

In classical game architectures, you write your main loop where you poll for input, update objects, components, systems, and render audiovisuals in the order of your choosing. In Unity, this is all set in stone and you have almost no control over the flow. It’s not clear and you can never be 100% sure of what gets called when and in what order. Unity gives you some degree of control via the script execution order tool, but even that cannot solve all use-cases. Not to mention that it’s weird from a coder’s standpoint.

Another issue is the performance. When your component is initialized for the first time, Unity checks if it contains a magic method, and if yes, it adds the component to an internal list of objects that need to be notified when certain engine events happen (Awake, Update, etc.). The problem is that these notifications are done via calls from C++ to C#, which is costly in itself, and the fact that Unity does a lot of safeguarding behind the scenes. In my opinion, that safeguarding should be your responsibility — you should make sure you are calling something that exists, that you don’t remove an object from an array you’re currently iterating over, that the object has ever been initialized, or whatever your specific game requires. You are making your own piece of software so you know what you’re doing. You should have full control.

And again, in small games with a handful of components, you will hardly ever notice any perf issues. In games with 120+ total components and a few hundred game objects in a scene, this can get noticeable.

Read this excellent official Unity blog post on the specifics! As you can see, they themselves recommend creating your own way of managing the game loop.

The Classical Way

What I’m going to recommend here may or may not fit your project, but this is what we learned the hard way when working on Vaporum. Since we realized problems piling up too late in the development, we couldn’t rework the whole game from ground up, but at least some changes towards the suggested system made it in.

There is no way you can properly implement your own main loop in Unity. You have to rely on the callbacks; they are the only entry points into anything you can do code-wise. So let’s work with that!

You should have a GameObject in every scene (let’s call it GameManager) with a single script on it, and you should make this object survive scene changes. This is one of the typical simple implementations (in Unity waters also known as singleton):

public class GameManager : MonoBehaviour
{
    public static GameManager Instance { get; private set; }

    public void Start()
    {
        // If this instance is the first one...
        if (GameManager.Instance == null)
        {
            // Set it as static instance.
            GameManager.Instance = this;

            // We need this GameObject to survive scene change.
            DontDestroyOnLoad(gameObject);

            // Initialize whatever you need here...
            ...
        }

        // If this is not the first instance ever...
        else
        {
            // Destroy this GameObject.
            Destroy(gameObject);
        }
    }

    public void Update()
    {
        // Update your stuff...
    }
}

The GameManager is THE ONLY class in your project that has the magic methods (with an exception, later on that), so it’s the only entry point from Unity into your game. This in itself is a HUGE boost already! Not only do you drastically cut the C++ to C# calls, you also gain full control over what gets called when. The Update method becomes your main loop from which you rule your kingdom with absolute authority!

Sure, this puts the burden on your shoulders to come up with a sound architecture for adding, removing, sorting, and updating your game objects & components. As none of your components have any of the magic methods, you have to spawn, initialize, update, and destroy them yourself.

To be clear here, you still use GameObjects with your custom components on them, but you just don’t use the magic methods on those components. That’s the crux.

There are countless ways to implement this, but I’ll describe our own here in a few words, just to give you an idea. I’m sure your game will need a specific implementation anyway.

  • When the game starts for the first time (GameManager.Start()), you scour the current scene for any GameObjects that have your own components on them, and add them to the system.
  • Have arrays and managing functions to add, remove, and update objects & components in these arrays. Use simple arrays, not lists or dictionaries. Arrays are fast!
  • Use integer ids in your systems and components to quickly access other objects & components in this global array(s).
  • Have your own functions to spawn and destroy objects that automatically properly handle addition / removal to and from the arrays.
  • Have a way of defining the order of when components or component groups should update.

Even if there is a unique special case where normally all ComponentAs update before all ComponentBs, but one specific ComponentB needs to update even before all ComponentAs, you can do it with this system. You can do whatever your game needs. That’s the point.

Now, one of the very few exceptions where you may need some magic methods in classes other than GameManager is collision handling. Unless you write your own physics, you will need OnTrigger... and OnCollision... methods on specific objects to handle this. Still, this can be wrapped into a single generic collision-detection component that can communicate with GameManager directly, which in turn can decide on when your game logic will get to handle the collisions (right when Unity detects them, or later on in the main loop, or ignore them in some cases — your call).

Note on Singletons

Some game systems (PrefabManager, SoundManager, SaveManager, LocalizationManager, …) are just a bunch of structures and functions. It doesn’t make much sense for them to live inside a Unity scene on a GameObject. Yet, you can find heaps of tutorials that teach you just that — create a bunch of singleton classes like our GameManager, put them on a few GameObjects, and everything is dandy!

Yeah, but why… I see zero benefit in this approach. My recommendation is to simply implement these as static classes. Handling the GameObject & Component thing is completely unnecessary in this case. Waste of your time.

Full-State Save System Hell

Here are a few issues you’ll likely run into when implementing a full-state save system without any kind of main-loop manager. By “full-state”, I mean creating a save point that is exactly reconstructed upon load, byte by byte, so you end up with the exact same game state as when you pressed the save button. For games with checkpoints, this gets much easier.

Components (classes derived from MonoBehaviour) cannot have constructors. The arcane Awake method is a sort-of replacement for that. So you mostly use that to initialize some other objects, states, and references. But there is a nice little caveat! If you load a scene with a disabled GameObject, the Awake methods on its components will never run! Not even when you enable the GameObject. Which leaves your components uninitialized for good. So for those you need to be disabled on start, you must create your own initialization method anyway. Sorry, this is not true. I mixed it up with something else. The issue we faced is that GOs that are disabled in design time will not get their Awake called until you enable them. But because the Awake is like a quasi-constructor, and you use it mostly to initialize references and other basic stuff, this leaves the object in a weird state. It exists, but its “constructor” has not been called. So it’s mostly unusable before you enable them, which you don’t always want, yada yada… Just something you need to be aware of.

The sneaky Start method has another beautiful perk. It does not adhere to the script execution order. We found out the hard way, when things were breaking every other day. Because of this, we had to stitch together a Start manager that would be able to call the method on objects in our desired order, and also be able to tell if the method has ever been called in the lifetime of that object (persisting through save files).

When you load a saved game in Vaporum and you are in the same level as where you saved the game, we do not reload the whole level (Unity scene). In this case, we just match those objects that are both present in the save data and in the scene, and load data into them instead of removing everything and re-instantiating it again. This is to make loads very quick, and damn, it does speed things up! But, there is a problem, of course. The object’s Start will not get called, obviously, and if there is something in there that need initialization, we got issues, Houston. So, again, your own layer of creation, removal, and initialization begs to exist here.

Objects that don’t exist in the scene, but do exist in the save data, or the other way around, have to be created or removed. But because you do the loading within an Update callback, the Starts don’t get called on those objects until the next frame. So we had to hack this too (also forcing them to be called in our desired order).

All this shabang exists because there are multiple concepts of “loading a scene”:

  • You’re entering a scene for the first time ever.
  • You’re entering a scene you’ve already entered before.
  • You’re entering a scene for the first time in this session, by loading a save file.
  • You’re entering a scene you’ve already entered before, but it’s the same scene as in the save file, by loading a save file.
  • You’re entering a scene you’ve already entered before, and it’s a different scene from that in the save file, by loading a save file.

Now, to be honest, some of the issues we ran into could have been mitigated by a smarter approach, or more research, or perhaps more testing, etc.

In any case, I’m not making another Unity game without a manager I have full control over!

Dec 152017
 

Hey guys!

As promised, we are rolling out a new patch on this important date in the dungeon crawl community — the 30th anniversary of Dungeon Master release. And it’s packed with new features!

TLDR summary:

  • New exoskeleton rig.
  • 3 new circuits & 9 modules.
  • Level cap increased from 16 to 17.
  • Enemy Showcase added.

New Exoskeleton Rig

We are introducing a new, 4th rig that you can choose in the first level. The Assault Rig is all about a risk-reward dynamic, increasing all damage you deal based on your missing integrity. In short, the closer you are to death, the more overall damage you deal (weapons, gadgets, shield reflects, etc.).

To take advantage of this mechanic, you will have to stay on the brink of death, only repairing your rig when the situation becomes critical. The constant danger of being one-shot to death is nerve-wrecking, but at the same time very rewarding, as your damage goes through the roof!

Because it increases your overall damage, the Assault Rig pairs well with both weapon builds and gadget builds. In any case, it’s all about offense, so you can go ham on them pesky creatures!

3 New Circuits & 9 Modules

The new rig is fun to play with on its own, but why not throw a few new skills into the mix, right? You can now invest your circuit points into three more circuits (each having 3 modules to unlock):

  • Servo Support: If you like weapons, this is for you. Enhances your precision and evasion with some strong bonuses on critical hits and evading attacks.
  • Complex Capacitor: Allows you to drastically increase either integrity or energy, with hefty bonuses and trade-offs.
  • Elemental Conductor: If you like DOTs, you will like this. Gives you a lot more ways to wreck enemies with elemental damage over time (even those who are immune to certain types!) while keeping yourself safe from such effects.

During playtesting, we found many interesting & fun builds that felt quite refreshing compared to the vanilla game. To open up more build options, we’re also increasing the level cap from 16 to 17 (it’s not easy to achieve though!). Can’t wait to see what builds you guys come up with.

Thank you all who contributed with their ideas for the new rig & circuits in this discussion!

Enemy Showcase

The third major addition is the Enemy Showcase. Whenever you defeat an enemy, an entry for it will unlock in the Showcase. This is not retroactive so you will have to defeat every enemy once again even if you’ve already beaten the game. Once unlocked, you can go see detailed information on their combat capabilities, hints, and lore via Main Menu -> Arx Pedia. You can also see some of the enemy animations in peaceful conditions.

Unfortunately, the Showcase texts are not localized. We wanted to provide solid chunks of lore and info, which resulted in lots of strings to translate, and in our current situation, it would be just too expensive. In any case, you guys can always take your part and localize the content yourselves (read this for more info).

Patch notes

  • Added a new, 4th rig. You’ll find it where the original three are.
  • Added 3 new circuits.
  • Increased max level cap: 16 -> 17.
  • Added an enemy showcase where you can read detailed info on enemies you beat.
  • Fixed: Total damage multiplier sometimes applies twice.
  • Fixed: Weapon damage shown in the inventory panel does not account for dual-wielding damage penalty.
  • Fixed: Difficulty change prompt sometimes shows up even if you aren’t dying much.
  • Fixed: Certain interactions with Puller Golem’s pull may crash the game.

Enjoy and happy holidays! 🙂