My program doesn't have bugs. It just develops random features.
A day in the life in the nieghborhood...
02-10-2003: Okaly, so the minor Three Team project has turned into a resulting minimod called "Riftwar" - wherein rifts in time and space have opened up conflict between humans, aliens and the undead. This was done in part to avoid some of the issues where Epic had hardcoded team stuff (skins, beacons, etc) and where they hadn't (Team AI, scoring, etc). After some real frustration (Pawn.species != replicated) with it, I have a working though somewhat incomplete version running in pretty much the course of a few days of crash coding. Hopefully tonight I'll add in the additional details I want, test it this week and then not only make a release but a full post mortem/tutorials on how to accomplish a similar mod. I'm keeping this simple, partially because this was only intended as a proof of concept for some FHNG things and also because it will be easier for people to run with it later. Riftwar should provide a decent example of how to build a custom class-based mod using only things you can find in your own home.
02-03-2003: After fixing the big netcode issues with FHNG's current inventory system, I went in a different direction and started to try and break UT2003's two team limitation. It was a pretty frustrating afternoon, finding a lot of little details which makes the assumption of a two team system rather than just coding in a flexible way. Most bizarre, though, is that the teambeacon code doesn't seem to exist anywhere in the UnrealScript side of things - an extremely strange choice, imho, for a natively coded aspect of the game. Would it have killed Epic/DE to have given us one solid example of interactions in the game?
In the end I got a gametype that would compile, spawn a third Team class and AI class and play a team game, but no real code to handle actually putting anyone into that third team. Also, the HUD seems convinced for some reason that Team's score is actually Team's and the very last test removed the teambeacons all together, though I swear I only changed the scoreboard...
01-28-2003: Freehold NG so far has a fairly robust inventory setup, much of the core gameplay rules from FHUT (bounties, balances, etc), and I just added in some interface customizations as well. I can't really speak about how the models are coming along because MoP still has me sworn to the hush hush on that side of the development. So I can only say nudge nudge, wink wink, and damn they are doing a good job.
01-07-2003: Bringing in the New Year by bringing back the Dev Diary, something I had done earlier with Freehold UT, and now the Freehold NG really has taken root, I'm going to start this on a more regular, if not weekly, basis.
Last night I started to work on the framework of Bounty War again. One thing I learned from FHUT is that later gametypes can benefit from having the strongest parent class possible. Instead of BW, Frenzy, etc., I'm going to try and put as much flexibility like starting balances, rounds, and different goals as possible. Getting a configuration tab to work with new settings had proved difficult but last night it seemed to work correctly for the first time and I could set the number of rounds playable per map with some ease.
Also worked on the gateway code which allows for players to transmat out of the playing field for a short time to buy and upgrade their character. This is a severe change from FHUT's use of the UpLink which forced people to use it ingame (although 039 introduced some rudimentary buy protection). There's a huge change of balance here, as this method is easier to use but also disrupts play. One of the end design goals of FHNG is to allow people to play with setting little, if any, custom configurations and keys - this is one part of that design. To keep the action fluid, there will be more of an emphasis on buying enough ammo and supplies to last the majority of a game round, rather than continously pushing buttons to buy health and ammo.
The early gateway code works, except that it has this tendency to fire your weapon for you while you aren't even in the game. Fortunately UT2003's codebase offers a lot more flexibility when it comes to altering the player's control code and it looked like the bug was only a few states away from being fixed in the first place.
Work should be steady now that the holidays are over. I have to catch up with MoP and his crew to see how the new models are coming. I've seen some samples, but I've been sworn to secrecy...