Overview

Scope. What is scope? Why do we care about scope? How does scope fit into game development?

In game development, “Scope” is a word you’ll hear a lot when designing a game. Scope is a way for everyone on the team to know if a game is achievable within a certain timeframe. Scope is how we determine how many features a game can have. Scope is dependent on time, and the work that is done on a game is dependent on scope. Scope—in its simplest meaning—is how big and how complex your game is. The achievability of this product, game,  software, or whatever project you’re relies on the scope and the amount of time you have to finish your project.

Feature Creep

Feature creep is a phenomenon that describes the action of adding more features to a project after the scope of the game has been predetermined. Lead Developer of Sintel: The Game, Jon Buresh has this to say: “Without a predetermined scope, your project will suffer from feature creep, and you will never finish until you decide on an [achievable] scope.” Feature creep happens a lot in game development, and it is certain to happen to new game developers. You will sit down, write a nice design doc, technical design doc, and all the other documents you need to write to plan for your game. You will start developing your project, and then a few weeks, or months down the line, you might start thinking, “You know what would be a cool, is if we added [… this, and that, and all these things]” And from that point, you’ll think of cool features you want to add in that you never thought of in the beginning. This leads to having an “overscoped” game.

Overscoping

“Overscoping is easy/common as you come up with more ideas. Set them aside or replace existing [features] rather than adding more” says Ross Derham, Lead Narrative Design on Grey: The Lost Technology. Overscoping a game is something that happens all the time when starting a new project. You have a deadline that you want to create a game by, and you have so many ideas that could make a game REALLY awesome, but that deadline… it seems so far away, maybe you can get away with a few more mechanics… Sooner or later you’ll realize that you have too many features planned for the game, and you will have to make some cuts to meet the deadline. When working with a deadline, and you’re starting a new project, you have essentially two ways to determine the size of your feature set. Desire and Necessity. “Necessity is the determining factor usually when a promised deadline is announced of when funds are running low and a profit from the project is required. This usually restricts details and features in the end result. Time based on desire has a much looser timeframe and usually takes a longer amount of time. The tradeoff, however, is that all of the details and features that the developers want in the game will be there, regardless of how long it takes. To get all details and features in the game a short amount of time is ideal, but difficult to achieve because it is based largely on team size and team skill” says Bryan Gabay, Lead Systems Design on Grey: The Lost Technology.

Protips

• Hold a team meeting when creating a new project. Get a large notepad and write down every idea that comes up. Look at the ideas with the dealine in mind, then start crossing off the ones you know you won’t be able to do.
• Create a paper prototype of the game if possible. This helps to define mechanics of the game, and allows you to recognize possible flaws of the game, as well help determine scale of the project.
• Write design documents before programming anything. The features need to be well documented, and well understood by the team developing them. This will increase productivity as there is no guessing how a feature is supposed to work. This means that no one needs to expand an existing feature.
• Technical design documents need to done as well. Programming a new system can be a high risk situation, so designing the system before you program it will ultimately help in the end.
• With the deadline in mind, look at the team size, and look at the feature set. Create a milestone list that has deliverables for each sprint (1-2 weeks). This will help determine if you’ve overscoped your game or not.
• When programmers start programming: Create a fully featured prototype that has every mechanic of the game implemented in as short of a timeframe as possible. This will speed up development of the game dramatically as designers will be able to tweak the game to polish it, and the artists will be able to create as much art as they need to. At PAX 2012, we met up with Super Giant Games, makers of Bastion, and they showed us the prototype they made for the game. It was feature complete, and it took 4 weeks to make it. There was no art, and much of the game was primitive and untweaked. But all the mechanics were there.

So I decided to do a little bit of research on tactical analyses and decided that I would share my findings with you.

Tactical Analyses are complex AI techniques also known as influence maps, most commonly used in RTS games. The point of a basic tactical analysis system is to allow an AI to make smart, tactical decisions based on a variety of variables depending on the game or situation and genre. In order to accomplish this, the AI calculates the military influence of each area of the map to understand where the enemy presence is weak and where they are strong. This post will focus on the most basic element of this technique, however, the ability to calculate the simple influence of each node in the world.

It is important to understand the factors that contribute to an influence map. The most common one is that any unit exerts a certain amount of influence around the area that they occupy based on range, power, level, etc. The farther away from a node that a unit is, the less influence the unit applies to that node. Many other factors are also used to affect influence such as military bases, terrain, weather, time since an area was occupied, and more. These also play an important role in how an influence map may be constructed. So how is this used?

Almost all influence maps today operate on a grid based system. This means that if the game that it is being implemented in is not tile or grid based, then a grid must be constructed on top of the terrain. We can then use this grid system for distance calculations which play a large part in any influence calculation. We can use the linear formula

where I_d  is the influence at a given distance (d) and I₀ is the influence at a distance of zero to represent the linear decay of influence in relation to distance from the unit. While the linear model is usually the most efficient, non-linear models may also be used depending on the situation required by the game.

These values are calculated for every unit in the game considering every unit in the game, which means that it becomes very processor and memory intensive. The processing execution time is represented by O (nm) while the memory used is O (m) where m is the number of locations in the game and n is the number of units. As a result, three methods of lowering the intensity of these operations have been created; Limited Radius of Effect, Convolution Filters, and Map Flooding.

To limit the radius of effect, each unit is given a maximum distance that they can apply influence to. This allows us to pass through every unit in the game and only apply influence to any nodes that are within that minimum distance, which significantly lowers the processing time to O (nr) where r represents the number of nodes that are within the average radius of a unit. Rather than manually giving each unit a maximum distance, we can instead calculate the radius of influence of a unit if we set a base threshold of influence. Using the linear influence formula, we could get the influence radius of a unit by using

where I_t  represents the influence threshold.

Convolution filters are much more complex than limited radiuses. With this method, we start by creating an influence map where only the nodes that are occupied by units are marked as being influenced. The game then makes use of graphical programming to apply filters to the map, blurring each unit’s initial influence to the area around it, effectively creating the influence zone of each unit. The most common filter that is used for this technique is the Gaussian filter, which is used frequently due to the mathematical properties that make the calculations required easier. This approach is actually more processing intensive than the original formula; however, the majority of the processing is being done by the graphics card, freeing up the CPU for other processing while performing the calculations quicker.

The last approach, map flooding, is able to achieve optimization by using the largest influence of the current units rather than calculating each nodes influence. The idea behind this method is that when a single strong unit is influencing a node, then that node won’t be affected by other, weaker units that are nearby. This allows the AI to use a version of Dijkstra’s pathfinding algorithm to apply that one influence value to every node in its zone of influence, rather than calculate the influence value for each node based on what units are affecting it. As with the other methods, this is not always the best method and it is very situational.

While tactical analyses are primarily used for RTS games, it has also been used in FPS games very effectively. The role that it plays in videogames is sure to expand and it will be interesting to see any further advancements that may occur in the coming years.

Bibliography

McCloskey, John, Jeffrey Miller, Amish Prasad, and Lars Linden. “AI in First-Person Shooter Games.” Lecture. Eastern Michigan University. Eastern Michigan University. Web. 10 Dec. 2012. <http://www.emunix.emich.edu/~evett/GameProgramming/LectureNotes/FPS.pdf>.

Millington, Ian, and John David Funge. “6.2 Tactical Analyses.” Artificial Intelligence for Games. Burlington, MA: Morgan Kaufmann/Elsevier, 2009. 518-553. Print.

See, John. “Tactical & Strategic AI.” Lecture. Multimedia University. Multimedia University, 10 Jan. 2011. Web. 10 Dec. 2012. < http://tinyurl.com/cy4z3wn>.

For the last few months we have been working with composer Matt Gates to come up with what we believe is the best soundtrack we could have. As it is nearing completion we have decided to share parts to help give you an idea of what has been accomplished. Let us know what you think by commenting at the bottom or by posting on our Facebook page.
http://www.youtube.com/playlist?list=PLCHxNTlByLqpy9ZfmcGWd5XqsLjM3NDYh

Hello everyone! As a fun way to give back to our friends and fans, we thought it would be cool to hold a naming contest for Grey: The Lost Technology!

Read on for rules/how it works…

THE CONTEST:

Name characters and/or towns/villages in the actual game!

THE RULES:

Each participant is allowed to submit three (3) names per category. After the contest is over, Team Aurora will choose finalists from each category and post on the website and Facebook for the fans to vote which name is their favorite in each category!

THE CATEGORIES:

Each participant may send up to three (3) names per category. Participants do not need to send names in all categories, but it is suggested for an increased chance in winning.

-Towns/Villages

-Utopian Citizens

-Nomadic Citizens

THE PRIZE(s):

For having one or more of your names chosen you will have the glory of having named someone or somewhere within the world of Grey: The Lost Technology as well as have your name in the credits of the final game.

Along with your name in the credits, winners will be allowed to help in beta-testing for the game!

SUBMISSION:

To submit your names, please separate them into the three categories above and send them to contact@teamaurora.net or message Team Aurora on Facebook.  Remember to include your name/email so we can feature you in the credits/send you beta-testing information!

Good luck to all participants and thanks as always for your support and dedication to the game and the team!

Much love,

Team Aurora

Hey guys so we do not feel that the demo is in good enough shape to release at this point in time, so we are going to take another two weeks to polish it. Right now we are planning to release it on July 15th, but we have a lot of things planned the next two weeks as well, so be on the lookout…

Hey There Everybody! 

Chris here, with your very first artist’s development diary!

So Markel and I been having a lot of fun lately scooping up all the ideas the designers are coming up with and turning them into fancy concept art for use in the game. So far we’ve been fleshing out the way each character will look, and how our beloved Utopia will appear (i.e. how it’ll be laid out, what kind of buildings we’ve got going on) and pretty much figuring out how the “lost technology” will be implemented into the everyday lives of the utopians, in an aesthetic (and functional) way.

Recently, though, we have been taking all these wonderful concepts and started turning them into in-game assets! Most of our time with the assets has gone towards character development, specifically taking all of the character concepts we’ve got and converting them into 64×64 sprites on a sprite sheet. So far Markel and I have been drawing each frame of an animation in photoshop (based on a character template we created to maintain proportions). After each sequence of drawings is complete we bring the .pngs into Adobe Flash to set up the correct timing for the specific cycle of animation, then save out the completed animation as a .swf. Once this is completed we use a program called SWFsheet to convert our new .swf into a nice, clean sprite sheet. Although this has been “working”, it hasn’t really produced an appealing animation, and alot of the 12 principles of animation aren’t showing up. We’ve been discussing various techniques to use in place of drawing each frame in photoshop, and we may decide to eventually use 3D models in proportion to the characters (with Autodesk Maya), do all of our animations in 3D and then convert the finished product into 2D pixelized frames. This sounds more difficult, but we would simply have to divide the body parts up in pixel form and overlay each part of to the position of body part in the 3D render. From having done animation in both 2D and 3D now, I can definitely say that animation in Maya is a heck of a lot easier.

The static objects of the game have proven to be a lot easier and a lot more fun to create. The team is planning on having the first playable demo for Grey: The Lost Technology finished by the end of July, which will bring our players the first ever chance to follow Oren through the streets of the Utopia. Within the last few days the two of us have begun the construction of the utopia, starting with the basic house structures and city streets. Our technique is fairly simple, we’re making many separate assets that would make up a building (doors, windows, awnings, etc.) in multiple styles and designs, and using this in different configurations to create unique looking buildings. All of these assets are being made in photoshop. Besides the characters and buildings, we’ll be creating a few particle effects to spice up gameplay, as well as a very basic HUD, targeting and dialogue system for now.

So as you can see, Markel and I will be keeping pretty busy for the rest of the month, and we hope you check out the demo when we share it next month! Until then I hope you’re all having an awesome summer! Peace.

-Chris O’Connor (Artist)

We are happy to announce that Matt Gates will be composing an original soundtrack for Grey: The Lost Technology! We had an online meeting with him a couple of days ago and we think that he will fit right in with the team. We are confident that Matt will be able to deliver an awesome soundtrack for the game and we are very excited to be working with him.

If you want to learn more about Matt or hear what he has to offer, check out these links:
www.symphonicuproar.com
www.soundcloud.com/magates
www.facebook.com/magates
http://www.imdb.com/name/nm2015534/

Hey,

Recently I’ve been optimizing the way that maps are saved and handled. Before I go too deep, let me tell you about how the maps work in the game. Essentially a map is made up of individual map sections that can be modified and saved and etc. For example I can create a dungeon that is 4×5 sections, and each section is 25×25 tiles (Every section must be the same size). What I have been doing when a map is created is immediately saving all the sections. After creating a 4×5 section map, there are 20 files, plus 1 to hold random details. In the end we have 21 files.

This isn’t all that bad, BUT when you start working with maps that are 16×14, and have 224 sections things can get very troublesome, especially in terms of file size. Previously for us, the main map of the game was 25 MB in the end, NOT EVEN WHEN COMPLETELY FILLED IN WITH TILES. Needless to say, there was a lot of filler text that wasn’t doing much. At that point, I was expecting that we would have 125MB-200MB of map files in the end, and just can’t have that. In the map files, I was limiting the designers to 4 layers of tiles, and saving the entire 2D arrays. That means that spots in the array that didn’t have anything in them would still get written out to the files, and that was the main reason that there was so much filler text taking up space.

So I devised a new method to saving maps. The main idea is that I only save out to our level files the things that were only necessary. This seems so trivial, but when you need to get a prototype out, optimizations aren’t exactly your main concern. Essentially, this means that we skip writing out all the tiles that don’t exist yet. Because of this I also had to change the way that tiles were stored. As I mentioned previously we were using a 2D array to store our map data, and that was way to restricting, especially in terms of the how much memory it took to store it and manage it. To remedy this situation, I switched over to a Dictionary. But using a dictionary, we are enabling ourselves to only hold the data we need, rather than all the data we could possibly have. Another benefit of this is that the designers now have more control over the levels; they are able to create as many levels of tiles as they want.

To make it all work, we ended up writing a custom implementation of the XML serializer and kind of being pretty creative when storing the dictionaries. Because of this little change, and writing out only that data that we had at the time, we effectively reduced the map size from ~26MB to >1MB. Yeah, less than 1 MB. To note, in the previous map implementation, I was writing out a lot strings, and I avoided that as much as possible by storing strings in and array, and then writing out the index positions to the strings. This way we only had to write those strings once in the file, and then all that had to be done is just write out a few numbers here and there.

tl;dr: Maps were big, now they are ~4000% smaller. Only save data you need, not data you could possibly allocate.

Much love,
Tom

Hey,

We have been working very hard to bring you something to look at. And today, we have done just that. The video below showcases a few cool features of the game, and essentially the building blocks for the rest of the game. I hope you enjoy it!

Hey everyone!

As previously mentioned, we now have two amazing artists on the team, Chris and Markel. They’ve been hard at work doing art for Grey: The Lost Technology. Before we get started, I’d like to say that the art direction we are going for with the game is pixel art. BEAUTIFUL PIXEL ART!! Chris and Markel have done just that! But it’s often hard to make some pixel art without first having done some concept art. So, checkout some art for Grey: The Lost Technology:

In other news, we are going to PAX East! If you find one of us (we’ll be wearing black Team Aurora t-shirts) say hey! We are hijacking part of the Champlain College table (table 158, by Rooster Teeth) and will have some cool Team Aurora and Grey: The Lost Technology stuff on display. We are also planning on reporting back here with anything we find/like at PAX, so check back here for some updates (possibly videos)!

We also have a Kickstarter page up, which can be found here: http://www.kickstarter.com/projects/2084358841/grey-the-lost-technology

Spread the word to anyone/everyone because Grey: The Lost Technology is going to be awesome. And not just ’cause we’re biased either (well, maybe a little bit).

As always, thanks for your support and continue to follow us here, at our twitter (@TeamAuroraGames) and facebook (teamauroragames) page.

Have a good one guys and see you on the other side of PAX!