Work-in-progress: HITBLOCK

I’ve been working on a new project over the last couple months in order to familiarize myself with Unity 5. The basic concept is a minimalistic stealth/puzzle game, in the vein of Hitman or Hotline Miami.

The above video is a quick demo of the NPC Guard AI. I also have NPC Civilian AI working at the moment (with appropriate “flee in terror” behaviour), but there’s still a few kinks to work out, mostly related to interacting with guards to tattle on the player.

Advertisements

AQUARIUS: Remaking “Submersible” in Unreal Engine 4

I was contacted by Epic early this year about a possible opportunity as a UI programmer. It didn’t go anywhere, but it did set off a chain of events that led to me learning how to make games with Unreal 4.

I decided to get my feet wet by re-making one of my projects from programming school. The game ran in a custom 2D DirectX 9 engine I’d built, which I later went on to use for “Fireflies.”

The aim was to keep the gameplay identical, and just translate everything from sprites to a 2D plane in a 3D game world. The original ending to “Submersible” was also quite anticlimactic, so I decided to throw in some additional content there as well ūüôā

I quite enjoyed using the visual “Blueprint” scripting system- although, the way some of the way I wrote calls to it from C++ felt a bit inelegant. There’s probably a better way that I’m not privy to, but it works.

Development Retrospective: FIFA 15

AAA Game Development is neat!

FIFA 15 (In Menus)

I think the seven months I spent at EA working on this title were the most fun I’ve had in game-dev since my first year of programming school. It was so nice to be able to focus¬†on a single aspect of a game and polish it to near-perfection, after jumping between disciplines on prior projects with smaller teams. As an added bonus,¬†working with the new generation of console hardware so soon after it’s initial release was very exciting!

FIFA 15 Kick Off (In Menus)

 

I started working on the project¬†in the middle of production, so for the most part my responsibilities involved creating and tweaking¬†menus and UI¬†components. FIFA has a lot of game-modes, and menus specific to those modes, most of which share common components. Ensuring that modifying a component on one screen doesn’t break it on another is a very time-consuming (though necessary) process!

FIFA 15 Skill Games (In Menus)

 

Flash, Actionscript, Flux, and C++ were all used during my time working on the game.

Fireflies

As I’ve said before, Fireflies is a simple RTS heavily inspired by E McNeill’s “Auralux”. The purpose of making it was to¬†exercise¬†my programming skills and try out some new stuff.

Something I’ve always wanted to add to a game, but never had the time or know-how, was a proper level-editor. I feel I did a¬†relatively¬†good job, even if the Editing UI is super basic.

It also made it much easier to test the AI by being able to quickly generate a scenario and run it without having to recompile or restart the program.

The game also features a scripted tutorial.

These are screenshots of the final build. Download the game here.

 

 

Work In Progress – Fireflies

Fireflies is a project I started working on after finishing school this year. I was getting a bit tired of using third-party middleware, and decided I wanted to try something fresh that had a large focus on optimization.

The gameplay and visual style would be heavily based (as in “I’m not claiming this is original at all”) on an Indie XNA game called Aurora. It’s an RTS simplified down to it’s base essentials- units and unit production

Player start with a base which repeatedly generates units. if two enemy units collide, they are destroyed. Neutral bases around the field can be claimed by “investing” a certain number of units into them. Some bases can also be upgraded to produce additional units by investing units into the base. Invested units are destroyed. Bases lose health when enemy units collide with them, and do not gain any additional health if upgraded.

I’ve never tried making an RTS before, though I do have¬†experience¬†managing large¬†numbers¬†of objects, all potentially interacting with each other.

Collision detection between units is handled by a 50*50 hash table. Wherever possible, memory is reused as opposed to being initialized and deleted repeatedly.

The part of the game that I was really excited to get working on was AI. The most experience I had programming AI was acquired from working on Interstellar Excavation, and that also had a focus on strategically capturing key locations, albeit only with one unit per player.

The approach I’m going to try first with Fireflies¬†is having the AI manage each base individually, coming to the best decision based on the base’s location and nearby idle unit count. To save performance, only one base will be considered per call to the AI Process function each frame.

I created a logic flowchart before working on it to organize my thoughts:

No, obviously there’s a bit missing, like a case for repairing damaged bases or defending ones that are under attack. This is because I wanted to test¬†these¬†key features before¬†committing¬†to the each-base-makes-its-own-decisions model.

A little bit of implemetation and bug fixing later, and this is what the above looks like as a function (At this point, I’d taken to labelling bases ¬†as “Lanterns”:


/*
 * Processes tha AI for this Frame
 */
void CPlayer::ProcessAI()
{
	//Get the Next Lantern in the list
	++m_iCurrentLantern;
	if(m_iCurrentLantern >= m_pLanternManager->GetLanternTotal())
	{
		m_iCurrentLantern = 0;
	}
	CLantern* pLantern = m_pLanternManager->GetLantern(m_iCurrentLantern);
	CLantern* pTargetLantern = 0;

	//Do I Own This Lantern?
	if(pLantern->GetPlayerID() == m_PlayerID)
	{
		//Does this Lantern have a sufficent number of 
		//nearby units to attempt an aggressive move?
		if(pLantern->GetNearbyFriendlyUnitTotal(m_PlayerID) >= k_iUnitsRequiredForAIAggression)
		{
			//Are there any nearby unclaimed Lanterns?
			pTargetLantern = pLantern->FindNearbyUnclaimedBase(m_PlayerID);
			if(pTargetLantern)
			{
				pLantern->OrderUnitsToTarget(m_PlayerID, pTargetLantern);
				//End Turn
				return;
			}

			//Can This Lantern be Upgraded?
			if(pLantern->GetLevel() < pLantern->GetMaxLevel())
			{
				pLantern->OrderUnitsToTarget(m_PlayerID, pLantern);
				//End Turn
				return;
			}

			//Are there any nearby enemy Lanterns?
			pTargetLantern = pLantern->FindNearbyEnemyBase(m_PlayerID);
			if(pTargetLantern)
			{
				//Do I have Enough nearby Units to take it?
				if(pLantern->IsThisTargetAcceptableRisk(pTargetLantern))
				{
					pLantern->OrderUnitsToTarget(m_PlayerID, pTargetLantern);
					//End Turn
					return;
				}
			}
		}
		else
		{
			//End Turn
			return;
		}

	}
	//or Is It Unclaimed/Hostile?
	else if(pLantern->IsAligned() == false || pLantern->GetPlayerID() != m_PlayerID)
	{
		//Send any nearby Units of mine to start capturing it.
		pLantern->OrderUnitsToTarget(m_PlayerID, pLantern);
	}
}

Initial results look okay- technical performance is good, but the simplicity of the above chart is reflected in how the AI plays; each player expands naturally until a stalemate forms over capturing the middle  base.

At this point, anytime the middle base is beaten back to neutral status, THIS happens. It’s a result of the Unit-requirement¬†for taking neutral bases being significantly lower than attacking an un-upgraded enemy base (100 vs 150).

Eventually, one player is able to overcome the other two, but there’s no¬†strategy¬†involved- it’s just a result of who gets what before all that’s left is the middle base.

So,¬†what¬†I’d like to do now is give the AI some more complicated, ¬†interesting options- Determining where the frontline is, reinforcing bases that are under attack, ¬†and making more wise decisions about when and where to attack. If you’re interested in seeing more of my ¬†source code samples, you can always contact me.

Giraffic Park

Title Artwork by Tim Shepherd

I learned more about team dynamics from this project then any other I’d worked on previously. A team of 7 Artists and 7 programmers were given 4 months to create whatever we wanted, as long as it showcased the skills we had learned over the course¬†appropriately.

The chief issue was, this was the largest group and time frame any of us had worked with thus far. Pre-production was slow to start because there was a lot of conflict within the group over what the project should actually be.

We eventually settled on a platformer, not realizing how art-and-content-heavy this type of game actually was. Naturally, we overscoped.

We got the¬†opportunity¬†to use Havok’s Vision Engine for this project, which was both good and bad- It had an expansive feature set and level editor, but we spent a good deal of time¬†learning¬†the ins-and-outs of how it worked.

Boxart by Bronson Bradley

The pitch for Giraffic Park was absurd, by design: A young viking child crashes  on an island, and his fighting abilities are based on the concept of using the heads of defeated enemies as weapons. Each animal head grants him a unique secondary ability, eg. Snakes allow him to swing from ledges, elephants repel enemies by spraying water, etc.

The player has to progress through the level, avoiding traps and fighting different enemies until he/she reaches and defeats the final boss. If the player dies, they revert to the last known checkpoint.

For this project, I worked mostly on UI, designing and implementing a menu system from scratch, using nothing but Vision’s provided 2D Sprite class. This ended up working in my favour, as I was able to spend more time polishing and less time learning how to use Vision’s provided menu systems.

I also implemented the Save/Load system, checkpoints, sky-box transitions, control tool-tips, and HUD.

Here’s a gameplay¬†trailer¬†I put together:

Here’s a quick demo of the 2D/3D Menu I¬†implemented: