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.
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.
AAA Game Development is neat!
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!
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!
Flash, Actionscript, Flux, and C++ were all used during my time working on the game.
It’s called “Spindie | Smashproof”!
It’s on the iTunes App Store! And the Google Play store!
It’s got Music and Basketballs!
I worked on the tools! And also the Basketballs!
It’s also got my name in the credits (below that restore button)! Wheee! 😀
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:
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.
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.
Subtitle: Prophecy of the Birdman
Shadow is a 3rd-person multiplayer combat game created in 8 weeks by a team of 4 artists and 5 programmers.
The initial concept for this game was inspired by an episode of Samurai Jack, whereby the game’s monotone colour scheme allows players to easily blend into the environment.
The secondary goal of the project was to familiarize ourselves with Unreal Engine 3. None of the programmers had any prior experience using the engine, so we would be learning how to implement features using UScript and use the engine’s tools on the fly, from scratch.
The areas of the project I spent the most time on include Player movement, camera set-up, animation and animation transitions, networking, and particle implementation.
Submersible is a simple two-week project I created after returning to MDS for my Diploma of Game Development.
Over the Christmas holidays, I’d retrofitted the DirectX engine I used for Island with a much improved 2D Sprite system, using what I’d learned while working with DirectX sprites on Interstellar Excavation.
The game itself is fairly straightforward- Dive in a submarine 10,000 meters to the bottom of the ocean. Obstacles you’ll have to overcome include enemy sea-creatures, lack of light as you dive deeper, and your sub’s physical limitations.
Players can kill sea-creatures for money, use the money to buy upgrades at the surface. Simple stuff.
You can download Submersible here.
This is the final project a team of 7 programmers (including myself) created during our first year at MDS. It took 8 weeks to complete, two of which were spent on pre-production.
The core scoring mechaninc is similar to the classic lines-and-dots game, in which player are driven to capture territory before their opponents.
The game features a top-down perspective, and each player controls a vehicle navigating about a grid of nodes. when four adjacent nodes are captured, the parcel of land inbetween them is claimed, generating income for the player. the player can then spend that income on defenses for the parcel or upgrades for their vehicle.
The game continues until the round ends, at which time the each number of land parcels for each player is totalled and a winner is declared.
The design goal was to create a game that was easy to jump into, but had enough depth to allow players to formulate a number of unique strategies.
The whole of the game was written from the ground up using DirectX, with the exception of audio, where we used FMOD. I was in charge of user interface and AI.
This first video shows four human players competing. The following video is 1 human player and 3 AI opponents.
The most recent build can found here.
Kurt Nadworny 