The game we’re developing is Squally, a 2D Platformer RPG that teaches assembly language. This game is cross-platform, and is written entirely in C++ using an engine called cocos2d-x.

We’ve been working on it for over a year now, and today it’s going open source. This is an extremely rare move in game development — after all, why would you give away years of hard work?

It’s not as crazy as it sounds.

The open source community seems to be thriving everywhere except video games. This is particularly tragic, because game development would benefit from this more than most fields.

Are most first-person shooters really so different that they should be written from scratch every time? Sure each game has its own unique feel, but the amount of redundant code written by game developers is staggering. Game engines have eased some of this pain, but still the wheel has been reinvented thousands of times.

If we could have forked somebody else’s game, it would have been a huge time saver. In fact, if somebody let us build on their game for $20,000, it would have been worth it. That’s how much money it would have saved us— and that’s not even accounting for lost time.

Goodbye revenue?

On the surface, open sourcing a video game looks like a seppuku ritual in which a company is gutted of all future profits. This does not have to be the case. Open source does not necessarily compromise any revenue streams in a single player game.

People buy games on Steam, and almost nowhere else. Steam has a firm monopoly on game distribution.

Will a user really care if the source code is available? The average user probably doesn’t even know what source code is, nor would they care to sift through a readme file in an attempt to compile your game.

There are other things you can do to protect yourself too. Only the code in Squally will be open sourced. To get the art and sound, the user will need to copy it from a legally purchased game. This is for two reasons:

1. Some of the art in Squally comes from asset stores (non-exclusive rights), so we couldn’t release the art publicly even if we wanted to.
2. This helps mitigate any potential revenue loss.

But what about piracy?

Squally’s audience is literally hackers. Piracy was destined to happen. But let’s pretend this wasn’t the case. Even for normal games, piracy is common-place. Piraters gonna pirate.

Piracy rates will probably go up, but my guess is that if anything, sales from the increased community will make up for it.

Downsides?

The worst that can happen is that the art in your game is swapped out and re-released by someone else, with no code changes. If this is a concern, be sure to pick a repository license that makes sense for your game.

If for whatever reason open sourcing the game backfires, you can always close-source it later. Sure, whatever you released will always be public forever, but if the game is early enough in development, it’s not a huge deal.

Upsides!

Looking at other open source games like KeeperRL, there can be some amazing upsides. Users creating mods and additional content, or helping fix weird niche bugs that only happen on certain machines.

Also, if you google around for open source games, the results are pathetic. This is an area where you can really win the SEO game.

Last but not least, there are the intangible, second order effects. Maybe you inspire somebody to learn how to program, or save them significant time on their journey to making a game. We’re excited to see what people do with Squally!

Looking for additional learning resources on game hacking? Check out content from our partner Guided Hacking!

We Open Sourced Our Steam Game, and Why It Was a Good Idea was originally published in SquallyGame on Medium, where people are continuing the conversation by highlighting and responding to this story.

Just like the first time in algebra class when your teacher had to explain that ‘x’ could be any number, eventually it just clicks. My co-founder Matt and I are working on Squally, a game to teach hacking, but before you can walk, you have to learn to crawl. This means that we have to also teach binary and hexadecimal. This game follows a strict ‘no lectures’ policy. Instead, we teach these concepts in the coolest way possible: with a trading card game.

In school, students learn conversion formulas, they memorize charts, and have no reward for their efforts other than a grade on a piece of paper. We want to change this. The great thing about a card game is that you can learn the effect first, and learn the reasoning and math later. Initially, it’s all about winning.

Your enemy has a lot of strong cards? Play the logical shift right card and cut their attack in half.

Have a binary card with0111 attack? Play a card to “flip the 4th bit”, and it will become a LOT stronger.

Learn that a hex card with C attack is the same as a decimal card with12 attack.

In the context of a classroom, this stuff is mind-numbingly boring. In the context of a card game, it’s awesome. To avoid overwhelming players, cards are introduced gradually. Play through the game and collect cards by beating other NPC players, find them in chests, or get them from defeating deadly opponents in combat. Squally is still a modern game — Hexus is only a tiny piece of it.

Squally is not released quite yet, but it’s in active development. We were accepted to the adviser track of YCombinator’s Startup School of 2018, and we’re doing everything we can to move quickly and make this an amazing game.

For those who are interested, you can sign up for our beta.

Learn Binary and Hex with this Gwent-Inspired Card Game was originally published in SquallyGame on Medium, where people are continuing the conversation by highlighting and responding to this story.

This had another unintended consequence. If the game hacks itself, then we need some low-level control over the game — and for that, we need a low-level language. C# and Unity were no longer an option, so we had to start looking at some C++ options.

We narrowed it down to two options. The first option we considered was Unreal Engine. Unfortunately, this engine is not very great for 2D games. Also, Unreal takes 5% of game revenues, which does not make sense if it does not add value. For these reasons, we settled on a lesser known engine called Cocos2d-x.

To emulate real hacking tools, there are only two things that we needed. First, a disassembler for converting the raw machine code into human-readable x86 assembly (or at least hacker-readable). The second thing we need is an assembler to do the opposite.

With these two tools, we effectively have a game that can read and write its own code. We just have to tell the game exactly where to look, which we will explore later.

Of course by letting users rewrite the code in assembly, the user can easily crash this game! But as any hacker knows, crashing things is just part of the job.

However, there are some cool ways to mitigate this. One option is to save the state of the program (registers/stack) before the hackable region of code, and restore it after it executes to prevent silly mistakes.

For those who like to live a bit more dangerously, there are libraries for ignoring segfaults and other errors, which is pretty frightening. This is no match for a simple jmp 0x00000000, but it may be good start for easing some of the inevitable frustration of an aspiring assembly programmer.

Now for the nitty gritty details. A completed sample project is located here: https://github.com/Squalr/SelfHackingApp

To accomplish our goal, we leverage three libraries:
AsmTK + AsmJit for assembling: https://github.com/asmjit/asmtk+ https://github.com/asmjit/asmjit
UDIS86, a disassembler: https://github.com/vmt/udis86

One might expect the steps are as follows:

1. Find instruction(s) we wish to edit
2. Disassemble them into x86/x64 assembly instructions, as strings.
3. Modify those strings, and assemble them back into raw bytes.
4. Write those bytes back to memory, overwriting the original instructions

This seems reasonable, except when we try it… the program crashes.

Upon digging deeper, it turns out that the protections for the page of memory that contain the code is marked as Execute only. It needs to be readable and writable. In Windows, this can be done using the VirtualProtect function in windows.h . In Unix, this is done via mprotect.

The next problem we need to solve is finding code we want to be able to assemble and disassemble. To solve this, we place markers around sections we want to be hackable, as done below.

The important features here are the HACKABLE_CODE_BEGIN() and HACKABLE_CODE_END() blocks. These emit a small sequence of useless x86 instructions.

Once we have these markers in place, we can grab a pointer to this function, and search for the markers! Everything in between these markers must be the code we want the user to be able to change.

For those interested in the implementation details of parsing, see theHackableCode class in the sample project.

Now that all technical problems are solved, we simply glue it all together! Below, we have created a function called hackableRoutineTakeDamage(). Notice the line health -= damage . This is the instruction we are going to self-modify.

In the runExampleHealth() function, we extract the hackable segments, and then patch the code with hackableCode->applyCustomCode("nop") .

As you might be able to guess, the second time we call hackableRoutineTakeDamage() , no health is subtracted! The health -= damage line has been effectively removed by self modifying code!

For those with a background in assembly, you may have noticed that 1 nop is far less bytes than the original instructions. The remaining bytes are filled with nop instructions automatically behind the scenes.

Hopefully you learned something, and if you’re interested in following our progress on our game, you can check out Squally on Steam!

Looking for additional learning resources on game hacking? Check out content from our partner Guided Hacking!

How We Wrote a Self-Hacking Game in C++ was originally published in SquallyGame on Medium, where people are continuing the conversation by highlighting and responding to this story.