Category: Game Dev

The Stalker

Posted on - by nuke

This is a game script i wrote a couple years ago in Lua for Garry’s Mod, a mod which exposes the Source Engine (the engine used by Half Life 2, among other things) to Lua. I wrote the game around 2011. It took roughly 3 months to complete. In that time I had to program the game and also made a few maps for it using the Source SDK which took longer than expected to finish.

Being able to script a game using Lua bindings in a pre-existing engine is good fun since it’s relatively easy to get a working prototype up and running.

Here is a general description of the game:

A team of soldiers must hunt down a powerful, nearly invisible creature known as The Stalker. The Stalker has a number of abilities:

• Scream – A loud shriek that causes nearby soldiers to lose their hearing temporarily and disorients them. This attack uses 25% of your energy.

• Mind Flay – This attack invades the mind of the targeted player. They are heavily disoriented and take some damage from the attack. Perfect for picking off stragglers or confusing players who are very good at figuring out where you are. This attack uses 50% of your energy.

• Telekinesis – Control an object with your mind. You can choose the direction in which the object is thrown. A useful tool for distracting soldiers or causing damage with larger objects. This uses 75% of your energy.

• Blood Thirst – Your attacks absorb health for a short duration. Uses 100% of your energy.

• ESP – This ability is enabled/disabled by toggling your flashlight button as the stalker. When ESP is enabled, you can see where soldiers are through walls. However, while ESP is active, your energy will not replenish and your overall vision becomes darker.

The energy used by psychic attacks will slowly regenerate over time. In addition to having psychic abilities and being invisible, the Stalker is also very agile. It can jump to high areas, run faster than soldiers, and cling to walls. The Stalker’s health slowly drains over time but it regains health with each kill.

The soldiers have their own tools for hunting the Stalker. There are 4 different, equally balanced primary weapons to choose from, as well as 4 different secondary weapons and 4 utilities. Their flashlight runs off battery power and if your battery reaches 0% charge then there is a small delay before it starts recharging. The recharge rate for the battery is slower than its drain rate so you have to manage your flashlight use.

Primary Weapons:
• SG 552 – A highly accurate scoped rifle. Magazine holds 20 rounds.
• FN P90 – A SMG with a large magazine and a high rate of fire. Magazine holds 50 rounds.
• SPAS 12 – A powerful close range semi-automatic shotgun which can fire 6 rounds before reloading.
• FAMAS G2 – A 3-shot burst rifle. Magazine holds 30 rounds.

Secondary Items:
• Portable Sensor – A laser tripwire alarm which can be planted on any solid surface.
• USP Compact – A backup pistol with unlimited ammo.
• Seeker Drone – An autonomous drone which floats around and sounds an alarm if it detects the Stalker.
• Optic Range Scanner – A handheld scanner which augments your vision.

Utilities:
• Automedic System – An integrated morphine injector for your armor which heals you automatically when you are injured.
• Laser Module – A laser pointer attachment that fits any weapon.
• Extra Ammunition – Additional ammunition for your primary weapon.
• Dual Cell Battery – An improved battery which recharges faster and augments your flashlight.

Some screenshots:

Plenty of people have recorded videos of the game in action.

You can check out the code on assembla: https://www.assembla.com/code/the-stalker/subversion/nodes

Learning MonoGame

Posted on - by nuke

It’s important to keep a log of the stuff you work on, even if it doesn’t pan out. I blogged about this game i was working on back in 2013 while i was in university, the following post is an amalgamation of everything i wrote pertaining to this game, edited for brevity and clarity.

This project started out in VS2010 using XNA and an open-source 2D physics engine called Farseer Physics but then VS2012 came along and Microsoft stopped developing XNA. XNA still works but it’s officially deprecated, so I migrated to Monogame which is basically a port of XNA that works on every platform (and works with VS2012 unlike XNA).

I didn’t really get any work done on this when i was messing around in VS2010. I had no idea what i was doing so most of my time was spent learning C# (which is a cool language) and figuring out the architecture of the Farseer Physics test samples. When I finally got around to installing VS2012 i had to figure out how to make Monogame work with Farseer Physics. After a while i sorted out the physics engine. The solution was trivial, just had to replace the XNA references with Monogame references and it built without any problems. So after I got that out of the way i hit my second road block. I couldn’t do anything with XNA content projects in VS2012. Monogame will soon support content projects but for now I have to use a separate content project in VS2010 and build that every time i add new assets (textures, etc) to my game.

So, once i got those two things out of the way i could actually start writing the game. I kind of cheated and used the Farseer Physics samples project as a reference when I started working on my game. So far I’ve implemented a similar screen management system (most games use multiple “screens” – menus and pause screens, etc.). And then there’s a lot of stuff behind the scenes that goes into actually setting up the “world” and spawning the low-gravity orange box you see in the first screenshot. It bounces around if you drag it with your mouse.

I guess my next task is to work on making the player object controlled by the WASD keys and make it so the player isn’t just a box that tumbles around (I assume i can just max out the damping on the box so it can’t rotate, or even just disable rotation). Then after that i suppose i’ll have to work on making the player object an animated entity with bones and joints and stuff.

In the picture there are 4 buttons in total, they support images and text (and a combination of both) but for now i’m just trying to get them to actually function like buttons. I think i’m just going to make my own text system using images for individual letters so i’m not actually drawing any actual text to the screen.

It’s hard to choose a starting point when you start from square 1, there are so many things to do and it’s hard to judge which features should take precedence. So for now I’m just going to try and get the basics of the interface sorted out and worry about everything later.

With some work I got the main menu and buttons working exactly how i wanted them to. Right now only the New Game and Exit buttons work. If you click New Game, it transitions to the game screen and spawns a player object. And the exit button speaks for itself. I think i’ll worry about getting a proper font and making the buttons look nice when it really matters. For now i want to flesh out the more important things.

This isn’t very exciting to look at but there’s a lot of stuff behind the scenes being completed! I wrote a basic EntityFactory and EntityManager class. Now i can go wild creating new entities.

I’ve also been working on a entity hierarchy. In my previous blogs i wasn’t actually using entity factories or my own entity classes so it took like 30 lines of code to just create one object, and then i had to write the code that renders the object on the screen. Now i can create an object in one line of code and I don’t have to worry about how it renders.

I need to figure out how to go about properly deleting entities. Right now, my EntityManager keeps a list of all the objects I’ve spawned into the world. If i delete an object then i also need to remove it from the EntityManager’s list (and if it’s a physics entity then i need to delete its physics object too).

Next, I finished an input helper component which should come in handy for several things. I can’t see how anyone can program a game without using a component-based architecture… It’s messy enough with everything compartmentalized, I can’t imagine how much of a mess it would be if it weren’t.

And here is more progress with player movement. Those two orange rectangles you see covering the blue bouncing rectangle are actually not colliding with anything, they are sensor bodies that tell me whether the player object is on the ground or touching a wall (which is why i can bounce off walls, that was intended). Normally they would be invisible, i’m just drawing them because i want to be sure they’re scaling properly based on the size of the physics entity they’re parented to.

I wrote an attribute system for entities and made them serializable. My next order of business is making a simple level editor. Instead of making a separate modding toolkit for this game i figure i might as well just build it in as a menu of its own.

I finished some concept art.

I Frankenstein’d the final product from several different sketches. I don’t own a scanner (i had to hold my webcam steady and take top down photos of each drawing) which explains the differences in color. If this looks like it was inspired by Earthworm Jim or something similar then that’s probably because it was.

For some reason i can’t draw normal hands to save my life. I also can’t draw hands directly from an arm, i have to draw them separately then splice them in and re-scale them using Photoshop. The gun in his left hand was also drawn like twice the size it needed to be.

The final product, converted in Photoshop and colorized without shading.

 

This is essentially all I really was able to complete on this little project before I lost interest. Around this time, Unity was growing in popularity and my university switched from MonoGame to Unity for all game development courses. Switching from MonoGame to Unity definitely helped highlight some of the things i disliked about MonoGame. Pretty much everything has to be programmed from scratch. This isn’t terrible if you know what you’re doing (I didn’t) and you want maximum control over every aspect of your game (I didn’t).

To say that I simply quit working on this solely because I lost interest would probably be an oversimplification. It was a combination of dislike for the game engine, lack of vision/direction for the game i wanted to make, and a lack of free time due to coursework. It was a good starting point for learning the architecture of games and figuring out how game engines really work under the hood.

 

Taming Random Numbers

Posted on - by nuke

Imagine you have a 120×120 grid of tiles. A tile can either be empty or solid. You want to procedurally arrange the grid such that the empty tiles form an interesting complex of caverns. You also want to be able to generate a near-infinite amount of different styles and variations of caverns, because variety is nice.

 

First, the basic concepts need to be set up. Every tile in the grid needs to know about the tiles that surround it. What is the X and Y position of the tile? How many tiles around it are solid? How many are empty? Is the tile to the left of this one solid or empty? Is this tile on the edge of the grid? All of these questions need to be answerable by an individual tile.

 

You also need to come up with a solution for how you’re going to tweak all of these tiles to get your result. This is where the concept of a filter (for lack of a better name) comes in. Every time the entire grid is modified, a filter will be handling the logic. By chaining several filters, you get your end result. A filter can be very simple. You could make a filter that finds every tile on the edge of the grid and makes it solid, or a filter that swaps all empty tiles to solid and vice-versa. You can also incorporate several commonly used tools in procedural generation into your filters, such as cellular automata. And so-on.

 

First, you start by randomizing the tiles. This gives you a rough starting point for shaping your caverns. Next, you apply some simple cellular automata rules to transform the noise into something more manageable. The cellular automata rule is simple: if a tile has 4+ solid tiles directly neighboring it (including diagonals), then it becomes solid. The same logic applies for empty tiles with 4+ empty surrounding tiles. In all other cases, the tile remains as it is.

In the animation you can see that step 1 is the random collection of tiles, while in the following steps a cellular automata rule is applied. The effect of the filter diminishes after the second or third step, so for practical purposes you just need to run that filter 3 times to smooth things out.

 

One obvious issue is that there are caverns that get generated with no way to move from one to another. What if the solid tiles are unbreakable?

Starting with a nicely smoothed out set of caverns, you could then add a filter which reduces the number of caverns to something more manageable. You could keep the 8 largest caverns and take all remaining caverns and make them solid. To maintain the same number of empty tiles, you could convert random solid tiles from the larger caverns to empty tiles based on how many empty tiles the now-removed caverns had. Now you have a guaranteed collection of 8 or less disconnected caverns and your grid has the same ratio of solid tiles to empty tiles. How can you make sure the caverns are all connected? One solution is to connect every cavern to the largest cavern by digging a trail to the large cavern. Now you can be certain that every empty tile on the grid can be reached by the player.

 

What if you aren’t satisfied with the distribution of caverns? What if you want to guarantee that the majority of the map has caverns of a specific width (more or less)? You could make a filter which finds every solid tile that has 5+ solid tiles in every cardinal direction, and make it empty. The same logic would conversely apply to empty tiles.

Step 3 on this image illustrates the outcome of applying this new filter. Solid masses of tiles suddenly have hollow interiors and large empty spaces suddenly have solid chunks of tiles filling them up. This filter seems to make a mess of the grid, however, so you would need to re-apply some other filters to clean it up. Reducing the number of caverns to something manageable then connecting all the caverns with another filter would give you desirable results.

 

Maybe you want the caverns to be more rectangular and less blob-shaped. You could add a filter that fills in small gaps and removes bumps.

Your options are limitless when you have control over the set of filters applied, and the ordering of these filters. The filters can even be fed different parameters to give much different results. Maybe you want to reduce the number of caverns in the grid to 5 instead of 8. This would use the same cavern reduction filter used previously, just with different criteria.

Having more filters at your disposal means you have more control over the end result, and also more interesting combinations to try.

 

What this conceptual grid of solid and empty tiles will be used for will be the topic of a future post.