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!

Getting Back Into the Game (Development)

     It’s been a long while since I’ve done a blog (or any game development for that matter). Recently I’ve been getting back into it heavily. I’m hoping that I can seriously find a way to make it permanent this time (i.e. will design/develop for food). How does one go from 110% hardcore activity in anything to 0%? How does one go from 0 to 100%+ again? I’m sure there’s not a straight answer for either of these. Honestly there’s no point unless going back to something is due to an irresistible itch that nothing else in life can scratch. For me, it’s pure passion. Words honestly can’t express how much I want to design and develop games; not only for a career but, even just for fun.

Going from 110% to 0%

     That’s actually pretty simple in my case; money. I gotta eat, y’know? I spent as much time as I could designing and developing my portions of Hack Wars. After a while though, having to find work for money, working, then trying to get back to the second love of my life just took it’s toll. Stress and anxiety made me actually sleep! I mean seriously, I’d stay up all day and night for 2-3 days in a row until stress kicked in. I gave up playing games to get to what I wanted to do. Outside? What the hell is this? I’d rather be working on Hack Wars!
     Unfortunately however, life called upon me to do its bidding. After so much over the course of just a few weeks, my development and design time dropped to nothing. I couldn’t get the energy to get into it. Ever have that feeling where your body’s tired but your brain can’t stop? How about the other way around? You got the jitters and feel like you could run a mile but your brain keeps making your eyes roll into the back of your head, closing your eyelids and slowing your breathing... THEN YOU REALIZE YOUR WALKING STILL! Yeah, completely bad juju there. Micro-naps such as this are very bad. Good micro-naps should be planned, not happen suddenly in full motion. Thankfully I wasn’t driving a vehicle or anything, that could be bad (and has happened once on a long road trip). So, needless to say, for the first time in like 1-2 years I started to sleep regularly. Anyone who knows me (or even knows of me) could be asking, “Are you sick?” Online at night? Same here. Online in the day? Me too! How about in between? I swear, I’m not stalking you.
     Getting more sleep due to complete exhaustion meant a lot less time for me. I went from 4-5 hours every 2 days (average, sometimes less sleep) to getting 6-8 hours nearly every night. Quite a change and, more importantly, a waste of time! I hate sleep. Takes up far too much time and my lack of design and development for Hack Wars was obvious proof. I have to admit though, a lot of the tedious work for one of my favorite games definitely didn’t help, it really lost its ‘fun factor’.
     Which leads into another minor reason I fell out. A lot of the work was in bigger ‘chunks’ which were difficult to complete without dedicated time. Not going into details but, it’s really hard to be motivated to do a 5-6 hour job in 1-2 hours at a time. In the long run it ends up being more like 10 hours total which isn’t very efficient.

Going from 0% to 100%

     Recently (within the last month or so) I received a message which was the physical, emotional and mental motivation and inspiration I needed. Physical? Yes, my heart skipped a beat for multiple reasons then began pounding with adrenaline. What was the mental reaction? Whoah! There’s no way I’m going to describe everything that went on in my head in less than 0.357 seconds of reading this message. Not enough time and people would be waiting forever for such an amount of text to be downloaded. All that needs to be said is that about 2,387,731,094 thoughts, images, videos, text, etc in one big garbled message. What the hell does emotion have to do with it? Everything! Unlike most, I have an extreme passion for games and the design and development they require, especially complex and well-rounded games like MMORPGs. I have an undying love and near unlimited loyalty for Hack Wars especially.
     I am more than convinced our game will reach a point of no return. It’ll reach a point that keeps gamers of all kinds completely addicted. A well informed and educated person can take a step back, look at the bigger picture and say, “Whoah”. This isn’t just a game to be thrown into the wolves. The team creating this game definitely has something. These things cause an insatiable drive to be a bigger part of it and make a deep impact on something incredible. I’m ready to take it all the way after several mishaps, realisations, epiphanies and a few words of wisdom from friends, family and even just old geezers with plenty of “woulda, shoulda, coulda” in their life.




     I think I’m obsessed. I may have an addiction problem. If so, I really don’t care. Can’t really be happy if I’m not doing something in my life that I like. It’s not like my obsession and addiction is destructive. I’ve been ridin’ the clutch for too long already. Time to shift, pop the clutch and slam on the gas. Expect much more from me, pressure me if you want (I work well under pressure). Most of the time though, my posts will be more ‘on topic’.

“Hi! My name is Chris and I’m addicted to making games.”

A New Era for Hack Wars

Yesterday the Hack Wars development team had an extremely constructive meeting. Very rarely in the current team's history did the Hack Wars development team seem completely unified. Everything was pretty scattered. Megabytes (possibly Gigabytes) of data is saved by each team member in several forms such as documents with notes, design diagrams, task lists, etc. Nothing really had a set sense of direction for us as a whole. Of course we have major plans for development for this year. Even though the first month is nearly over, we finally have things setup to better develop a tiny, bug-ridden and feature-dry MMORPG into a large, clean and feature-rich game which any gamer can like and any programmer/developer can love.

New Development Methods for Hack Wars
Of course this is always a plus, right? Well, for Hack Wars our methods were pretty barbaric and brute-forced attempts at an actual method of progressive development. Very poor tracking, lack of tools (or just lack of tools being used). We also threw a lot of weight into content and features which left the game's core engine severely bloated and unbalanced.

Not anymore. The Hack Wars team has reformed and will be taking a huge leap into a more professional hierarchal and structured method of development. Before, we were developing and updating directly from a single 'trunk'. While this method was just barely okay for simple small tasks and updates, creating a huge feature/fix lead to very big problems. Not to mention if one developer updated their working copy of source before another committed large changes, those changes could be lost due to an accidental overwrite. This has been remedied by restructuring the code-base a bit to separate live from development.

We now have a different system of development and a much easier method of keeping large projects within the source able to be developed separately from small updates. This will allow us to maintain a much more smooth process for updating the live Hack Wars server. We now have a plan for at least a small update/release every 2 weeks.

A Whole New Team
No, nobody was replaced. Nobody left and nobody joined. The Hack Wars Development Team has reformed, regrouped and is (and will continue to) maintain constant communication and a much more team-friendly approach to development. No longer will certain members be 'out of the loop'. No longer will developers have a 'blackout period' of falling off the face of the Earth.

The primary developers (owners) of Hack Wars have been busy and successful in their lives outside of Hack Wars development with doctorates and major thesis developments. Not to mention Ben (aka Johnny_Heart) is a developer for FreshBooks, who recently had a major update/release. Our leaders-in-development have finally reached a point where they can take a slight breather and get back to their fun project - Hack Wars.

We've all agreed to several things that will benefit Hack Wars on a massive scale. These things include proper development methods (as stated above), better bug/feature tracking (especially documenting/noting changes), constant releases (even if very small) and much more interaction with everything involved in Hack Wars.

What's this mean for Hackstock?
The primary focus for my role within the team is content design and development. This is usually system-driven entities, concepts, currencies and anything else the players of Hack Wars interact with which extends the core-functionality and gameplay of the game engine and core. For Hackstock, the new elements laid out for our team means a lot of work at first which will pay off greatly in the long run.

First, I'll re-enter a major design phase. The new designs being created will be much easier to manage and share data that is based on the designs. Once the designs are complete (at least ready for initial development), developing a few systems/methods linking design to implementation will be created. The best part, I'm hoping to design/develop a system that will take a lot of the 'chore'-work out of content creation and management; something a bit more efficient and reliable.

We (the Hack Wars Development Team) have a much more definitive plan of action and a clear path in Hack Wars development. Time to fit my designs to that plan and help develop Hack Wars in several smaller hops rather than huge inaccurate leaps.

2010 - Learning from Past Mistakes in Development

I've been developing Hack Wars for a few months now and have been able to actually apply my (incomplete) college education as well as some limited experience to the Hack Wars project. Of course, as with all things, I'm learning several new things each moment spent in development. Unfortunately I haven't accomplished as much as I wanted to in the time I have been developing this great hacking MMO. The good news is, I know several reasons why my goals haven't been met; as well as why development with Hack Wars was slow before.

Development Process
Several things have been skipped and/or missed by previous developers as well as current developers. There's still several gaps in the development process and/or 'old holes that haven't been filled'. This has hindered quite a bit of progress for Hack Wars and it is beginning to hurt more and more each day.

Design Document
There is/was no Master Design Document. At first glance, this may seem like a petty requirement that can be forgotten. Not to bust anyone's bubble but, how the hell do we know what we're doing? Programmers/developers have one thing in common, whether for a game or just another piece of software: We create something based on the specs given. Granted there's more to that (like everything in life) but, the validity of the point remains true. Creating something new is like exploring a new place that you haven't been to before - It's too easy to get lost without a map and asking for directions on the way is rather inefficient.

Usually the development process is a cycle. It can be extremely complex and confusing with several 'branches' in the cycle but, there's a few things that should remain in constant motion and in this order:

1. Plan
2. Create
3. Test
4. Implement
5. Fix
6. Back to Step 1

I know this is technically wrong to most but, let's look at it from "laymen's" terms:

• Plan
• Obviously before you do something, you usually think about it first. If you want to create something worthwhile, it better be planned or it's going to either a) suck or b) just be half-assed. Plan ahead, or your hard work becomes nothing more than a gamble.
• Create
• Obviously you need to create something first. If (in Hack Wars situation) the foundation is already created, you'll be creating new things to build upon that foundation. In terms of games this would be new content, new features, etc.
• Test
• Once you've created something, you need to test it...then test it some more. Oh, after you've tested it, it needs to be tested again. Keep in mind - Public testing separate from what's current is needed in order to maintain the game's balance.
• Implement
• If everything passes the initial tests, implement the creation; put the creation up on live. Then watch it and the unforeseen impacts it may have.
• Fix
• Even after testing, we'll still find problems. If it's something serious, hot-fix it right away as if it needed to be done last week. This is usually the case (for example, in Hack Wars) when a player finds a bug that gives TONS of rewards. Less-serious things that need fixing are things that function but, not quite as intended. As long as it's not going to keep players from playing or give players more than they should get, we can give it more time before pulling the server down.
• Back to Step 1
• If you've gotten this far - everything's great and time for some new creations. Keep the process going and with each new creation - keep an eye out for unseen 'dependencies'. I'm not talking classes, inheritance and other programming techy mumbo jumbo. I'm talking about things such as making a specific item drop more often than before and that item is linked with quest difficulty, can be sold on the market and was meant to have some value. Give it away too easily, and it has no value.

So, we have the basics of the process down. With how little it's been used in Hack Wars, we have seen several problems (and still do currently). We've been forced to play "catch-up" and it seems to be a losing battle without some fixes.

Organization
Obviously, without the cycle and/or the design document, there's not much to organize with so why even mention this, right? Wrong!! So wrong! We have several great tools right in front of us and they're things that anyone can readily have in front of them rather quickly, no matter the size of the project:

Website
I know, the internet is for pr0n right? Ha! We have a website with a great CMS system, forums and plenty of possible ways for player feedback. Heck, there's a bug forum, suggestion forum and even a few pieces in other forums where several players have request/reported various issues.

Sourceforge
Great Subversion Repo, commit logs etc... I think we (at Hack Wars) have failed to notice/utilize the Bug, Request and Task tracker here. There's several people on the developer list and only a couple bugs listed within the tracker. This could be put to much better use. That means even having someone go through the bug forums and suggestion forums and copying those bugs/suggestions into the tracker on Sourceforge.

Feedback
We've got tons of it. Unlike other games, Hack Wars actually has its developers (including myself) right there with the rest of the players. Some of us interact with the players several hours throughout the day. Again, we have forums as well. We have a Twitter. In any development project, you should always give the consumer/customer/client what they want. When it comes to games that doesn't mean give them a money hack, experience hack, free item hack etc... They usually want something more to do, something new and, most of all, for things to work as they should without huge game-breaking bugs.

Team
Most projects (especially sizable ones such as Hack Wars) don't have a single person doing everything (we hope). In certain cases where there might even be limits to team members, their time, their communication etc...using the tools stated above should make this a lot easier. Now for the next step, make the team work smart, and work together. In Hack Wars we'd have a great team. Members can do a lot of the major code edits such as fixing game-breaking bugs, new features, etc. Others can take care of hard coding the small stuff; details; little bugs. A 3rd group creates content based on what the other two offer. If we continue on this path (keeping priorities straight) we're in a winning situation.

It's very important that for any project to have good organization. Every team member should know (and use) their skills to fit the role that they've been given or that they've volunteered for. I have definitely lacked here. I have been extremely ignorant of the tools right in front of me and haven't quite prioritized things correctly due to lack of organization. Which leads into another thing I've noticed about development....

Priorities and Process
Yep, we're back at processes again. With any project, it's all about process. Process and progress go hand-in-hand. Process is like a wheel on a vehicle while progress is the ground covered by that wheel moving.

Organization puts everything into perspective. It puts things in order. How can you prioritize without anything being in order? We all wish we were telepathic and telekinetic gods of our art(s). Thinking this though is telepathetic. We can't do too many things at once, no matter how hard we try and/or how much we've convinced ourselves that we can. Multitasking a few things is fine, if they're all directly related. So, organize and prioritize.

In a game development environment, priorities should be (basically):

1. Game-breaking bugs or mood-killing 'crap'.
2. Player annoyances. For example, things that 'work' but not as intended or portrayed.
3. Things that have been around for a while. If it's an old bug, why let it live? It will get in the way sooner or later.
4. Things that weren't completed, at least take a look at them and see where they stand. Otherwise, if you've relied on this for future content/features, it will halt all progress anyway.
5. New content and new features. If you have anything planned and the game/software's running smoothly, now's the time to take advantage of it!! Expand it! Update it!

For many, this may seem rudimentary and barbaric but, it's amazing how much priorities get thrown out the window for something 'new'. I've had so many ideas and worked pretty hard on things way out of order of priorities. It's cost me dearly, and anyone/anything else that was relying on me.

The New Year, The New Developer (Me)
This year I'm going to start off by taking a step back. I'm going to look at the bigger picture, plan further ahead, devise more detailed attack plans and get things organized. Hack Wars has made a huge jump out of its previous state of disrepair and I can definitely guarantee an increase in progress throughout the year, especially within the first month or two there's going to be some large changes.

I can't do this alone, however. With my various projects I'm definitely going to be calling in the cavalry to my side and make sure we regroup, reform and take out any obstacles in our way, together.