Designing an Assault Level for Firearms|Source

2011-12-20 5:18 AM

Assault Game Mode Overview

FAS is introducing a new gamemode for version 2 called Assault. Like the current Push game mode this game mode involves push points but the similarities end there. There is an attacking team and a defending team, only the attacking team may capture points and the defending team may not recapture lost points.

After set time intervals the attacking team takes a negative reinforcement hit for each uncaptured push point. This is intended to encourage the attacking team to attack because if they turtle they will lose from reinforcement drain. When the attacking team does capture a point, they receive a large reinforcement bonus, further incentive to keep pushing.

Obviously a scoring system alone does not mandate how the player will actually play the game. To do that you design your level with the intended gameplay in mind. I will share some considerations and tips that will hopefully help our community mappers author AS maps.

Layout and Spawn Placement

My philosophy when designing an AS map is to consider the map a series of mini levels. Each focusing on a specific conflict.

There should be ample focus on the point of conflict for each AS point. You need to make sure that both teams have a similar travel time to the current AS point so that it isnt too easily captured yet isnt a stalemate. This design consideration infers that progressive spawns are absolutely necessary. In fact I would go so far as to say a separate set of spawns for each AS point is required.

In the case of AS_Caliber, I have been tweaking the spawn positions each test by a few meters at a time to try to get the right feel of intense conflict at each AS point. Im quite happy with the current results but every once in a while you do get a stalemate. Fixing this in the level design by introducing cover, new routes, and restricting positions the defending team can turtle from are all important but Ive recently been considering introducing another tool to keep the game fluid:

I have been thinking about having 3 sets of defending spawns per point attached to a timer. For the first 3 mins the defending team spawns at the closest point which has a slight distance advantage over the attacking team. This is followed by the defending team spawning further away from the AS point at 3 mins then finally spawning even further away at around 6 mins. At that point the attacking team has a significant distance advantage (30-50 meters).

Heres the Pros/Cons to doing this that I can see:

Pros Prevents quick caps at the start of the game when teams are possibly not organized. Prevents snowball capping (when a team caps then caps again while the defending team is just getting their bearings) Should reduce long stalemates

Cons It could be interpreted that this punishes the defending team for playing well. If the defending team spawns too far away at 6 mins then they are practically giving away the point.

Further Thoughts

There are things I could do to alleviate the negative effects of the cons. The most obvious being that I need to make sure that the attacking team has a deficit on reinforcements if they dont capture an AS point within the 6 mins it takes to push the defending team completely back.

Post comments regarding your thoughts on this system. Im interested to know if you think this will help or hurt gameplay. Im interested in both a public user and clanner perspective.

Conflict Point Design Considerations

When designing AS points try to keep a few things in mind:

Do not provide a clear view for snipers or suppressive fire onto the capture point If you do this, you are pretty much ensuring that a well coordinated team will dominate at that point. If they can snipe, MG, and throw grenades into the capture area all day then theres little you can do besides try to cut around the side and clean out their nest. A well coordinated team will be able to prevent this from happening.

Do not box in the capture point On the other end of the spectrum is capture points that are too boxed in. Examples of this would be a small garage with 2 points of entry (the garage door and a small door somewhere else). This point is susceptible to many things including fragmentation grenades and flashbang grenades. The absolute worst culprit is the claymore. If you have limited access to the capture zone then the defending team can simply cover all entrances with claymores. The extra care you have to take to maneuver around them gives the defending team a large advantage.

Designing a point in AS_Caliber


Here is how Ive set up the 3rd AS point in AS_Caliber. As you can see it is protected from sniper fire by being a fairly guarded building, that said the capture zone is wide open inside to prevent people from grenade spamming. There are too many places to hide in the capture room to be exploitable by grenade spam.

There are currently 3 major points of entry for the attacking team that split into 4 paths of entry into the capture zone when in the building. Its quite possible that the defending team could put claymores on all the entry points and hold down the map too easily. I will be keeping my eye on this in our testing sessions. If this does make defending too easy I will be looking at ways to incorporate a wide entrance into the building that which would be more resistant to claymore exploitation.

Thanks for reading. If you have any suggestions on how to tailor a map to further fit the AS game mode post int he comments and let me know

If you would like to comment on the article or discuss AS level design please post on the Firearms Source forums. Here is the link to this article:

Tags: level_design tutorial

Strict(er) Game Development : A game in 70 hours.

2011-11-28 2:36 PM

Recently I’ve come into a situation where I have a bit of time before college starts up again for me in January 2012.

I’ve decided to take advantage of the time and study up on both the more difficult topics I will be taking at school and personal projects.

One of these projects is to make a ultra cut down version of a game I’ve been designing on and off for about 2 years. I will be developing in Flash using the Flixel library.

The goal is to make a full game in 70 working hours or less. This estimate includes everything from design through execution. This is to test my ability to manage my time and project scope.

I’m using the time tracking program Grindstone to track how I spend my development time. Once I’m done I’ll break down how I allocated my time on each aspect of the game.

I guess you define the genre a top-down action-RPG. I’m 12 hours into the game and have the basic NPC AI working, weapons ingame, and a basic level. I’m very happy with how the code is working out right now. I’ve managed to avoid the temptation to bloat the classes in order to cover all possibilities. Every chance I get to simplify my code I take. As a result so far implementing the gameplay elements has been relatively easy compared to past projects.

I’m now at a point where the basic mechanics are in game. I need to step away from the computer and start working on hammering out the game design. I estimate it will take 2-4 hours to get a decent plan going.

My experience with Flixel and Actionscript3 is really helping this time around. I spent a fair amount of time making a NPC system that uses baked rotations and still animates so that I can avoid the very large performance penalties of drawing a rotated sprite.

Now that the more mundane task of setting up the foundation for the game is complete I’m very excited to work on implementing the gameplay systems.


Cult Retribution : Reloaded

2011-11-03 5:30 PM

Last year I posted some videos of a shooter I was working on in XNA. Unfortunately I ended up going to school for programming and then getting a job through the School’s CO-OP program. Well things have died down temporarily and I’ve had time to catch up on many game related projects I had to put down when my studies began. I now try to spend a few days a week working on the game. The artist for the game also comes over and works at my place 1-3 times a week.

I find that working from home there are a lot of distractions, by having another developer working along side of me we tend to keep each other focus and get more work done together than individually. It also helps to be able to discuss design decisions in person. IMO that will always be better than over the internet.

The game we are developing is Cult Retribution which is a shoot-em-up game with leveling and weapon purchase/upgrades. I plan to use some RPG concepts to encourage players to use a wide variety of weapons rather than just a few choice OP (overpowered) weapons. I plan to do this a couple ways. One is to have damage types for bullets much like the traditional Final Fantasy Fire-Ice-Lightning types. Attacking a fire-element enemy with fire element attacks would do little damage but attacking a fire-element enemy with ice element attacks would do lots of damage.

Progress on the game has been getting better and better. I started the game by writing the engine which is interesting but it’s not game development. There was a lot of initial time where the artist had to wait for me to figure out how thing will be done in the engine before he could start working.

I’ve now got most of the engine work out of the way and have decided to write LUA exporters for the DAME level editor rather than write my own level editor. This has saved me a ton of time and allowed me to focus more on the game itself rather than it’s supporting technology.

In this video you see me create a level in DAME really quickly. Export it. Then load the level in the engine and play it.

Plans next are to add various scrolling cloud layers to the game to give a sense of height in the game. Post-processing shaders for different events are also being investigated. We want the game to have a much darker look than what you currently see in the video.

I will be making a point to post often about Cult Retributions progress both for the readers and myself so I can guage how much work I’m getting done.

Tags: cultretribution XNA