PHP, Zend Framework and Other Crazy Stuff
Archive for January, 2007
Factions: Social Control on Newbie Bashing
Jan 30th
A recent discussion was sparked on the Astrum Futura forums regarding player retention and new player protection. It was one of those times when the discussion branched to a higher view - a wider look at how players interact on a large scale.
The current suggestions called for players to be penalised for undesireable actions, e.g. attacking a new player who is incapable of defending him/her self. This remains a long standing issue in many online games. AF could resort to enforced levelling - limited who a player can attack, and be attacked by. But this is all artificial - in the real world it’s open season on anyone.
Cyberlot (Richard) raised the question of penalising through a Karma rating. As a player attacked newcomers they would attract negative Karma marking them out to other players. I can see the rank of “Newbie Basher” emerging as an undesireable outcome for many players. But Karma while adding some measure, does not address enforcement. Exactly who enforces what and when? Who set’s the standard for interacting with other players?
From there we hit the subject of Factions. A Faction would be a specific group of players sharing a common interest. This obviously includes Races, but is also extendable to a Merchant Guild or a Pirate Clan. The point is to give players an instant group they are a member of. Now where it gets interesting in how the player and game logic would respond in the presence of Factions.
Say you have a Faction, Earth Humans United (go Terrans!). What happens if a member of this Faction attacks a new player who is joining the Earth Humans United Faction? Can’t have allies killing each other off (even if it might reflect reality 
). The answer is in the Karma. Killing a new member of your own faction is stupid, damaged the Faction, and makes other players less likely to join it. That member should sur be paying tax to the Faction, which is needed. Such a player would immediately get negative Karma.
So we have Karma, and we have Factions - how do they relate?
Karma is a measure of one’s standing within a Faction. If your Karma falls below a minimal level you’ll be declared an enemy of the Faction, and then its time to start running before you’re hunted down by your peers. Where do you flee? If you’re lucky, some other Faction still has you as Neutral.
But this is where Newbie Protection get’s interesting. It’s not Faction specific - your bad Karma is classified when killing a new player as a “Stigma”. It decreases Karma for *ALL* Factions. It’s the ultimate punishment - imagine playing when nearly all the Factions refuse to grant you trade access, when your planets are penalised with “special tax charges”, when other players are unable to maintain an Alliance with you once you become Factionless (Outcast). In short, if you gain a reputation for killing new players, you’ll be kicked, booted and sent to Hell with a one way express ticket. No Admin interference or funny AI fleets required. Society will put you straight or else…
More on this later as details are worked out, but it looks like it’s a feasible and supported suggestion.
Thoughts on a Unit Testing and Test-Driven Design Experience
Jan 29th
Creeping closer to Spring; it’s 1 February if you follow my calendar. One of the things which stand out in my online activities as it touches on PHP is the 3 month period spent working on the QGL (Quantum Game Library). The library is just reaching its 200th commit, and should pass that barrier later this evening when I get around to a small class naming change.
Sticking with the QGL, it’s a small side project which sprung up from a vague idea. Those of us working on the related Astrum Futura game project, knew a standard game library of some description would pay dividends for future projects by centralising a general set of useful classes. It was shortly after this concept was solidifying when Jacob Santos joined the team with his imaginative vision of implementing AI algorithms.
The one thing that really stands out from the usual project hustle and flow, was our shared wish to use Test Driven Design and Unit Testing. It’s very difficult to use it on anything more than personal projects at work where developer resistance (though falling) is still an obstacle. So the QGL was an all too rare opportunity to cooperate in a team led effort focused around the test-first approach.
So how did we fare?
Personally, I think a lot of what we accomplished to date (bearing in mind the time limitations) was a result of TDD, and of course Unit Testing’s benefits in general. There were times where we were working on complementary components such as Jacob on Ai_Pathfinding, and myself on Quantum_Map_Measure where TDD led to simpler more maneageable classes. Of course the unit tests supported our efforts with style. Throughout the process we were both refactoring code, and tweaking interfaces. Without the unit tests we would have reached deep treacherous waters as our respective efforts slowly drifted apart.
I also think poor Jacob may have become test infected. He seems to be recovering, so I’ll have to wind him up later over the current two failing tests he introduced! I haven’t heard any rumours of a bald Jacob Santos so presumably that odd side symptom has yet to rear its ugly head.
Back on track… The most visible benefits of the TDD + UT approach during the last three months can be summarised as:
- Easier Refactoring (perform a refactor, check tests still pass, rinse and repeat)
- Immediate Feedback when code goes wrong (big fat red bars in the testing results. Hard to ignore!)
- Enforcement of Standards (tests discourage questionable hacks/shortcuts)
- Regression Testing (if something goes wrong, we add test(s) to prevent repeats)
- Force Feedback (not just a console controller type, failed unit tests spark attention from other developers)
- Code To An Interface (TDD and unit testing teach you why if you’re a quick study)
- Testable Code is Better Code (adherence to practices which generate clean, focused, flexible classes)
I’m sure there are others, but these were the most obvious over three months of development across 200 commits to subversion from two developers. If the immediate benefits are not a motivation to become test-infected the future benefits might. The one thing I know from past experience is that unit tested code tends to be easier to maintain and generates fewer bug reports.
Now of only someone miraculously removed the initial pain a developer experiences when starting to learn TDD and Unit Testing (the pain that explains why many quit before the summit of the learning curve is reached) we could get more folk on the TDD bandwagon. One unfortunate fallout from following a test-first approach is that it necessitates any new developers becoming educated. No easy task when dealing with a vast population of wannabe programmers taking their first few running jumps with PHP by showing interest in open source projects.
