Category: News

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

“I want to quit my job and make games for a living.”

I thought my wife would fall out of her chair laughing when this sentence came out of my mouth.  After all, I was working a full-time job, attending multiple online college courses, and digging my way out of debt.  Not to mention I was in my mid-thirties and had zero professional game development background.  Hell, I didn’t even know what kind of game I wanted to make!

Instead her reply was “Okay babe, just be smart about it.” and she went back to drinking her quad grande two-pump mocha with whip cream and sprinkles.  At least I had one thing working in my favor.

Over the next couple of years, I would finish my bachelor’s degree, build a game demo, market it, crowdfund it, sign a publishing deal, and quit my day job to do what I dreamed of doing since I was a kid.  I actually made it!

Guts and Glory was my first video game project.  It hit #1 on Steam Greenlight, #1 on IndieDB.com (where it has remained for months) and has sold well over 100,000 copies in Early Access, where it hit the Steam Best Seller list for short time.  Version 1.0 launches this Summer for PC and Consoles

Screenshots of the (now defunct) Steam Greenlight stats for Guts and Glory

As a solo project, Guts and Glory was a big success, but it wasn’t easy.  In fact, it was one of the hardest journeys of my life and I made many mistakes along the way.  To help others who may be traveling this path, I’ve put together a list of helpful tips and advice.  I could probably write a whole chapter on each of these points, but I’ll do my best to keep them concise, yet valuable.

If you don’t like reading, you can find a summary of my story in the first half of the video below.

[embedded content]

 

Your passion will become a chore

Genius Game Development is 1% inspiration and 99% perspiration.

I think the altered Thomas Edison quote above sums up game development quite well.  Most of us get into this industry because of our love for the craft, but I think many of us don’t realize just how much work goes into building a game until we actually try it.  If you’re new to gamedev, realize that no matter how much you love what you do, there will be many days where it becomes a chore; it comes down to good ol’ fashioned hard work to actually finish a project.  If you realize and accept this before beginning, you will have an easier go of it.

Don’t let anything distract you from the task at hand!

Set a schedule and stick to it

How much time you spend on game development is less important than how well you spend that time.  When I first started, I could only allocate 10 hours per week on gamedev.  This broke down to roughly 1 hour on weekdays and 2 hours on weekends.  This is not much time at all to learn and apply such a complex subject. 

However, I made the most of this by religiously sticking to two rules:

RULE #1: Work the allotted time no matter what.

Every.  Single.  Day.  Sometimes this means staying up late, getting up early, or working on lunch breaks.

RULE #2: Keep each session laser-focused. 

Pick a thing to learn or do and work only on that task until complete.Zero distractions.

Eventually, I was able to increase my schedule, which brings me to the next point.

Carve out new time

Once you can stick with a disciplined schedule, it’s time to start carving out more time.  Think about your current job, for example.  How much time in each day is truly productive work?  Are there ways to do things faster?  Are there things that could be cut out completely or delegated?  Is telecommuting an option?  Can you work on your game or study during breaks?

I worked 50-60 hour weeks at a demanding Fortune 500 company.  Finding more time seemed impossible at first.  However, after learning a few productivity/time management techniques and convincing my boss to let me telecommute, I was eventually able to reduce my work weeks down to only 30-40 hours per week.  Again, a whole article could be written on this subject, but I’ll save that for another time.

Focus your scope

While we’re on the subject of time, let’s talk about project scope and feature creep.  Like most beginners, I made huge mistakes in this area and over-committed myself early in the project.  This led me to become very frustrated and burnt out.  It was only by pure discipline and necessity that I was able to push through the final months of development and complete the game.  (It’s in the publisher QA and porting stage now.)

To avoid this hell, it’s very important that you keep the scope of your first projects small… like really small.  Once you’ve decided on a game idea, cut it in half… then in half again… and again.  Boil it down to just the essential elements that will make a fun game.  Forcing yourself to work within very limiting constraints will allow your creativity to grow.

Also realize that it will take you 2-4 times longer to complete a given game development task than you estimate.  I’ve had a lot of conversations with other indie developers over the past year, and this is a recurring theme.  Trust me, your game project will always take longer than you initially planned!

In retrospect, I believe I could have built Guts and Glory with only bicycles and it would have been just as successful.  I could have put more effort into polishing those mechanics and building content around it.  In the end, I think I would have ended up with an even better game and more success, so consider that when you are planning the scope of your own indie game project.

[embedded content]

The right tools can save you a lot of time… and sanity

Work smarter not harder

If you’re a solo game developer like me, or a small team, it’s critical that you find every advantage possible.  Here are a handful of resources that I found very useful during the development of Guts and Glory.

ATracker:  Fast and easy time tracking app.  Knowing how you spend your time is key to optimizing it.  Time is your most valuable resource; you can always make more money, but you can’t make more time.

Evernote: One notepad to rule them all!  Keeping all your game ideas, development notes, learning resources, links, etc. in one place makes it easy to reference them later.

Trello: Don’t make the mistake of thinking you don’t need to write out a plan just because you’re a solo game developer or duo.  As the old saying goes, “measure twice, cut once.”  Planning ahead forces you to think through the steps and workload needed to actually complete the project.  Planning in Trello is about as lightweight and fast as it gets!  If you manage a team, consider something like HacknPlan.

Asset Stores:  Why build a 3D barrel model from scratch when there are already hundreds of pre-built models out there that you could use or modify to fit your aesthetic?  If you’re going to spend money, then take advantage of marketplaces such as the Unity Asset Store to save time where possible.  This applies to programming as well.  If you get stuck in your project, sometimes you can find a solution in the asset store that will either directly solve the issue or, better yet, provide you with a hands-on learning resource.  It always better to learn than to become reliant on solutions that may or may not be supported in the future.  I’ve found this to be a much faster way to learn than books alone.

Reallusion Software:   If you want a fast and easy way to produce high quality 3D characters or animations for your project, then I highly recommend checking out Reallusion’s software suite.  I discovered these tools rather late in development but found them very valuable.  So valuable, that I reached out to the company and now I’m working with them to help shape future versions of the software specifically for game development!  They have some very exciting features coming out this year for gamedevs! 

You can learn more about how I used Reallusion’s current tools here.

Round out your education

Learn business and marketing skills.  If you want to make games as your primary source of income, you need to remind yourself that you’re running a business.  Even if you partner with a publisher, having business skills at your disposal will give you a big advantage.

My professional background is in marketing, sales, and analytics, and these skills have proven useful for HakJak Productions time and time again.

Maintain your health and relationships

There’s no such thing as balance… at least not while working full-time and doing game development.  If you’re going to try and make a career-change to full-time, independent game developer, you need to accept the fact that this will be a period of sacrifice.  Even if you’re lucky enough to be in a situation that doesn’t require you to work a full-time job simultaneously, you’ll quickly find out that building a startup—any type of startup—requires an extraordinary amount of time and effort!

Fortunately, there are a few things you can do to prevent burn-out or ruined relationships.

1. Get good nutrition: What we eat can significantly influence how we feel.  Get the junk food out of the house and make healthy choices easy to grab.  Trust me, this makes a big difference in your productivity!
2. Exercise regularly: My health declined sharply when I transitioned from being on my feet all day to a sedentary desk job.  Get up once per hour and try to work out 20-30 minutes per day, even if it’s only a brisk walk.  An Apple Watch or other fitness tracker can really help with this, since it will give you regular reminders and motivations.
3. Schedule sleep: Get your circadian rhythm on track by going to bed and getting up at the same time each day, including weekends.  Avoid blue light right before bed as well, as it can interfere with your sleep cycle.  Melatonin supplements are a natural way to help you fall asleep fast and get into a new cycle.
4.  Log your brain out: When you finish working on your game for the day, don’t think about it.  Log out.  Your subconscious mind will continue to problem solve for you in the background, and you will be able to return to your work refreshed and more productive.
5. Enjoy life outside of games:  Don’t neglect your friends, family, or hobbies outside of video games.  Get outside.  Explore new interests.  Take your significant other on a date and make your relationships a high priority.

There are many more tips I could discuss around this subject, but I’ll leave it at this for now.

Enjoy time outside games and watch your productivity soar

Build a Showcase ASAP

Before you invest months or years of your life into a project, you need to test the market and see if it’s even worth pursuing, or needs modifications.  The best way to do this is to either build a prototype, or build high quality art assets that showcase what your game is all about.  Don’t hide this gem in a hole in the ground, show it to the world!  See what others think about it.  Ask them to brutally critique it so you can improve it—or can it and move on to something new.  It’s better to cut your losses early rather than waste even more time on a project that’s dead in the water.  The only way to know if you’re on the right path is to get opinions from your target markets as soon as possible.

Conclusion

Building a game by yourself is hard work.  Making that game a commercial success, while working full-time, going to college and raising a family is even harder.  I’ve learned so many lessons from this experience that I could write a whole book about it, but I hope you find these condensed highlights useful. 

Thanks for reading and please help me share this with others in the gamedev community!

Guts and Glory is currently available on Steam Early Access, and version 1.0 will launch on PC (Windows, Mac, Linux) and Consoles (PS4, Xbox One, Nintendo Switch) Summer 2018

Follow HakJak’s game development journey at HakJak.com

The iOS App Store has started to shrink, with the number of apps on Apple’s mobile marketplace falling to 2.1 million in 2017 from 2.2 million in 2016.

As reported by analytics outfit AppFigures, that five percent decline was partly the result of Apple’s stricter enforcement of its review guidelines, as well as some technical changes that eliminated many older apps that didn’t support 64-bit architecture. 

Perhaps more notably, it was also caused by a lack of fresh software, with the number of new apps hitting the App Store falling by 29 percent year-over-year to 755,000 — the first drop since the App Store launched in 2008.

Both the App Store and Google Play store had been experiencing consistent growth until now, and while Apple’s marketplace took a hit, Google’s continued to surge upwards, growing by a rate of 30 percent to more than 3.6 million apps. 

The number of new apps hitting the Google Play store also rose in 2017, with Google Play developers launching 1.5 million new apps throughout the year — an increase of around 17 percent year-over-year.

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

Development in a big team is always an issue in Unity when we are talking about a scene file.

Multiple people working on the same scene may experience problems when the time for merging parallel work arrives.

Some solutions have been developed to account for that, but more often than not, bumps are present during production stage of the game.

The solution found here at Black River Studios was custom built from ground up and from day 0 to fit development of multiple people on the same scene causing as little interference as possible and the results were quite pleasing.

Two rules were defined at the beginning of production:

• Game flow controlled by waypoint;
• No direct references shall exist in a scene;

By having the team following this two rules, the only possible scene conflict would only fall on the scene composition work.

If two or more artists would add and edit what the scene actually looks like, that could cause a conflict.

Luckily that did not happen during the whole production phase of the game, and rarely there was more than one developer working on the scene composition at the same time.

Waypoint System

A waypoint system was created, where the philosophy was that all the game flow of a current waypoint is controlled by it, and every waypoint is self contained.

That means that anyone could set any of the waypoints as the starting waypoint, and the game would work perfectly from that point on.

That meant that each waypoint would guarantee that all the systems it needed to run would exist, all actors were set correctly, and from that point on, the game flow could start flawlessly.

This architecture sped up the development process considerably, since we could focus test each waypoint, and bugs found during the execution of a waypoint would be contained to that execution, making it extremely easy to pinpoint them in matter of minutes.

Playmaker was chosen as the tool that would handle the game flow so game designers would have more control and less dependency of engineers to create their own waypoints, but this system can be adapted to use any type of flow management the team decides to use.

The SceneManager sends an event to the FSM called “Initialize”, and from that point on, the waypoint should do everything it needs to run correctly.

Spawning of enemies, start and end of battles, opening doors, setting traps, triggering big events should all be done by the waypoint, and actors only satisfies the condition of each node in the waypoint flow that triggers the next node to activate.

Ideally, a waypoint could start in any node and work correctly, but that level of encapsulation may hurt the flexibility of the system and is not required.

[embedded content]

Scene References

The second part of this system is the indirect scene references.

Only one GameObject on the scene holds references to anything that is inside the scene that might be needed by any script or FSM.

It is a singleton, and the references are mapped via string path, with a custom editor controlling said references.

References in the scene are divided by categories and references, making it easy to map the variables to any script or FSM.

Additionally, an automated FSM variable addition was created to reduce the overhead work for dealing with references this way instead of directly linking a GameObject to a script variable.

This allows the waypoints to be prefabs, and manipulate the scene just by programming using the empty references instead of the actual objects.

At the start of the game, all scripts and FSMs have access to the SceneManager in order to fill the empty references with actual scene objects, allowing the code in them to affect actors and objects in the scene during run time.

 

Conclusion

By building an indirect reference and encapsulated flow from ground up , the scene conflicts during development were practically nullified and stability and control over what is happening made bug hunting the easiest the studio has seen so far.

This system is flexible enough that most projects can at least adapt a version of it, allowing to reap the benefits of disconnecting direct references from development and controlling game flow.

Newsbrief: Warner Bros. Interactive Entertainment has signed an agreement with IO Interactive to publish Hitman: Definitive Edition.

It’s a notable development given IO’s fairly recent split from owner Square Enix, which published every entry in the franchise from 2012 to 2016. 

The Danish studio and Square went their separate ways in June 2017, with IO agreeing to a management buyout that allowed it retain the rights to the Hitman franchise. 

Right now, Warner Bros. has only agreed to publish Hitman: Definitive Edition — a bundled together re-release of the 2016 episodic series — but it’ll be interesting to see how the partnership evolves moving forward.

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

A few weeks ago, a friend and I were simultaneously playing different games, he Middle-earth: Shadow of War (MESW) and I Animal Crossing: New Leaf (ACNL). Surprisingly, I began noticing similarities in both games’ NPC interactions. The characters seemed to have some agency and were more aware of the player than the typical NPC – basically, they felt more real. I wanted to put my finger on exactly why they felt that way, so I put together a rough list of behaviors. It was immediately clear the behaviors stemmed from systems rather than being predetermined. I had never really thought of systems in a social context. So, my next questions were, “What are the parts of a social interaction system and how is one different from a dialogue tree?” Answering that turned out to be harder than I expected, but I eventually came up with a rough framework in the context of systemic games.

But before we get into that, let’s briefly get on the same page about systems and systemic games. In Aleissia Laidacker’s much-cited GCAP talk, she explains that a systemic game is one that is comprised of several systems, all of which can influence each other. Systems are a collection of parameters and rules that drive behaviors and outcomes in the game world. In systemic games, these are given agency and turned loose to interact with each other however they want within their given framework. Each system bumbles along reacting to stimuli either from the player or from other systems, resulting in things like NPCs pulling out umbrellas when the weather system decides it’s time to rain.

Interactions Separate from the Player

Social interaction systems are one possible piece of a wider systemic world. They too operate autonomously but are restricted to a social context such as conversing or feuding. They can interact with other systems, like a weather system, by choosing dialogue relating to its outputs e.g., “This rain is so refreshing!” They operate without requiring input from the player. In both Animal Crossing and Middle Earth, it’s not uncommon to find two characters having an interaction entirely separate from you, be it a gift exchange or feudal combat. NPCs interact organically outside of you, and you, as a player, have the potential to witness or even join it, like crashing a war chief battle in MESW to ensure your preferred orc captain wins. They have unique interactions with each other but not necessarily full relationships because they don’t tend to have a running memory of each other.

A Sense of Memory

Memory is an important factor in defining a social interaction system. For both games, characters remember exchanges you’ve had. These interactions layer upon themselves to create a relationship unique to that character. In MESW, this manifests through its Nemesis System. In this game, procedurally generated NPCs ambush you, forcing you into an impromptu battle. When you kill one of the enemy captains, they can spawn again with plussed-up parameters and a death wish for you. They hunt you down while delivering lines of taunting dialogue relating to your inability to kill them for good. The system goes so far as to remember the way you killed them by giving them scars and nicknames related to the manner of death. In ACNL, all villagers start with limited, cordial interaction options but over time they open up new options such as asking you to give them a new catchphrase.

Creating the illusion of memory doesn’t have to be complicated to be effective. What I’ve found in the case of ACNL is that the number of times you interact matters, not necessarily the way you interact. Characters speak cordially at first but warm up over time. Additionally, through smart dialogue, the player is led to feel the relationship is deeper than it is. For example, Gala, a normal-type pig character, asked for a favor which I totally forgot. When I later approached her, she really laid on the guilt explaining how sad she was that I forgot. I felt so compelled to repair the relationship that I sent her an apology letter, despite knowing she would not reference this faux pas again in the future. As a player, not knowing the depth of the system, you begin to attribute more thoughtfulness or feeling to the character than you know you probably should.

Emergent Relationships

In a game, emergence is when an activity (event, problem, solution, etc.) is possible because of the game’s ruleset rather than an intentionally designed outcome. In a nonsocial context, this would look something like using objects in your environment to solve a puzzle in a way that is different from the prescribed solution. In a social interaction context, this takes the form of relationships that were not preconceived. In ACNL, for example, the set of characters that reside in your village is random. They approach you at different times and ask various favors. There are loose rules, such as being asked to catch butterflies only in the spring, but which character makes which request at what time is not planned before it occurs.

Similarly, which particular orc becomes your nemesis is not preordained. If you happen to be bested by one of the many procedurally generated orcs, this sets into motion a chain reaction that makes it increasingly harder to defeat that character even as you level up in the game. This power rebalancing leads to the long-term, protracted conflict with a character that has organically become your nemesis. So, in emergent relationships, the entirety of possibility is not predetermined by designers.

Not a Dialogue Tree (Entirely)

In games, dialogue trees typically handle the social interaction component. In their purest form, you walk up to an NPC, they utter a line, and you choose from a menu of possible responses. Don’t be fooled though; these can get very deep, look at Mass Effect: Andromeda as a single example. You can start romantic relationships with a handful of characters. Here too, memory, or an unfolding relationship, is present. The more you interact with a character and successfully choose the correct romantic options the closer you get to them, eventually coupling off. However, you can only become entangled with the characters that have been designated as “datable.” Every flirtatious advance and coy response specific to that pair has already been planned. Moreover, you never see NPCs interacting outside of the script. In other words, while dialogue trees typically have a sense of memory, they do not afford emergent play, nor organic interactions separate from the player. They tend to rely heavily on the advancement of plot points to trigger interactions.

Conversely, the ability to advance the plot (or even have a plot) is a weak point of systems. Because they are just a loose framework of rules, they have a harder time directing the player. This weakness is why you often see systems and dialogue trees working in tandem. Systems are continuous and omnipresent while trees are continual tools that can guide the player to specific experiences, act as tutorials, or advance the plot.

Next Steps

Admittedly, it took me a bit of effort to delineate between a robust dialogue tree and a true system. While both share memory as an attribute, systems can interact with other systems (or themselves) separate from player inputs, have the potential for outcomes that designers cannot predict, and don’t entirely rely on plot advancement to open up dialogue options. A social interaction system exhibits all of these features within a social context.

One thing I want to think more about in the future is, how can we add improvisation to social interaction systems to make them more dynamic as in Matthew Gallant’s recent article on intentionality and improvisation. I think the Nemesis System did a great job with this with its ambush feature. However, what would this look like for games that are not based on combat but still have elements of social strategy?

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

---

*All ideas mentioned are from my memory and shouldn’t be considered official statements.

When I joined Destineer in 2007, the Minneapolis-based company had opened a sister studio in North Carolina.  The Raleigh team I joined was gearing up to work on a CIA game experience while Six Days in Fallujah (SDIF) had been active in Minneapolis for a couple years using in-house technology.

Developing a proprietary engine with a variety of new and veteran developers is never an easy thing.  A year later it was decided the bulk of development for SDIF would be moved to North Carolina merging both teams into one. 

Tactical shooters hadn’t completely embraced modern battles yet, so the time period stood out. Plus, destruction hadn’t been done to the heavy degree SDIF was working on at the time, offering another fresh approach to the tiresome Call of Duty formula. The game market was ready for a title like this.  The general public wasn’t however.

The label of “Survival Horror” was a bit of a misnomer. It didn’t mean the typical survival horror formula, which involves low firepower, surrounded by gore. It was the closest familiar term to convey isolation beyond your immediate Fire Team when surrounded by unknown assailants. A psychological trial as a stranger in a strange land.

While we didn’t lock down the exact consequences of player death, it was going to be realistic. For awhile there was discussion on regenerating health. This wasn’t to make it like Gears of War or arcade style. It was an attempt to focus more on the conflict, strategy, and emotional impact instead of trivializing the connection you build with your character. The flip-side was to replace him with a new marine every time death occurred (which is an issue by itself since we wanted to use real marines).

The original advantage Destineer had was self-publishing the game. Because of technology reasons, some inexperienced members, and “death by demo” schedules, the company slowly lost its chance to self-publish. It’s possible a larger publisher was always considered in regards to world-wide distribution with Destineer responsible for USA only.

Atomic Games wasn’t part of the picture until 2009.  Atomic was a company brand under Destineer to separate AAA games from their budget and training simulator titles.

While courting Konami, other publishers were approached. EA was a strong candidate. Had it been with them, it would’ve been included under one of their existing franchises and called something like “Metal of Honor: Fallujah“. The project fast-tracked with Sony as well. Everyone in the US Sony division was 100% behind the game. Japan HQ felt differently though. They sold Sony products in the middle-east and didn’t want this game to affect that consumer base.

[embedded content]

Konami of course caved to backlash from a handful of loud voices against the idea it was going to disrespect the death of real Marines and make a flashy game out of the conflict. The previous idea about regenerating health fueled the belief SDIF would be a typical Call of Duty game.

That was far from the case. For several years the team was in direct communication with numerous Marines. Each one gave us presentations and recollections of their experiences. They were quick to correct any misinterpretations, as well as promoting what actual military personnel do, react to, and operate.

We recorded personal one-on-one interviews with them. These were to be presented in a bookend fashion before and after each chapter of the game. They would share their fears, strategy, and expectations at the time. Then they’d reflect on the experience, what went wrong, and what they learned. What other game out there puts a personal, real face to the conflict?

After Konami bailed, the studio survived for a few more months. Other publishers were approached, but none of them wanted to embrace the project. It was too hot in the media at the time. Everyone of the 75+ team except a dozen or so were laid off in August 2009. 

The remaining members started work on Breach as an intermediate project while efforts to find SDIF a new publisher continued. Despite rumors the project was complete and waiting for release, it was never completed. The technology, production pipeline, systems, and design were there for the most part. The game maps and scripting weren’t complete however. Several levels were made throughout SDIF’s lifetime in a showcase-demo fashion. Most of those were removed during development because of technology or story changes.

When the team was laid off, we had four out of eight levels in development. One of them was almost complete, but removed because it took place in Resala Cemetery. The media backlash prompted its removal for fear destroying gravestones would be culturally disrespectful. Mosques were also off limits to destruction. In the bigger picture, I thought the restriction was too extreme considering the subject matter.

Also, we weren’t consulting with insurgents. It was a journalist hired to interview residents. Producer James Cowgill has more details on the Insurgent controversy.

The part about consulting with insurgents was highly confusing and somewhat ironic. The reality is this: months after the game was announced publically and the rumor of Atomic consulting with insurgents started, I personally hired (as the documentary producer) a journalist to go to Fallujah and interview / tape people there with experiences centered around the time period of the battle. This included people who had fled the city, mothers who had lost sons and men who claimed to be insurgents.

The goal was to use this footage in the documentary part of the game (along with about 100 hours of Marine interviews from the 8th and 3rd Divisions) and to help us generally understand the people of Fallujah better and create an authentic experience.

The interviews were incredible – even now some of them very much stick out in my mind; a mom crying on her son’s grave, an insurgent looking straight into the camera and saying he tried his best to kill Americans, a father who fled with his children before his house was taken over by insurgents.

It was real and it put a face on Fallujah that helped to give the project credibility as a historical document. We had enough footage (interviews and battlefield footage) to create an entire 2 hour documentary of the battle that put the Military Channel to shame.

I discovered later that people in Fallujah thought the journalist might be a CIA agent and his life was put in danger – so much so that he couldn’t return to Fallujah. One day, I hope this material is turned into a documentary – I strongly feel that the stories we collected from the Marines and people in Fallujah about this event are too important to be lost. This probably great tragedy of the project.

Other games have since approached similar modern topics and survived. SDIF would have risen above the typical shooter and given players more insight to what really happened. It was never intended to push a political agenda. It was about the men on the ground and their personal accounts during that week in November 2004. Six Days in Fallujah was going to be a game that presented history, knowledge, and tragedy during a serious world event. What a novel approach to the watered down and sensationalized gunplay games made these days.