Month: August 2018

Arena Simulator

Posted on by nuke

I created a Unity game that simulates a Hunger Games sort of scenario. The idea was to make it as modular as possible so that users could control virtually everything about the characters, weapons, and arena via XML.

For example, the user can create different types of bodies and define each body part. The body is organized as a tree, so in a human body if a pawn’s leg were destroyed then it would follow that their shin and foot would become unusable. Here’s an excerpt from a human body definition:

<BodyPart Name="Left Eye" ParentName="Head">
	<MaxHealth>3</MaxHealth>
	<IsRoot>false</IsRoot>
	<IsBranch>false</IsBranch>
	<CapacityFactors>
		<CapacityFactor>
			<CapacityName>Sight</CapacityName>
			<Factor>0.5</Factor>
			<WeakLink>false</WeakLink>
			<Influences>
				<DamageType>Any</DamageType>
			</Influences>
		</CapacityFactor>
		<CapacityFactor>
			<CapacityName>Pain</CapacityName>
			<Factor>0.7</Factor>
			<WeakLink>false</WeakLink>
			<Influences>
				<DamageType>Any</DamageType>
			</Influences>
		</CapacityFactor>
		<CapacityFactor>
			<CapacityName>Manipulation</CapacityName>
			<Factor>0.5</Factor>
			<WeakLink>false</WeakLink>
			<Influences>
				<DamageType>Any</DamageType>
			</Influences>
		</CapacityFactor>
	</CapacityFactors>
</BodyPart>

An example of a capacity modifier:

<CapacityMod Name="Steadfast">
	<CapacityName>"Pain"</CapacityName>
	<Description>"You handle pain better than most people."</Description>
	<Modifier>2.5</Modifier>
</CapacityMod>

Each body part can affect the capacities of a pawn. The eye body part affects the sight capacity by a factor of 0.5, which is to say that if a pawn has its eye destroyed, its sight becomes 50% worse. If both eyes are destroyed, its sight capacity falls to 0%, which affects its abilities in combat and so-on.

An example of a weapon:

<Weapon Name="Lead Pipe">
	<Usefulness>8</Usefulness>
	<Damage>8</Damage>
	<Range>0.6</Range>
	<AttackSpeed>1.2</AttackSpeed>
	<DamageType>Blunt</DamageType>
	<IsRanged>false</IsRanged>
	<MissText>%PAWN swings their lead pipe at %ENEMY, but misses</MissText>
	<DestroyText>%PAWN crushes %ENEMY's %PART</DestroyText>
	<DamageText>%PAWN clubs %ENEMY in the %PART with a pipe</DamageText>
	<KillText>%PAWN beats %ENEMY to death with a lead pipe</KillText>
</Weapon>

Usefulness determines whether a pawn should prioritize a weapon (for example, a lead pipe is vastly preferable to a flimsy stick).

An example of a character:

<Character Name="Johan">
	<Attributes/>
	<Aspects>
		<Aspect>Clumsy</Aspect>
	</Aspects>
	<Competencies>
		<Competency Name="Strength" Value="4"/>
		<Competency Name="Marksmanship" Value="7"/>
		<Competency Name="Vitality" Value="3"/>
		<Competency Name="Constitution" Value="5"/>
		<Competency Name="Dexterity" Value="4"/>
	</Competencies>
</Character>

There is also a built-in editor for existing characters, however it lacks the ability to modify the aspects assigned to a character.

The map is a dynamically generated mesh using the Unity terrain object. Patches of dirt and sand are added using simplex noise to determine which vertices have which texture. Objects are scattered on spots all over the map using raytraces. There’s a day/night cycle where the amount of light affects the visibility on the map, and therefore how effective some pawns will be with their weapons. There’s also a set of controls on the top left which allow the user to speed up time, pause, check the event log and open the stats of a specific pawn.

The action log allows the user to see exactly what is happening, in depth. The character inspector lets them see the vital stats of characters and their current action.


This is technically abandoned although with a bit more polish i think it would be something worth releasing. In its current state it still needs some work.

Blender Stuff

Posted on - by nuke

Way back when Team Fortress 2 was popular, I decided to mess around with creating cosmetic items in Blender. None of it really went very far but i learned a lot about the Blender workflow.

Hits N Giggles

Posted on - by nuke

A culminating group project done for a game dev course. It was a lot of fun to work on and was a resounding success.

Features:

  • Local multiplayer with support for 4 usb controllers as well as keyboard WASD/arrow keys.
  • 2 playable characters with their own unique look and different abilities.
  • A “comeback mechanic” where you get a special weapon when you have 25% health. the rabbit gets throwable bottles in place of his melee attack, the bear gets a hammer with more knockback and damage.
  • Robust physics prop/gibs system. Props can be thrown at other players and have their own unique properties. Crates will sometimes contain other props.
  • 2 functional maps, each with their own unique hazards and traps.
  • Music player that plays the music in the game music folder, you can replace the included music with your own if you want.

The alpha demo:

The final product:

You can download it here.

Space Frog

Posted on by nuke

For an assignment I had to make an asteroids clone. I kept track of my progress with some videos. For fun i added some procedural parallax clouds.

Room Generation

Posted on - by nuke

Here are some screenshots of a room generation algorithm i wrote in action.

The idea behind it is simple enough but there are a lot of things that can go wrong in the process. It took the most time to make this algorithm robust since ~10% of the time it would generate disjoint rooms. Here is the process:

  1. Start with a grid of blue tiles.
  2. Hollow out some grey rooms randomly, using some constraints such as max/min room size. Rooms should not touch.
  3. Create corridors between rooms. For each room we make one or more corridors (also based on constraints that we can change) to another room. When creating corridors, we have to make sure the tiles on either side of the corridor are blue or else we end up with corridors merging. We also need to ensure the corridor doesn’t attach to a  room corner (since corridors are 2 tiles wide).
  4. Check each room and make sure it can be reached by all other rooms. If one room can’t be reached, discard all corridors and generate them again until a configuration is reached which satisfies this constraint.

 

The more variables you expose, the more interesting configurations you can get. The leftmost image has smaller rooms with a higher chance to have several corridors per room, the rightmost has larger rooms with less corridors.

Cellular Automata

Posted on by nuke

This was a little test project I made to experiment with cellular automata.

Simplex noise can be a very useful tool for accomplishing the same result, but it’s nowhere near as customizable (or fun) as cellular automata.

Here is how it works (i had a rough idea of how this works beforehand but this is for those who might be interested):

1. Create a 2d grid of tiles. turn roughly 50% of them red, at random. Depending on the rules you choose for the cellular automata, you may need to tweak this to be closer to 40% or 60%.

2. Decide on the rules you want to use for each tile. To make this a little easier to understand, imagine that each tile is a living organism like bacteria or something. The organism will either die or expand to other tiles based on its rules. The classic “5-4” rule is as follows: a white tile becomes red if 5 or more of the 8 tiles surrounding it are red. A red tile becomes white if less than 4 of the tiles around it are red. We are basically saying: a bacteria starves to death if it is surrounded by less than 4 other ones, and an empty space spawns a new bacteria if it is surrounded by at least 5 others.

3. Apply the rules to each tile. In order to get desirable results, these rules need to be applied several times in a row. Over time, the cells will shift into a random, unique shape based on the rules you applied in each iteration.

That’s it. The above image is what i got from applying the 5-4 rule 5 times in a row to a grid of 50% white and red tiles.

…But it gets more interesting. We can change the rules to get vastly different results. We can also use different rules with each iteration. For example, we could apply a given rule 3 times, then change the rules and apply the new set of rules 5 times in order to get a totally unique result. The image in the bottom right shows some of the stuff i ended up with using different rule sets. You will also get different results depending on how many iterations you do. There’s an infinite amount of combinations of rules and iterations you can do which makes this a very cool method to use for generating worlds.

In my situation, i wanted to generate a world where there is only one main area (ie, no smaller disconnected white areas that can’t be reached from the main white area). In order to do this i have to first generate the world, then check each white area using a flood fill algorithm (kind of like the bucket fill tool in mspaint) to see what percentage of space in the world each area takes up. In the bottom left you can see this in action. The blue area is the main area and the green areas are the smaller detached areas we want to get rid of. The blue area takes up roughly 40% to 60% of the world space so it is easy to tell which ones are small and need to be discarded (the green ones). In the case that the main area takes up less than 40% of the grid we can always just scramble the grid and start over.

The most popular use of cellular automata is conway’s game of life. Check it out if you wanna play around with this stuff in your browser.

If you are interested in programming something using cellular automata, this page is extremely helpful.

Tile-Based Untitled Game #2

Posted on - by nuke

This project was a sort of continuation of my other chunk-based grid project i created in MonoGame.

This one uses simplex noise combined with an ‘infinite’ chunk-based game grid. You can see where the chunks connect. There are 9 chunks in the grid and you start in the middle. If you move to an edge chunk, that chunk becomes the center and the chunks which are not immediately on the edge of it are erased and moved to become the new edges.

Combined with saving/loading the entities within a chunk, this means i could create massive procedurally generated persistent grids.

The 3 images show the difference between using different octaves with simplex noise (the leftmost image uses 8 octaves). I started work on generating cliffs (the orange outlines on the right image) but it’s going to take a different algorithm to properly generate cliff edges.

Here is some working on cliff generation, specifically marking the edges properly. To properly illustrate chunk boundaries, I made the chunk colors alternate between grey and white.

The top image is the initial cliff edge marking (any tan tile connected to a white tile becomes orange).

The second image shows the second pass where i convert all white tiles with 2 orange tile connections into an orange tile. This method actually gives worse results and causes large gaps between cliffs segments in different chunks.

The third image shows a tweaked version of the method used in the second. I am converting tan tiles to orange instead of white tiles to orange. It gives significantly more accurate results, still a few gaps to sort out though. I am missing a specific case related to chunk edges.

This simple method i am using works well. I originally used the marching squares algorithm to mark the edges of the tan blobs but it would have taken a lot of tweaking in order for it to give the proper results.

 

Stroller Simulator

Posted on by nuke

This was a simple thing i made while learning how to use Unity.

It started out with a simple randomly generated path and a stroller that continually rolls along it.

The path was too rough so i replaced it with a randomly generated mesh.

Next, I added particles.

I used this little project in a presentation about Unity in one of my electives.

 

Raytracer

Posted on by nuke

This was an academic group project for the computer graphics course i took. We had to write our own raytracer and implement several things such as shadows, motion blur and antialiasing.

Our final version had antialiasing with some basic supersampling, motion blur, randomly sampled soft shadows, refraction and more.

It started with a simple sphere being rendered.

Next, we added basic shadows and played around with reflectivity of surfaces.

Our shadows looked ugly so we refined them.

Next, we implemented motion blur.

We also wanted to import a 3D model so we grabbed a random trash can model online.

We also implemented a Cornell box and a few other things.

Overall it was an interesting project, ignoring the few sleepless nights we spent trying to get everything working before the submission date.

Tile-Based Untitled Game

Posted on - by nuke

This was another project I started in MonoGame. The goal was to make a gigantic grid-based 2D game. I don’t remember many other specifics, but the basic premise of the project was pretty ambitious.

The basic camera code and grid generation code were the first things i completed.

Once i had a simple grid generated, i wanted to take it a step further and create a grid of grids.

The grid became an 8×8 2D array of chunks which are 256×256 tiles. At most, there were 4 chunks active (within camera view). All other tiles were considered inactive until the camera moved within their visible range.

The tiles were colored to show where chunks begin and end.

After getting the grid generation sorted out, i doubled the size of the tiles and added a cursor (the white square). I also implemented some basic selection code. In this example, i could turn a tile yellow by clicking it.

In the top left corner i placed a basic player pawn entity as well.

Next I started work on my pathfinding for actor entities.

When you select an actor then click a tile, it runs a pathfinding function which computes a path to the tile (in the form of a queue consisting of tile objects). Then the actor starts de-queuing each tile and transitioning from tile to tile until it empties the queue. If a tile becomes impossible to traverse, then the actor will stop and re-call the pathfinding function, rebuilding the queue of tiles.

At this point i had also added an asynchronous load screen since generating all the world tiles took a bit of time.

This is where this project hit a dead end. In this case it was just a lack of direction.

 

Generic Zombie Game

Posted on - by nuke

Another game i wrote in Lua around 2011(?).

It is a round-based zombie survival game, with rounds typically lasting 15 minutes (although often ending much sooner when all human players die). You earn cash by killing zombies which can be spent on weapons and supply airdrops. If you die, you become a zombie.

Some notable features:

 

• Challenging gameplay. A strong emphasis on teamwork and inventory management.

• A dynamic weather system. Thunder, lightning, particle-based rain and wind. The weather is randomized each round.

• Random events. They happen over the course of the round. Some are good, like scientists and supply crates appearing. Some are bad, like temporary radio blackouts. There’s even an event which causes a wicked storm using the weather system.

• Intelligent zombie NPCs that hunt you down. They can also break through doors, breakable walls and windows.

• A bunch of scripted weapons which implement scopes, ironsights, bullet penetration and more.

• Melee weapons, including a hammer which can be used to build barricades using wood planks.

• An inventory system that is very modular. You can add your own items with ease.

• 4 human classes and 4 zombie classes, each with their own perks.

• Fancy effects. Motion blur, postprocessing, realistic drunkness/infection/etc, blood spatter on your HUD, and probably more.

• Lots of gore effects. Blow the torso off of a zombie with a winchester, create showers of guts with explosives, instantly fry zombies with laser weapons and blow the heads off of zombies with pretty much any gun.

• Ailment system. If you are attacked by certain zombies you will start to bleed. If you are hit by zombies you become infected. You can also become irradiated from certain things.

• Replayability. Never play the same match twice. The infection antidote spawns randomly around the map throughout the game, and the evacuation helicopter has multiple landing zones.

• Stats. At the end of the round awards are handed out to players who have accomplished great and not-so-great things. If you’re one of those fellows who hides in a corner while his teammates do all the work then you will get publicly humiliated. If you are a skilled player then you’ll get a pile of accolades.

• Parameters that give the server owner complete control over most gameplay aspects.

• A custom entity loading system for maps which do not officially support the game script.

I originally wrote this game several years ago, before the original Left4Dead game was released by Valve Software. There are a bunch of gameplay videos on youtube, search for “ReDead Gmod” or something along those lines if you want to see more.

There are plenty of gameplay videos on YouTube as well.

The scripts are freely available: https://www.assembla.com/code/redead/subversion/nodes

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.