Development Process (Again) Part 1

     In my most recent project I am faced with a serious problem: Standard development process went out the window. Really, this would be a completely bad thing. Luckily for me and the team I am working with, we all hold a trait which is probably one of the more important aspects to being a good developer and that is the ability to adapt. Adaptability is really underrated and taken for granted. Adaptability, flexibility and compromise are really being put to the test for my entire team at this point in time. How do we ease the path through this obstacle?

“Standard” Development Process

     In order to better understand my situation, I’ll start off by explaining the basic development process for comparison. In an earlier post I did explain a simple process but, here’s a better overall look. Also, keep in mind that this process can be used for nearly any type of project in life! With large projects such as developing a full-featured MMORPG, extra attention to the first few steps is crucial.

1. Plan
2. Analyze
3. Plan
4. Design
5. Impliment
6. Acceptance Testing
7. Maintenance

     First we see plan and that should be pretty obvious. Before doing anything, plan it all out. It doesn’t have to be perfect to start, this is just the beginning. For a game, this needs to start of by planning the basic properties such as genre, platforms, languages, gameplay, core mechanics, combat, stats etc. Once the core concepts and system theories are out of the way, dig a bit deeper. Start planning the details. For example, an MMORPG usually has tons of items. How are these items used? Are they equipped, and if so, where and how? Such systems like combat really begin to take shape when you plan ahead on the item properties such as type of items, possible stats, etc. Now, this isn’t to say think of a game and start creating items, this is just an example. This first leap is extremely huge and equally discouraging for brand new games. If you’re making a sequel, remake or some other form of expanding something that’s current, this first leap is just a simple double-step: build up on what is current, expand/extend everything. Especially for things like sequels, this is where you put in those crazy ideas that couldn’t make it into the first. Another part of the first planning period is a few visuals such as concept art. However, this should not be a priority here.

     Next in line is analyzing. When you plan for something, technically you have just built a ton of theories. Analyzing these theories allows for a sort of “pre-test” on many levels. This step also gives very large projects a chance to gain a general priority list for various features. Graphs and scales are important here and preliminary flowcharts should be created. Some common questions when analyzing pieces of the initial plans:

• Is it an important feature/concept?
• Will it make sense?
• Can it be balanced?
• Is it easily executed/developed? Nothing’s impossible within realistic terms. However, various things are highly improbable due to difficulty and/or time.
• Will it be fun? Obviously for games. I personally don’t believe in this one but, it is still important. Why don’t I believe in this? Everything is fun to someone and even if not, a good game developer can make it fun.
• Is it efficient and/or matches the overall concept? This is more for the technical side of things. Very important when determining technology possibilities. For example, I’m not too sure a monopoly game should be using the Unreal engine (Just my personal opinion).
• There’s plenty of others (probably unlimited) but, I won’t get that much into detail... yet.

     Moving on we have... plan... again!? Yes, can never plan too much! Okay, really you can. That just depends on the size of the project. A full-featured MMORPG can never have too much planning. Anyway, usually after analyzing the original theories, it’s time to rethink them based on the analysis. Because the initial overall planning is done at this point and the long tedious process of analyzing has been done to that plan, the second planning phase should be fairly quick. The time spent on the second planning phase should be double-edged by re-planning a theory and re-analyzing it at the same time. If the second planning phase takes just as long or longer than the first planning phase and analysis, it might be a good idea to head back to step one and start from the top. More concept art and graphics should be introduced, by the second planning period an overall style should be established for good.

     Planning is done and completed with full analysis and the project is ready to move forward. Now it’s time to design everything. This is where all of the concepts begin to make their way towards something a programmer can use. Designing should start with Use Cases (basically requirements) and tons of lists. The flowcharts and Use Cases should be compared to make sure they match and flow logically. During the design period, graphics should also begin to take shape. This means fine tuning concept art, digitizing it and of course world/level design. Graphics during the design period are very important but, they should adhere to plans and especially Use Cases. User Interface should be near finalized here as well, as it will be the way a human will interact with what you’re making.

     Implementation is a chance to take a breather. A lot of people say, “No! Don’t stop here!” I disagree completely. This phase is a great halftime point so take 2-3 days off, get some sleep, take the wife/husband out and get some sun. Let everything sink in a bit. Implementation is when the programming really begins. For many projects, it may have begun sooner but hopefully on a very small scale for little things or something like getting an engine, physics library and networking library combined. Implementing all of the design factors leads into a Prototype and ends with an Alpha version of a project.

     Yes, there’s a difference between Prototype and Alpha. Prototypes are usually choppy, ugly and are used to test core mechanics and tech-based features. An Alpha release should mean that the core mechanics are smoothed out and it’s time to start putting in features. Many might disagree but, I feel there is a big difference between the two. Acceptance Testing is where the Alpha is put through a repetitive process of Implement, Test, rinse and repeat. The Alpha is where this phase starts. Acceptance Testing follows through until the end of a Beta period. Going from Alpha to Beta is another big step. By the time a project reaches Beta, it should be fully operational, meet all requirements and contain all features. Beta is mainly non-crash-bug testing and polishing details.

     Before going into maintenance mode, here’s quick and easy way to get your head wrapped around the difference between Alpha and Beta. Alpha features are usually non-functional, period. Beta features are functional but, may or may not function correctly. If something has made it to a full release, it has met the Acceptance Testing requirements and its features are functional and function correctly.

     Maintenance is kind of self-explanatory but, it really depends on the scale and type of project. It also shifts based on the project’s nature and release availability. For example, some projects are in ongoing Beta for a very long time yet they are still available as if it were a full released version. Such items require constant maintenance. Other projects attempt to finish and close shop once Beta reaches the release requirements. Then there’s MMORPGs whose maintenance phase is quite literally repeating the entire design process indefinitely. All of these details are specific to each project and/or the entity in charge of them.

     In the next post I will explain a different more flexible development process which my current team is using. Because we are working on a full featured MMORPG, the term “iteration” will be used and abused more than just the standard maintenance phase of other huge MMORPGs. Iteration, flexibility and a different type of focus... it’s time to make a great game, fast!