Agile and Stage Gate Development

I've long been a proponent of small teams of individuals working together in a fast-paced development environment, reminiscent of "xp" (or extreme programming), and I came across another great article from Lost Garden, Rockets, Cars and Gardens: Visualizing waterfall, agile and stage gate, which described a succinct and clear development platform and management methodology that I already embrace and didn't have any name for and simply believed to be "agile best practices."

It's called Stage Gate and consists of cross-breeding portfolio models and iterative development. I worked at Lockheed Martin Missiles & Fire Control over in Grand Prairie for about 7 months in an internship, and they believe strongly in following the waterfall method for their projects, although they were at that time also researching agile practices and methods. I subequently worked at L-3 Communications Link Simulation & Training for roughly 10 months in 2 separate terms, first as an intern, then as a Software Engineer I, and their ethic was more of an iterative development approach with constant integration of the coding platform, so it was a bit closer to achieving that agile best practice method for such a large company.

Both of these work experiences enriched my belief in the iterative system, especially since in between the two, I worked at a small company called FoodTronix. FoodTronix is a great company, but during my tenure there, the company was expanding faster than it could handle and hadn't looked into these techniques, falling into that haphazard pattern of developing whichever feature was being demanded most by the customers without a rigorous testing process or any thought into documentation, alongside being severely understaffed. These problems are typically considered huge, but the company was able to handle the fires primarily because they were in a constant dialogue with their customers. FoodTronix is a Restaurant Point of Sale system. I've seen better and worse. What sticks out with this company is their customer service and their adaptation to changing and evolving customer needs - they always handled their customers with care and immediately helped them address their issues and resolve their problems, putting out patch after patch until the biggest fires were extinguished acrossed the board for all of their customers.

To summarize, I learned from these experiences that an iterative development model worked very well for me as in individual and for large companies, along with agile and xp practices such as continuous integration, adaptation early and late into development. I had also seen that I worked better across multiple projects with a selection process of picking which ones to proceed with through a series of comparisons, which I can now call kill gates, in which I examined each project, its pros and cons, its required estimated time left, its original purpose and its final, intended result.

I hadn't heard of portfolio models until I read the post, but it seems like a very logical solution - that of spreading and managing risk via multiple projects in parallel. Now, I don't work on multiple products at a time, but I love the breakdown of how even an individual product can be compartmentalized into several isolated projects with focused teams on a susbet of features or some sort of a divisional area. Of course you have to have overall management, but the Cabal method described by Valve in the Gamasutra article he referenced seems to impart to me a singular philosophy of involving everyone in a project from each of the individual areas in a face-to-face meeting of brainstorming, understanding the individual areas a bit better, and learning how to work with each other better, overall.

I think I'm going to put together a post, eventually, that summarizes my exact philosophy and posit if it can be beneficial to others to follow along and see what intuitive changes they make to the process. As an independent consultant and a typical nine-to-fiver in a small team at a mid-sized company, I find that I don't have to necessarily adopt separate methodologies of work in order to fully harness and focus my energies. In fact, having this one, tight philosophy of adaptation and managing your time across multiple projects with constant customer interaction allows me to state that the focal point is in organization, management and preparation of the overall product in conjunction with the rest of your team and your vested customers, whether you're a project manager, a software developer, a customer, or an external party relying on a completed component for your own development or use and aren't originally invested in the product.

Yes, you have to get the work done, and you have to test, and you have to ensure that everything is consistent, visually, functionally, etc. - but the focus isn't on making sure you're meeting some deadline and writing x amount of source lines of code, or writing tons of documentation or trying to "design" and "architect" the perfect end-all solution, but rather that you're achieving the customers' current and immediate needs with a look ahead (but not a project) to the future, and that you, your team, and the customer all understand that as customer needs evolve, the product evolves, the project schedules evolve (be it a delay or a cut in time), the team evolves, and the business relationship evolves.

Either way, some of the great resources I've come across that I prefer to read and take a look at whenever I have some spare time include:
Free To Play,
Lost Garden,
Agile Game Development,
Extreme Programming,
Gamasutra.

Also, if you're ever bored, check out 8-Bit Theatre, CAD the Series, and Pandora.

An old post to a great article by LostGarden

I was perusing once again one of my favorite blogs out there, http://www.lostgarden.com, and since he's recently re-tagged his entire blog and updated his directory listing, I was reviewing an old article Danc had written, called The Chemistry of Game Design (which was also featured on Gamasutra).

I like to read the comments the users post in response to his article, as Danc also tends to reply to these remarks, and I'd made a post with respect to his article that I had forgotten about and that I think is still worth noting. The link to the Wikipedia article about game design no longer features the Psychological Profiling section, but some googling about on your own should give you a nice insight on what you're looking for with regards to that.

Here's Danc's article:
http://lostgarden.com/2007/07/chemistry-of-game-design.html

Here's my post:

Great article Danc. A few things I noted, since I just got a chance to reading your article in its entirety:

Psychological Profiling / Player Model:

The player described in the player model is limited, in that it describes a specific subset of the set of players: those that are "driven," usually to learn or dominate (and to dominate, they must learn first). Due to the fact that a psychological model is called for, the player model described contains the following player subsets: Timmy Power gamers, Timmy Diversity, Johnny Combo, Johnny Offbeat, Johnny Uber, and all the Spikes, who, evidently, this player model is perfect for. [See Game Design in Wikipedia, specifically Psychological Profiling: http://en.wikipedia.org/wiki/Game_design]

So what about the Timmy Social, Timmy Adrenaline, and Johnny Deck profiles? One could argue that they aren't the mainstream of gamers, because they aren't "hardcore" gamers - however, Timmy Adrenaline would disagree vehemently, as witnessed by DOOM3's and F.E.A.R.'s success, and The Sims is proof that Timmy Social is a very large demographic that can't simply be ignored. Johnny Deck's profile, in my honest opinion, represents those players that build or generate some sort of expression of themselves or their experiences in the game, such as a guild or clan, a house or empire, etc. And they're usually rooted into the other player profiles on some level as well.

The reason I mention this is to ask if maybe there isn't a player model that abstracts out a bit further to include a more involved psychological model. The purpose of your original abstraction was to focus on the core that is the player - but if the player is too loosely or too strictly defined, then it degenerates a critical component of the chemistry of game design. In this situation, the player is too strictly defined.

On that same note, I believe the Wiki should be updated to include your article on game design and your blog in general, as there is a wealth of game design information available here.

Pre-Existing Skills:

Shouldn't the general assumption be, of every game, only that a player cues in to the screen for some sort of visual feedback, and that they know that pressing buttons or moving analog sticks is supposed to do SOMETHING, as opposed to nothing? With this same thought process comes the need for every game to have at least a very simple tutorial, if not more involved for more complex games, which defines and describes the game controller and its general actions, and the capability to learn advanced skills by utilization of mastered basic skills, thus teaching even a non-gamer that mastery and utilization of certain skills leads to game advancement and skill advancement.

Most games today do provide a tutorial, but not all of them, and often times the "New Features" or "Tutorials" sections are nested into sub-menus that aren't necessarily clear in the first place (Example: Madden '08 by EA Sports). And in some cases, the tutorials are demonstration-based (see earlier: Madden '08, which provides nice video and audio tutorials showing exactly what to do) but don't allow the player to interact there directly to try a skill-set out and see if they can't get the basis for it down outside of actual gameplay instead of possibly trying it out during gameplay, messing up, and costing yourself time to re-load from a game death, etc. As such, these games are less effective in delivering the message to non-gamers or gamers who like directly to "jump into the action" and there's no built-in game-based tutorial. Obviously, advanced gamers may want to skip a built-in tutorial, and so they should be given that capability, just as newer gamers may want to listen/interact with the built-in tutorial and given that capability. (This goes with what you state in the Pre-Mastery of Skill Taught In The Game section regarding feelings of boredom and frustration for advanced players.)

Skill Atoms & Skill Chains: (Objectives, Future Topics)

Proposal: an artificial intelligence analysis framework, in comparison with the MDA game analysis framework for game analysis that you mentioned, that utilizes Skill Atoms and Skill Chains as they are progressed throughout the Player's Gameplay Life Cycle (as I like to call the fundamental game play, skill mastery and burnout flow described by your Chemistry of Game Design). If some sort of CGD architecture is built into the game itself and actively monitors a players partial mastery, full mastery and burnout of Skill Atoms, then it can eventually generate data by which an adaptable artificial intelligence can play against the player, allowing for variable levels of interaction and difficulty for the player, constantly providing a challenging stimulus without leading to frustration or boredom. Such information would be tremendously useful in any number of applications within the gameworld itself, and as a preferences experience for future game titles (and has numerable applications in the marketing world as well). In addition, this analysis could clue players into how using certain previously burned-out atoms may advance their skill-set later on during the game, by knowledge of their usage history with the skill atom in question and the necessity of learning the skill atom further down the chain for completion of their current objectives.

Just some food for thought. I do apologize that it took me as long as it did to read such an excellent article, and I'd love to hear your reply.

-Ahad

It's an interesting read, and my post reminds me of some of the more interesting notions I had regarding AI.

Take care,
Ahad L. Amdani

Echo Consulting, Small Business Consultations, Software Automation and Development, and Business Efficiency... in a big way!

Welcome!

This site is about everything the title of this post entails, along with some articles and links here and there about game design and development. I might throw a little light in on things such as software algorithms, the struggles of a young, independent game developer (myself! -- that is, if you can count a 22-year old full-time employee with his own small business who plays video games most of his spare time and wants to make a game of his own one day an indie), the small business advice I receive or give, the books I've read to come to the conclusions I've come to in the present time, and a bunch of other content that probably has no bearing whatsoever on anything important except that I find it interesting or special in some way.

I have extensive ramblings and rants on a wide variety of topics, I just seem to lack the proper time frame to focus all of the daily knowledge I come across into a textual format, properly edited, and publish it on the internet in the form of a blog.

In any case, I welcome you and hope you get something positive out of this, or even if it's just a waste of time and a way to kill that ever-present and sinister calamity: monotony.

Good luck, good hunting, and good gaming!

Thanks,
Ahad L. Amdani