Ucc Make Columns/1.4 Patching The Beta
ucc make (1.4)
part of the ucc make columns series...
Patching the Beta
Games, and well programs in general, have gotten fantastically more complex in the last decade. Gone are the days of the 8-bits, the 16-bits, the 640k limits, the time when you could fit multiple games on a single floppy. This complexity has given rise to new genres (clearly the FPS genre couldn't exist before 3D could really handle it), birth to online gaming, and an evolutionary step in new and more powerful bugs.
The term "bug" in conjunction with computing comes from the old days when computers were behemoth machines with rows of lights and pretty things to attract a creature such as a moth. Indeed, at one point a moth flew into the computer, died, conflicted with the delicate hardware and become the world's first real "bug" in computing. These days the bugs are much less literal, but much more evil in nature. It stands to figure that code that is thousands, if not millions, of lines long is more vulnerable to weary days when three digits was more than enough to count the program.
Consider your average FPS mod. Most mods these days are either interpreted code (such as UnrealScript) or native code (such as C++) added on to a pre-existing engine. In the former, there are now two languages at least and in either case their is usually some kind of interface the mod is using. Move backwards from this point to the original game, it has sections of code to handle 2D graphics such as textures and sprites, sections to handle the 3D engine, sections to handle in-betweeners like effects and particles, sections to handle the definitions of various actors within the engine (weapons, armor, ammo, health), AI code, netcode, menu code, and so on. Considering this is a commercial product, it's usually safe to assume that it's fairly stable...although every modern game these days has at least one - if not four or five or even ten - patches after release. By itself, the game is a complicated network of subsystems which can have small flaws and bugs which don't ruin or may not even be usually noticeable in the game.
Now enter the unsuspecting mod. The nice thing about mods is that a lot of the real rocket scientist stuff, like particle systems, animation systems and 3D rendering is done for you. The problem with mods is that as you add your own sections of actors, AI, netcode, menu code, and so on - you are not only opening the chances for new bugs but are also possibly weakened by existing flaws in the system. While one programmers shortcut late in writing the spawn routine for a weapon may have no impact in the commercial game, it may have catastrophic events on the person who tries to subclass that weapon.
It's kinda like a reverse house of cards. You keep stacking more and more on top and there is much greater chance of collapse. Worse, few mod teams have the resources to have a hardcore beta testing staff. Beta testing is one of those unsung arts of computing programming, because as my old Quality Assurance Manager used to tell me, it should all be about prevention - not fixing things at 3AM before handing stuff off to a client.
Mods have this odd tendency to use beta testing as a defense. Counter-Strike started it, refusing to leave beta until was forced by Sierra when it commercialized. Alpha and Beta's are (by definition) not supposed to be public. Alpha essentially means work has begun. Nothing's really working, just getting things started. Beta is supposed to be the testing right before a public release, meaning the feature set is closed and you aren't adding any more cards to the stack. Test, find bug, fix, rinse, wash, repeat.
The problem is unless you have a lot of dedicated testers, bugs these days can be hard to find. In fact, in the many betas I had with Freehold , there were several bugs the testers found that I didn't even know were bugs until I tried to reproduce them. Sometimes they just sounded like weird quirks in the gameplay, or something I *knew* I had fixed a version or two ago. Especially in object orientated code, bugs can be like viruses - they'll mutate, hide, and arise again. A bug I just found in the preview of Freehold just released this week was one I thought I had fixed last week (don't worry - it's killed now in the internal release...I swear...I think).
Here are a few tips when trying to beta test with a small team:
-KISS stands for Keep It Simple, Stupid. It's a mantra for coders to know when to hit themselves on the head and not overengineer something. Out of all the problems with designing and coding an overly complicated system, the chief one is that is opens up the possibility of conflicts and makes problem resolution harder.
-Either don't test your own code or take some time away before testing it. While a lot of coders will write, compile, test, tweak, repeat for day to day work, it's not the best testing. It's like trying to edit your own term paper right after writing it. You are so familiar with the work that you'll glance right over the flaws. Another pair of eyes is essential, or at least giving yours a break.
-Write down the little things. Keep track of the tiny flaws as you notice them. It might seem trivial now, but it could later cause a bigger problem.
-Regression, regression, regression. Half the bugs I've caused in Freeholds were fixes for something else (including the fore mentioned one). Test to make sure that you have not only fixed the bug, but also test any code that the fix might be coming into contact with. In the case of the sample bug, I made a fix in the game's ReduceDamage function, but didn't completely test the Killed function.
-When it comes to gameplay, majority rules. This isn't a rule - but a suggestion. Especially for teams with only a couple of coders. Listen to other people playing the game when it comes to non-programmatic bugs but possible design flaws. What's easy for you may be completely impossible for a new user. Thanks to beta testers, I changed buy rules, weapon features, item features and more. All concepts which worked for me but probably would have infuriated someone else.
-Finally have fun. It's a game and a hobby after all.
Fixing "Patching the Beta" (ucc make 1.5)
Column Changelog July.03.2003
-Added link to Mychaeel's excellent column on beta testing and modding in general: http://wiki.beyondunreal.com/wiki/Mychaeel/Modding_Etiquette.
-Used Mychaeel's ideas as a connection to Unreal Wiki (http://wiki.beyondunreal.com/wiki/HomePage) in general, noting that a shared community is a more reliable community. Completely independent programming projects are more likely to have unseen bugs and creating a more "foolproof" mod community starts with sharing development ideas, libraries, code.
-Realized "bug" intro was trite, overused ... replaced with brief history of QA in general.
-Noted that the "other side" to community beta testing and bug fixing the is the possibility of inefficiency. Urge new coders to seek out existing material on problems, bugs, ideas rather than asking fresh (and possibly redudant) questions.
-Should question the current "tone" of UT mod community - the odd quiet as everyone waits the next codebase, wonder if there will be a kind of void for older UT efforts.
-Use above note to connect to fact that the new codebase may be elusive.
-It will bring new bugs, new features, lose old ones ... language may be similar but warn developers looking to port that it might not be so simple.
-Use converting LightSaber to Longblade as a sample - different code for detecting bot users, processing trace hits, animation routines ... end with "what looks the same on the outside might be a completely different beast on the inside. Upcoming gametypes might mirror the classics (CTF, DM), but doesn't mean the code will be the same.
-Got rid shameless Freehold plug and replaced ending with acknowledgement that the UT2k3 demo should (probably ... might?) be out in a couple of weeks, and wonder how the removal of the original Unreal1 codebase will impact the smaller mod projects.
-Put shameless Freehold plug back in anyway. Note that the new preview will at least double the existing gametypes. Use this to end with a teaser that next column will be all about evolution in deathmatch gameplay.
Other ucc make columns
please reserve edits to minor changes and comments – RegularX
