Vaporum Blog

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! 🙂

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!

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!

Hey guys!

We recently announced a giveaway of keys for Vaporum on Steam and GOG. We’ve received 157 answers, and what’s interesting is that the vast majority of you (89%) was right! You guys obviously know your stuff! 🙂

The correct answer is 15th of December, Dungeon Master!

We added all of you with the correct answer to a pool and used a simple program to choose 10 from the pool, at random. We are currently contacting the winners to see what kind of key they wish to get.

Winners, enjoy this early Christmas present! The rest, thank you for taking part!

Hey guys!

We have a major update for you today! Yesterday (December 3rd) was the International Day of Persons with Disabilities, and we wish to address some of the issues people with disabilities may have while playing Vaporum and other games. One of the reasons why we took this stance is this article written by Olivia Falk at GameSpew. Olivia pointed out several in-game situations where Vaporum fails to fully allow people with various forms of disabilities a full gaming experience.

In the past patches, we were adding quality of life improvements and some changes to make the game more accessible to people with motion sickness and hearing deficiencies. Today, we’re introducing a Stop Time Mode.

You can turn this mode on and off at any time by pressing CapsLock (default key). When the mode is active, it automatically stops time whenever you are taking no action. This can be very useful in difficult combat situations where you need time to plan the best attack, or retreat for that matter. While you’re taking an action, time goes by as normal. But the moment you stop doing anything, time stops again, giving you the opportunity to plan the next move. Sometimes, the best course of action is to wait. You can hold Shift (default key) to advance time. You can make time tick while holding a weapon attack button too (LMB or RMB).

The Stop Time Mode can also be used in puzzles and hazards that require perfect timing, obstacles you may find too difficult to beat in real time. Using the Shift key, you can time your movement down to the millisecond. Please note that this is not meant as some sort of turn-based combat mode, but rather a more tactical approach to combat that is available in the game. We thought it would be interesting for people who like to play games at a slower pace, or people with physical difficulties, to give them plenty of time to reason about their moves.

We’re also adding an on-screen directional keypad for people who can only play with a mouse or only via touch. Or for those who love the old-school feel! 🙂

As usual, here are patch notes:

• Added a Stop Time Mode.
• Added an on-screen directional keypad.
• Added item comparison tooltips.

Enjoy!