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:
- Plan
- Create
- Test
- Implement
- Fix
- 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.
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):
- Game-breaking bugs or mood-killing 'crap'.
- Player annoyances. For example, things that 'work' but not as intended or portrayed.
- 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.
- 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.
- 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!
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.

0 comments:
Post a Comment
Feel free to give me any feedback and ideas. I'm not a genius or Einstein so please be constructive when giving criticism.