Tag: game dev

Why make video games?

When setting out to do anything, it’s important to really consider why you are doing what you are doing. In my case, making video games. Why? Philosophically, why would one dedicate the work that it takes to make video games? This is a question that resonates deeply with me, and I’d like to explain what games mean to me and why one would subject themselves to this taxing endeavor. This is all just my perspective and I’m not trying to imply that anyone should or shouldn’t agree, but I hope that some may resonate with my reasoning, and come to their own conclusions.

I started playing video games in preschool on the Sega Genesis; I loved Sonic the Hedgehog 2, and played it until its first few worlds were burned into my memory. Back then, games were designed to be difficult, constantly forcing the player to improve if they wanted to see more of the game. The elation I experienced after making it to a new world for the first time in Super Mario Brothers was powerful. Sure, I may have failed innumerable times before that, but it was all worth it when I could see the improvement. Games back then didn’t pull any punches. If you got further than you had ever gotten before, it was because you improved at the game. The achievement felt real because it was real.

In a tangible way, these games taught me to adopt a growth mindset and instilled in me an appreciation for overcoming great challenges. These are powerful lessons, ones that can completely alter the course of one’s life. Simply teaching someone the virtues of working hard or delayed gratification more often than not will fall on deaf ears. Even if someone has continuously heard the good word that nothing worth doing is going to be easy, if their subconscious doesn’t agree, in the big picture of their life, this lesson will have minimal effect. This is not something that you learn intellectually like your multiplication tables; it must be viscerally experienced. And in my admittedly biased opinion, video games are very well suited to instill these kinds of lessons.

I see video games as a potent artistic medium like books, movies and music. But, unlike other these other mediums, games have a particular advantage: they give the individual control over the experience. This has profound implications for what a piece can say and mean. It’s one thing to demonstrate an aspect of the human experience in a compelling movie or book, it’s quite another to allow the user to interact with and experience it themselves. Games allow the player to be the character, be in the situation, and set them free to discover for themselves how a given situation would impact them. What better way to empathize for another person than to be put into their shoes?

It’s easy to sit on a high horse and disregard the validity of the tough decisions that characters make in a movie or book. It’s not quite as easy when you are in the driver’s seat. Wonderful examples of these decisions abound in the subtle interactions in Papers, Please. In it, you play the role of an immigration officer in an authoritarian state. Money is tight, your family is starving, and any mistakes or wasted time drags the player down a slippery slope. Strictly speaking, the player is only obligated to validate passport credentials, but what happens when a terrorist comes through with everything in order? Or a desperate refugee whose papers would have passed if the rules had not changed that morning? Whatever the player does in these moments says something about them and the game is elegantly constructed in such a way that the player is encouraged to really engage with the weight of these decisions. Even disregarding these moments and “just following orders” is itself a choice.

But more than mere empathy or visceral understanding of others, games let us see big picture forces at play, how the systems that we set up in a virtual world and the goals we ascribed to them impact how both individuals and collectives respond. You can take the complex social dynamics of any MMORPG to see microcosms of society form when enough rational actors combine. Or witness the unrestrained anarchy of phenomena like Twitch Plays Pokemon, where pseudo-religions and politics evolved to make sense of the chaos. There’s a vast range of possibilities when it comes to analyzing and harnessing this kind of collective behavior that games have only just begun to tap into.

Games are powerful, they can be one of the most interesting and provocative artistic mediums there is, should we choose to utilize them in that manner. Relatively speaking, they have only just begun to exist, the possibilities are endless, and I’m excited to extract some of that potential.

Why I use Godot

Warning: Potentially controversial opinions about game and software development. What is a valuable solution for one person may not be valuable for another, etc.

In the world of game development, there are plenty of choices off the beaten path: Phaser, RPGMaker etc. I could not seriously ever list them all. But when it comes to professional indie development, there are have really only have been two viable choices at the head of the pack for a long time: Unity and Unreal.

However, I would suggest for many developers like myself, that Godot may be the best choice. Godot is an open-source game engine that has been rising in usability and popularity, and as of the release of Godot 3, can be considered a real contender to these more established engines. Why?

Well to start, I’m not a game designer by trade. I’m a full stack engineer, working in python, scala and javascript to develop web APIs and ETLs most of my career. As a result, I have a more "outsider" kind of perspective on these engines and languages. And frankly, when you have been working in these higher-level languages for a long time, it can be quite jarring to have to use things like C++ (the 90’s called…)

One of the first things that struck me when I started using Godot was how much more familiar the workflow felt for a traditional software engineer. Writing code was a breeze and the engine is designed for you to work with code first and foremost; everything is linked together in a dynamic tree structure that lends itself nicely to quick prototyping and "bottom-up" style development.

There has been a trend in recent years towards making game engines more "designer-focused". Don’t get me wrong, this is great and opens the door for more people to get their hands dirty with prototyping and developing games without studying programming for years. But at the same time, there’s a tradeoff when the code is practically hidden from the user.

By default, games in Godot are written using GDScript, a python-like language specifically created for Godot. You can get the brevity and expressiveness of Python while developing games! If you are anything like me, this is a godsend. For many in the industry, this may sound like a horrible idea: "won’t an interpreted language be too slow?" you may be asking. But here’s the thing, GDScript is compiled to a Godot specific byte-code, meaning it is as close to the hardware as C# is.

Caveats

Godot was designed as a 2D engine. This gives it plenty of advantages in terms of efficiency and ease of use when making 2D games. In most other engines 2D doesn’t exist, it is simply 3D with a permanently orthogonal camera. Godot is later to the 3D party than most other engines, and truth be told, I don’t know the full extent of how well Godot fares in 3D game development, but it is certainly a main focus for the development team. If you are working on a 3D game, it may be best to use a more mature tool for now.

Deploying games with Godot is quite easy to do, however, you may find that its list of exportable targets to be lacking. Currently, you can export to PC (Windows, Mac and Linux), XBox One, Android and iOS. This misses the major consoles, so if you were hoping to target the Switch for example using a Godot, your options are limited (Console Support in Godot). For me, this is the real concern holding me back from using Godot for virtually everything. It is possible to get a third party company to port your game for you, but I don’t know how viable that is (I’m planning on trying it at some point though).

To sum up, if you are comfortable with code and plan to make 2D games, Godot is the best choice out there in my opinion. If you need console or 3D support, perhaps not now as of this writing.

If you love Godot as much as I do and want to see it succeed, consider donating on Patreon! This way, the developers can afford to hire more full time staff and create the game engine we’ve always dreamed of! Disclosure: I am in no way affiliated with Godot, I just love and support it.

Quick Tip for Godot 3 Signals

I figured I’d share a quick tip that I found helpful in structuring my project in Godot 3.

Signals in Godot allow you to loosely couple any component in your game tree using the Observer Pattern. This means that any object A can communicate with any other object B simply by signing up to listen for a particular signal.

Neither object needs to explicitly reference or even be aware of the other object as long as they both agree on the same interface. This is very helpful when dynamically generating the game tree out of many scenes since the parent can connect together all of the children as needed.

This works great for simple setups, but as soon as you need to connect parts of the game tree that aren’t direct siblings or children, things can get hairy. You may find yourself creating "pass-through" signals to forward messages down or up the tree. Or you may start making several versions of the same signal to handle edge cases.

I followed a strategy of making "handshake" signals for any major scenes that needed to be accessed throughout the code. My base_level.gd forwards a signal level_handshake that would connect on to any interested receiver’s _on_level_handshake function. In this way, any dynamically generated scene that needs to accessed elsewhere can be broadcast to any node that is interested. It simply says, "hello anyone who cares: I’m the level and here is my reference". The receiver can simply save this and use it as it sees fit.

Following this simple strategy has drastically improved the flexibility of my code in regards to updates and refactors. It’s simple, but it’s effective!