Before going through this, you can download my end result in excel, as well as take a look at the actual document containing the requirements.

The Goal –

You’re given 26 employees and 1 contractor to create 24 in-game characters (12 major, 12 minor) and 24 in-game cutscenes for those characters (2 min per major character, 1 min per minor character). The assignment comes with a few conditions regarding your employees, usually personal life issues that result in delayed production. Given the start date of Monday, January 2013 and a burn rate of $10,000 per man month, the goal is to schedule all of these assets with target length of three months and a budget of $750,000.

Employee Count:

• 1 Writer/director contractor who bills at $500 days
• 3 Sound designers
• 5 Concept artists
• 4 High-poly modelers
• 4 Low-poly modelers
• 1 VFX artist
• 9 Animators

Each of the tasks have inter-related dependencies, and specified durations, that may cause conflicts as you progressively get further into the schedule. Detailed descriptions of these tasks can be found in the original document above, and the assumptions I took while going through this are described further in this document.

Quick Results

I was able to effectively take into account all issues while getting the schedule completed by April 3, 2013 (four days before the deadline) with more than $250,000 remaining in the budget. However this kind of schedule is fairly unrealistic due to its strict waterfall methodology, so be warned that this is simply stepping through the work tasks as quickly as possible and avoiding any kind of agile methods.

To see how I managed this, the process I took, and some more in depth analysis on my result, click below to read more.

Tasks and Dependencies

Above is a quick look at each of the tasks designated by the original document, and my assumptions on how they fit together. Some of these dependencies are clearly laid out, such as character sound design requiring both the animations and FX Art to be created before beginning. Other dependencies were not so clear. For instance, the document labels out that all major and minor characters use the same rig respectively, but what isn’t clarified is that because they all use the same rig, animation on all characters can begin as soon as the first rig for each is built. Similarly, it isn’t clearly defined if just the rig is needed to begin in-game cutscene animations or not. Because I wasn’t sure on some of this, I double checked my thoughts on these by checking with both some artist friends I knew and a former producer with nearly a decade of experience. They were able to confirm and correct some of my dependencies into what is shown above.

(It’s worth noting that cells 145-148 are specific to the cutscenes as script writing and VO recording, and are completed at the beginning of the schedule well before the concept artists begin storyboarding.)

Methods and How I Learned to Solve the Schedule

Concept Art –
Initially looking at the schedule I started as a normal person might, by taking concept artists and linearly scheduling them out starting with all the concept art for major characters. Half-way through this process I realized I needed to diverge resources at some point to begin cutscenes early enough for animators to have them available when possible. Once I completed this set and started working on the high-rez modelers, I realized I made a big mistake. By linearly scheduling out the concept art, I failed to realize that instead of waiting 8 days to begin, I could get high-rez modelers to begin within 4 days, as well as all other resources, by having some concept artists begin on the minor characters immediately. What I decided to do was allow 3 concept artists to begin work on major characters, while 2 started on the minor characters right at the beginning. This allowed me to have 6 characters ready to go by Jan 16th for my 4 high-rez modelers to start up, immediately creating a safety net between the two later on when concept artists would need to start working on storyboards.

I also want to take note of Concept Artist 5′s positioning in the schedule. Apparently this artist had an accident and broke a leg playing soccer, somehow causing his art to take twice as long as anyone else. Because of this, I knew I needed to get him on the shortest tasks during this time that had the largest differential between it and its dependency. This ended up being the minor character cutscene storyboards. For him, each of those would take 2 days of work, while the subsequent task takes five days. This means that despite his liability, he has a healthy margin of difference to complete 2.5 storyboards before a single animation set is done to start on the next one. Alternatively you could consider it means that he’s able to keep pace with two animators behind him, and even continue staying ahead. This allowed me to maximize returns on what would ultimately be considered a delay. After that first month of injury, he is able to pick up pace again, and by that point in time, is moved back to help finish character concepts.

In the end, concept art for all characters and storyboards are done by Mar 1.

Hi-Rez and Low-Rez Modelers-
These guys (and gals!) tended to be pretty easy to schedule. As I outlined above, because of the split work load for concept artists, I was able to have 4 concept artists working at all times on characters, and had 6 available pieces of work ready by Jan 16 for hi-rez modelers (one of these tasks would already be completed by then, so really down to 5). Because the hi-rez model takes exactly as long as the concept art, they maintain pace between tasks and always have an extra piece available in case concept art ends up slipping in the schedule slightly. It is worth mentioning that it was important for one of each major/minor characters get completed as soon as possible because of animators needing those models to begin the rigging process, and start animations across all characters.

Low-rez modelers ended up being a slightly more sordid affair. Because their tasks are around 60% of the total length of the hi-rez models, yet they have the same amount of resources available to them, it meant that low-rez modelers tended to have short breaks between their pieces. This could be remedied in a multitude of situations, all of which would require an increase in budget, for something that has low-impact. The reason that I advise against spending additional money by contracting in an extra hi-rez modeler (which would cause hi-rez modelers to get left with blank periods and would require an additional concept artist to alleviate that), is that low-rez modelers have no dependent tasks waiting on them, thus avoiding the critical path for development. It’s also worth noting that the low-rez meshes can easily be completed before April 7th even if no low-rez modelers were available until the last days in January. This means that low-rez artists could be used elsewhere on the project during this time frame and only brought on when they was sufficient backlog to maintain a consistent workflow for them.

Animators-
This was easily one of the most frustrating parts, and complicated pieces to do for this schedule. Every single deliverable in this schedule requires work from animators, while also having people waiting for that work to be completed. Because of this, every task that needs animating needs to get done as quickly and efficiently as possible. Luckily, because all characters are based on two rigs, as soon as a single character is complete, animators can begin working on the entirety of animation sets for that type. This allows all animators to begin work immediately, and generally able to keep on task through the project without significant periods between work. In the end, what I ended up doing is breaking them into basic strike teams of 2-3 animators.

• Animators 1-2: Start immediately and alternate between major and minor characters until they are complete, then fill in at the end for cutscenes.
• Animators 3-5: Focused on minor cutscene animations. #4 was almost entirely on VO sync to keep pace with #3 and #5
• Animators 6-8: After starting in major character animations, they move into major cutscenes
• Animator 9: The misfit of the group, as his tasks take twice as long compared to anyone else. He’s slotted into non-essentials to complete by deadlines.

Long story short, these guys tended to be very sporadic in their scheduling, as they have a wide range of tasks getting completed on various days, requiring them to be flexible across the overall project.

VFX Artist and Sound Designers
These two resources are where the largest bottleneck in the project occurs. The VFX artist has tasks that take only a day or two to complete across the board, and only require animation to have started before beginning his/her own tasks. This means that the VFX Artists can easily move through his/her work at a consistent pace without openings. Unfortunately, because the project has 3 sound designers, they tend to catch up very quickly to the VFX Artist because the task times are nearly identical, preventing a backlog of work being created and resulting in an uneven work flow. This fact is compounded because the sound designers require the VFX Artist and the animator to be completed with their work before the sound designer can start. Because of this uneven balance, if you take a look at the overall schedule, it’s very easy to see that the third sound designer is entirely unnecessary without sacrificing the overall project timeline. Sound Designer 2 is able to keep pace on all character work while Sound Designer 1 takes care of all audio tasks on the cutscene side. Even with only two sound designers, there still ends up being breaks between work nearing the end of the project as they wait on final VO syncs within cutscenes to occur before they can mix the final sound balance. To alleviate these issues, it would be ideal to hire on a contract VFX artist for a week to push the character schedule ahead, allowing a backlog of work for the sound designers to come in and alleviate.

Conclusions

So what did I end up with? As I said above, all work should be completed by April 3, with only two tasks slipping into those April dates, both of them on the major cutscene 12.

In addition, the overall budget ended up at $491,000. This was calculated based on a burnrate of $10,000 per man month with an equation taking in the total duration of time spent working and dividing it by 20. Why did I choose to do 20? If you look into the definition of man-month, you’ll find something along the lines of taking the exact amount of work being done, which should be I divide total days worked by 30. Instead I opted to drop it down to 20 to overestimate budget in case of salary payments during days where work is not being done.

If you made it this far, thanks for reading through!

Slither is a 2.5D platformer made in Unity over 48 hours for Global Game Jam 2012.  Players take control of a larva, progressing through its stages of life attempting to collect the pheromones that will allow it to move through the door at the end.

Controls:
A/D – Movement
W – Place new Egg
Space – Activate ability (Chomp/Climb/Fly)
Shift – Speed up time

Click on through to play the game

Please view the full post to see the Unity content.

Things a bit tiny/squished for your taste? Download the full rez version:
PC Download Mac Download
 

The reason I’m bringing this all up is because my adviser and main teacher during this final year of school is no longer there. I spent a good portion of Friday last week talking to him, and now I find out this morning he’s gone, just a few days later. This is the second time it’s happened to me when I got close to a teacher, and it’s extremely frustrating.

Clearly this kind of thing happens in the industry all the time; people come and go in positions all the time, and there’s nothing that can be done about it. The difference here I guess is that these people are highly influential in my ability to get jobs coming out of this school. Not having them there to recommend my work and everything is pretty debilitating. This also means that everything that he was overseeing in terms of my education, including things that he was tailoring for me, are now out the window. I hate for this to sound like a bitch-fest, but I just need to let out my…disappointment(?) with things. I’m not really sure if that’s the word I want to use here.

In other news, in addition to somehow maintaining my 4.0 all the way into my final semester, I also am now Student Government president. That kid of role comes with a completely different set of issues that I have to deal with. It also means I’m basically managing two different teams of people, my game studio group and now the representatives. This whole situation is giving me an opportunity to expand my ability set by forcing me to step back and rely on lieutenants to get 90% of the things I need done. So that’s the good in all of this. I’m just going to be extremely busy managing people over the next few months, and hopefully will have the time to get all my applications sent out.

Down below is a web version of our game Primordia. HUD elements are all adjusted, and it definitely looks better at a higher resolution. But we did want to show that we can get it up online.

Controls:
W/A/S/D – Movement
Q/E – Rotate Camera
Mouse – Aim
Left Click – Primary Fire
Right Click – Secondary Fire
Tab – Open Mod Console
Space – Use Health Kit

Click through to give it a shot. Current high score on Annihilation is around 250k

If things are a bit scrunched for your taste, check below the player for the full screen download links.

Please view the full post to see the Unity content.

Download Links:
PC Download Mac Download

Preface:

The issues I bring up in this document are heavily slanted towards the production aspect of Game Studio 2 (GS2) and may or may not reflect the feelings of other members of my team. Because of this, several of my points are focused on direct actions I took that I feel resulted in either positive or negative results.

Things that worked:

1. Cross-Discipline Communication

When we sat down at the beginning of the semester I knew that the only way to get things done in an efficient manner was to get people talking to each other. I’ve had issues on previous teams where groups would segment themselves from the rest of the team to the point where people didn’t even know some of their team members’ names. If communication doesn’t flow well on teams, things tend to get delayed. This semester I set out with the intention of limiting segmentation in the group by setting meeting schedules that would solely rely on cross-discipline communication. This would mean we would rarely have only art sitting down, but instead art and design, or design and programming coming together. Preventing group segmentation was not the only reason for wanting to do this. An added benefit was keeping each group up to date with what was feasible or not by having a check in place with another discipline to vet ideas against. How often have games been overblown by designer scope? This check allows people to really understand the issues other team members are facing, streamlining the whole process eventually.

Initially there were two methods I wanted to try when going about this goal. The first was to create strike teams assembled of various disciplines. This meant we would try to get an artist, designer, and programmer together to meet regularly and focus on specific aspects of the game to build or improve upon. This didn’t work out primarily because of weird scheduling issues with individual schedules not being able to line up correctly.

The second solution was only having meeting blocks that involved at least two disciplines. This worked a bit better, as we found once a week where designers had a four-hour opening with programmers, and artists were able to sit with designers. In the case of design and programming, the designers were able to immediately get responses to questions they had, and were able to quickly trouble shoot any problems that occurred.

2. Production Process

Somewhere around a month and a half into the semester I sat down with Bob McCabe to catch up. Eventually we got on the topic of GS2 and our team’s current progress. He told me that from his view, it seemed we were the only group that was following a traditional development process when approaching a game development. What he meant was we were utilizing the standard development structure of paper design, grey boxing, initial art pass, final art pass, and finally a lighting pass. This structure was likely what kept our progress moving forward throughout the semester.

By utilizing this structure, it meant our designers were never sitting around waiting for both art and programming to get tasks done, as well as front load our major art assets to the beginning of production. Our designers were free to work in a basic grid structure to map out levels on paper, and overall create our entire level well before they were even given the toolset to build it. Once we had the basic movement within the game, they were then able to take those levels and push them into the engine and move around, getting a feel for the space and making adjustments as needed. In addition, by having them work with grey box, we weren’t forcing art to get environment assets done early, which would push back progress on our larger, higher priority character and enemy art. When art was ready to start putting in environment art, all they had to do was swap out the current building blocks our designers used in their levels with the new objects. This meant we weren’t wasting a month of progress and allowed each department to keep their eyes focused ahead, rather than fixing issues from before. Not everything went perfectly, but it was our first time going through this process, and generally it kept us on track and seeing obstacles before we got to them.

3. Badass Dev Team

There’s no denying it, we had the best programming team in the school. If we didn’t have the people we had, this game would not have been what it was. Because I have nothing but praise to give to these guys, I’m going to openly say their names. Michael and Ben were both unbelievable in what they did over the semester, yet both held very unique positions. Ben had the raw organization skills to keep the programmers on task and looking ahead solving problems, and Michael was just a beast. After our final presentation I sat down with Ben to talk about everything and we both agreed on this: there was literally nothing we could give Michael that he could not handle.  I know on my end that I thought long and hard on what to give Michael that would give him a challenge and keep him interested, but the more I talked to other people, the more I realized he was perfectly happy just knocking features out. It eventually got to the point where I started to question in my head whether Michael was actually spending the amount of time he estimated on things because he was so good. That’s not even saying I was mad with his estimates, I think the longest time period he told me for a single project was three days. I have no problems with three days.

I don’t want to sing praise to just those two, because Adam was also an incredibly valuable asset. After about a month and a half of him working on gameplay programming, Ben decided to move him onto UI. Initially he was hesitant, but I worked with him and started brainstorming with him on cool things to do with UI, and eventually started to get into it. He ended up taking on a piece of the project that he was unsure of and made it entirely his own. In my opinion, we ended up with the best UI of any of the GS2 projects, and I solely place that result on Adam’s drive to make it the best possible. Since then he’s told me he is considering specializing in UI programming for several reasons, one of them being his enjoyment of it.

4. Picking Up the Slack

There was a core philosophy I had while taking my picks for GS2; I only wanted people who liked working with people, and didn’t like it when someone dropped the ball. When we finally had our first team meeting, I sat the team down and told them a few of my personal opinions on how I feel about teams I work with. First, I don’t tolerate people complaining about something they aren’t ready to fix themselves. Second, I don’t dictate work schedules, only deadlines, and I would work with them to set those. Each of them are adults that can figure out their own work/life balance, and as long as they keep hitting deadlines, I couldn’t care less on how they scheduled out their time.  Finally, if each of them put forth their best individual work, they need to trust the person next to them to do the same.

When it came down to roughly the last month of production, we finally had the exact dates we would be ending the project on.  At that point in time we were able to look at what we had, and where we needed to be before break started, and had a very clear picture of what was still needed to get to beta. Once again, the producers laid it directly out to the team and said, “We know you don’t want to work over break, and we don’t want to make you. From the beginning we’ve planned for December 16^th, and we need to stick to that to make this happen. Whether you guys have to work over break is entirely dependent on your ability to get the remaining things done by then.” They pushed and got about 90-95% of what they needed done.  But I knew this team by then, and that part isn’t what surprised me.

The last week before break, I started having people come up to me and basically say, “I don’t like this,” or, “I want this to get in the game,” and each one of them told me, “Can I work over break to make this happen?” Why they thought I would deny them that opportunity escapes me. More than half the team ended up taking up optional projects over break to get wish list features in and improve parts of our game we thought were lacking. Because of this attitude we were able to squeeze both Annihilation and achievements into the game.

5. Annihilation’s Popularity

There is a level of irony to the fact we spent four months building a story based vertical slice and then having a game mode we spent maybe three to four days on total become the more talked about feature. Obviously a major reason we were able to do it so quickly was because we had the sandbox already created, and all we had to do was some custom scripting for the game mode.

Looking back on it, the most likely reason is the same reasoning social and mobile games have so much popularity; it is easy to talk about. When you have a game mode that is purely score based it is easy to compare yourself with other people playing the game, and thus talk about it. In addition, we were able to create a strong enough ability sandbox that players tend to discuss strategies on how best to beat high scores.

The success of this mode is something we’ve taken to heart in concepting our next project, as it paints a clear picture of the value of good gameplay over story for us.

Things that didn’t work:

1. Lack of Art Export Experts

Honestly, we didn’t have a clue what we were doing with our export/import settings between Maya and Unity. We knew Unity was pretty straightforward in handling anything being imported, but we knew very little about setting scale initially and how that affects the whole game later on. What we did know was learned during our small UDK tutorial sessions the year before and involved setting snap settings primarily, which didn’t really teach us the lessons we needed to learn.  By setting these things early on we eliminate future re-works, and potentially provide a far more realistic product.

But, because of our lack of foresight, all our models ended up being 90 degrees off when we started to work in look-at functions with them, and required an unnecessary amount of back and forth to get them to the correct rotation. During the process we all recognized that this could have been easily fixed if we had more opportunities to sit the art guys down with the dev team.

2. Too Few Meeting Opportunities

This is mentioned a little bit earlier in this document, but we really had trouble getting enough of our guys together at the same periods of time. It ended up being completely impossible to get our full team together unless it was outside of the normal workday. Unfortunately, most of our guys traveled an hour or more to get into school per day. This caused us to be hesitant when scheduling meetings outside of the day period because it would mean people were doing 12-hour days. This meant that we didn’t hold a single full team meeting outside of class until 2 weeks before winter break occurred, or roughly 3 months into development.

Not having at least a single two hour full team meeting per week ended up costing us precious development time, and possibly could have led to increased bug fixing, and greater team collaboration.

3. No Idea Leader

The morning of our first GS2 meeting we were supposed to have a game concept pitch. That was impossible, and we knew that. There seemed to be urgency on the faculty’s end for teams to have a fully fleshed out concept extremely early in the process of development. This immediacy meant we had no time for a team who barely knew each other to break the ice and sit down to discuss ideas. We took the first meeting of the year and spent nearly six hours straight brainstorming with the full intent to have an idea ready by the next meeting. Basically, we got to the point where we didn’t have a strong idea that was really standing out, but one that everyone was just ok with. There was no spark involved with the idea, and I think we all felt it was derivative and uninspiring.

By not having that one great idea that everyone just keeps talking about, we lost out on having our team be fully passionate about the project and really take ownership on it. Even after we wrapped, I discussed this feeling with several of the team, and they felt the same. Everybody on the team only seemed to be about 50% for the idea. No one hated it, but no one loved it, and that kind of hurt our creativity on the project. If I learned one thing out of this process, it would be to never rush the brainstorm period. You might end up hating everybody on your team at points during that period, but eventually you all come together and get behind an idea that everyone thinks is pretty awesome.

4. Where Was Mother?

Luckily, due to the intrinsic nature of our team, our lack of discipline didn’t affect us nearly as much as it should have.  I feel terrible admitting this, but we never wrote up a single person on our team. We gave out a few warnings, but never enforced any policies we put in place. Personally, I view that as a complete failure on our part, because there were issues that should have been handled with written documentation. By not sticking to our values and giving repercussions for failure on our team’s behalf, we often fell slightly behind on features, which cost us when it came to trying to present those features.

The biggest example I can provide is with several of our art assets. They were coming in far later than they should have, and even the time estimates I was being given were being missed by a significant amount. Part of this was the lack of oversight by the producers, and eventually was fixed by instituting stand-ups three times a week for over a month of production.

In addition, our audio team was missing key milestones for their assets that were costing us revision time. They were busier than normal audio students based on their doubled schedule, but we should not have allowed things to get pushed back as far as we did. By not getting those sounds in on time, we lost opportunity to iterate and provide feedback in time.

Overall the issue comes down to two words: accountability and responsibility. No one up top was really holding the producers accountable for the overall project, which is what would normally be seen. In addition, the producers then take that accountability and make others responsible for completing assets and features on time. We had none of that structure, and never held people responsible for hitting their deadlines. Even simple warnings to people early on would have provided a greater sense of urgency across the whole team.

5. Decision Making

This was by far the most indecisive team I have ever worked on, and I take responsibility for a lot of that. Far too often we allowed conversations to go on about features that really needed to be set. This issue can be cited to so many problems on the production side; the two most notable ones were time sheet dates and task tracking. Let me go through each of those issues and their effects, then, I’ll back up and explain why this issue was happening.

In regards to time sheets, it took us roughly four weeks to nail a specific due date for them down. We kept becoming split between doing it on Friday, Monday, or something ridiculous like Wednesday. Usually you don’t think this would matter, but it really screws with things when your deadlines are Fridays, and time sheets are due on Monday. Does that mean people then need to get all their work done before the weekend? What about due dates on Fridays? Well then you aren’t giving people the breathing room to see if they need to push themselves over the weekend to meet the necessary hours per week. Eventually we ended up just leaving it at Monday and dealing with the deadline thing as it came. On our next project we’ve identified that the bigger issue is deadlines being on Fridays, for multiple reasons, and have moved them to Mondays. This means our deadlines will now coincide with time sheets. Taking four weeks to iterate on this idea was confusing for everyone and it didn’t start things off well. As you’ll see, we had just as many problems determining a task tracking system.

We utilized a total of six different programs over the course of the semester to track progress on the game. How can any individual keep track of that many locations? Don’t let that number fool you though, we didn’t use that many all at the same time, but instead cycled through them trying to find the thing that worked the best. Initially we were on Assembla doing all our subversion merges and tracking progress through that with Excel and Google Documents maintaining a larger picture. This was only meant to be temporary as we though the school’s solution in Basecamp would be the answer. When we got a look behind the hood of that, we backed away almost instantly. Eventually we moved to a program I pitched to Brian before the semester started, called Pivotal Tracker. After around six weeks of messing around with these different systems, we finally settled on a location that we failed to fully enforce activity on.

There are a couple things going on that screwed up our decision making process. If I can be modest, I’m a pretty gung-ho person at the beginning of a project. I like to get things moving smoothly as fast as possible. Unfortunately, doing that doesn’t take into the account other people’s feelings so much. Knowing this, I tried to involve more people on the decision making process, especially in regards to over all procedures. Quickly, or possibly slowly if we’re sticking with this issue, I realized people didn’t care, and they will end up using whatever solution you give them provided it works and over time can be improved. In general, it took far too long to set up the chain of command and allow a singular person to just make the big decisions. I still deferred design decisions mostly to the team, but when it came to how to manage the team, I became the sole provider of answers for that. Whether that’s the best thing in the long run or not, I don’t know, but it eventually worked, and it took far too long to get to that point.

Primordia is a top down sci-fi shooter built in Unity by a group of 15 Tribeca Flashpoint Academy students. Player’s control Viktor Schell, one of few survivors left after humanity was ravaged by a deadly virus. After being told a possible solution exists by an AI named ORSON, the player travels to a previous time to find a dormant sample of the virus.

Over the course of 4 months, we built up a vertical slice of our game, showing what would be around 1/4th of the final project. In addition to the story mode, we were able to build in a survival mode titled Annihilation. In the game, players have access to 6 mods that can be equipped into primary or secondary slots, with different behavior depending upon which slot it is equipped to. This allows the player to have a total of 30 different combinations of abilities.

Contributions:

• Led team of 15 students to hit major deadlines and successfully hit above our initial scope
• Created schedule and milestone delivery list
• Designed in-game UI and HUD
• Built PFX throughout the game

If you missed the download link on the previous page and want to try it out, click below.
Play Now! PC Download Mac Download

]]> http://www.maxwellzierath.com/portfolio_primordia/feed/ 0 http://www.maxwellzierath.com/portfolio_sound-city/ http://www.maxwellzierath.com/portfolio_sound-city/#comments Sat, 21 Jan 2012 04:06:07 +0000 Maxwell http://testing.maxwellzierath.com/?p=118 Play on Facebook!]]>  

Sound City is a music-centric simulation and social game which offers players an immersive experience into virtual club scenes and music subcultures. With music library containing over 70,000 songs, players will be able to create playlists of music that they discover within Sound City and share the playlist with their friends. Fuel your creativity through customization of your club, music, and even your avatar, and express yourself however you wish. You are the club owner, and you have tens of thousands of songs at your fingertips.

Contributions:

• Wrote design documentation for various game elements
• Drafted initial marketing and social media plan
• Developed and implemented social media presence
• Provided QA support and bug submission

Sound City launched in Fall of 2011 and you can play it now on Facebook by clicking the link below:
Play on Facebook!

My Role:

• Led concept and brainstorming session
• Designed and made HUD artwork
• Created all environment block textures
• Built all of the PFX and made the necessary art for them

If you’d like to play the game, click the box below
Play Now!

Project Grudge is a side scrolling shoot-em up built in XNA by a group of 9 students from the Tribeca Flashpoint Academy. The game’s unique gameplay and audio/visual mix are meant to represent the player viewing the world around them through alien technology. The core of the game is signified by what we call, ‘color sonar,’ where the player uses sonars to view specific gameplay objectives in the world, each associated with a color and type of sound.

I took the role of lead producer on the project over the course of 4 months managing a core of the scheduling.

Contributions
- Managed a team of 9 people through all phases of production
- Led quality assurance team in logging and fixing bugs
- Authored core documentation and project schedules
- Contributed to all areas of development (programming, art, and design)

Didn’t see the link to download on the other page?
PC Download

During EA’s latest conference call to investors it talked briefly about the kind of money it was making in the social game sphere. EA said the average money spent per paying user over the user’s entire lifetime (specifically in the Superstar lineup) was $56. That’s surprisingly a considerable amount of money, considering social games usually see player numbers in the tens of millions. Of course, EA’s definition of lifetime spending is currently unclear, so that value may be subject to change. Unfortunately, that figure doesn’t show how many users are actually paying, which would reveal the kind of money EA is really making on these games. Luckily, we can start to derive that amount using various information sources available.

A new study by Visa’s PlaySpan and VG Market Study came out showing that roughly one third of all players spend money on virtual games. That gives a rough number on how many players are willing to pay.

We can pull some revenue numbers out on these games. If we look specifically at the Superstar lineup of games (as that is what our $56 figure applies to), data collection website AppData shows roughly 3.8 million users for those games (Madden Superstars, Fifa Superstars, and World Series Superstars). If one third of those users are paying customers, it means 1.26 million users that are buying virtual goods.

Finally – by putting these numbers together we can see that EA is making roughly $70.56 million from the Superstars lineup. A good chunk of change to be sure, considering all three of those products probably cost less money and time to develop combined than a single AAA title.

How does that stack up against EA’s overall revenue though? Well, EA reported their yearly revenue at approximately $1 billion right now. That means the money coming from their social games only accounts for 7% of revenue. However, that figure represents lifetime revenues, not yearly, so 7% is still inflated.

Anyone still want to contradict Activision Publishing’s CEO and his statement regarding consoles maintaining their position as the driving factor behind the industry? I thought not.