First, making blog posts is a bit of an effort, which is why it happens so infrequently. Introducing: the Devlog.
We'll be posting periodically (every test cycle or so) in the subreddit to log our work and give you guys a better picture of what we're up to so this whole affair isn't just a big black box. Feel free to ask questions or criticize our decisions or whatever. If you post something on the subreddit that is well-formatted, and (most importantly) well-punctuated, we'll usually honor your effort with a response.
Alright, so what are we up to (and why are you taking so damn long)?
1) Bug Fixing
When we built our prototype, we built it to be very narrow. We built it do get things done as quickly as possible, with no consideration for code quality. We had one job to do: make it fun, as fast as possible. After we scrapped the prototype, we started building a very wide game. That goal is entirely difficult. We know our game is fun, now how do we build it in such a way so as not to limit our options in the future?
Conventional wisdom dictates that you build the narrowest game to get your idea done. In the startup world, that's called the MVP--Minimum Viable Product. It's a sound strategy to pursue, but of course we know better than every successful businessman of recent times, right? We believe the MVP has to be redefined a bit for games, as at it's most simple, the definition of "whatever players can get their hands on and play" is insufficient. Sure, but what about when you have to update said game? That's where most early access games hit their trouble spots.
In our minds, MVP for an early access game (and no, that's not us committing to early access) is both something that players can play early, but also something that can be updated and expanded upon easily. When your update rate isn't fast enough to fix the problems that players find within the game, you've got serious problems. These problems aren't isolated to the obvious technical ones like hacking and game crashes; failing to patch your game's design in time means that players will play out its systems to the point where the game is no longer interesting, and in the worst case this playing out is irreversible.
Aside: That Old Dead Horse, DayZ
Image shamelessly stolen from the RockPaperShotgun
A good example of "playing out" can be found in the community shift in DayZ (again, one of the few games dear to my heart). At first, DayZ had a healthy balance of bambis, uninitiated players who'd prefer to do no harm to their fellow man, and bandits, disillusioned psychopathic veterans. Like the process of reduction in cooking, DayZs community inevitably boiled out, leaving only bandits. If DayZ had been developed under ideal conditions, it would have had an extensive, well-tuned survival and character development system that put hours of gameplay before what I call (ominously) the turning point, so as delay this process of boiling out for as long as possible.
Essentially, the turning point in DayZ is when a player has A) done everything in DayZ: flown the helicopter, fired all the cool guns, and B) has developed the knowledge of how to find these things again easily. At that point, dear Bambi goes bandit. Bambi realizes that survival in DayZ is rather boring, once figured out, and also through inevitable past experiences realizes that killing sure was unlike anything Bambi had ever experienced in a video game before.
This event is irreversible. Once players develop the habit of killing for sport, they can never not know it's pleasures, and every experience within the game, even the experience of attempting to play someone good, can never escape that frame. Even with only a community of bandits, the game is still worth playing, but ultimately a far less rich experience than before.
Genetically, Due Process inherits from tactical shooters like Rainbow 6 (3 and below, of course, though we believe Siege has accomplished its goals rather admirably and we salute them for it), SWAT, and Arma. These games did not have a dramatic playing out, but we are doing something different than them in that we're trying to achieve the impossible: get joe schmoe to put his microphone on and really play. While we're not at risk for losing something profound in Due Process, but we do know that our goal is a very delicate one, so we've exercised caution by taking development a bit slow.
Earlier this year we decided to model most things very rigorously, using few abstractions, and now we're paying the technical cost of that approach. While the systems we've built are robust and due to their nature of construction, relatively easy to build off of, they're quite complex and because of that create a lot of bugs and can be a bit difficult to maintain (any experienced developer is going to find that last part troubling). I have mixed feelings on the approach, but given that our to do list has zero bugs on it involving these systems, I'd say there's a pretty good shot that it's about to pay off. Time will tell.
What do I mean by 'robust', exactly? Easily expandable with obvious solutions to problems; object oriented. Have a crazy design idea? Yeah we can do that.
Want to shoot a grenade in someone's hand, causing it to blow up? Well, in something like Counter-Strike, I'd imagine that's going to be a bit of a hack, as the grenade on the character model isn't exactly a grenade. It's the mesh of a grenade--it doesn't have any logic attached to it and is rather subject to some other logic that toggles these models on and off when a grenade is added to your inventory. At least I presume that's what's happening--not like I worked on CS; I was 9 in 1999.
Dat logic tho
In Due process, that grenade in your hand is actually a grenade. The inventory system is entirely physical, meaning that whenever you pick up an object off the ground, that's physically (virtually?) the object in your hand. So add the event listener OnBulletHit to your grenade class and you can have that logic detonate the grenade.
Yeah. Turns out all the legwork making that process easy-peasy is kind of a bitch. A physical inventory system is fun, but there are a ton of problems that come up when you're so closely linking game logic to animation and physics and rendering.
Anyway, the good news is that these kinks and quirks have almost been ironed out (and boy were there many), so now we can stop bugfixing and really start building. Famous last words.
Another example: want a breaching round for your shotgun? Easy. Just make some logic that does the breachy bit and attach it to the projectile (class--we're not simulating projectiles, our weapons are 'hit scan') which is fired from the shot shell, which is loaded into the magazine-tube of a shotgun (or perhaps, a detachable magazine, if you have something fancy like say, the VEPR 12). That will load into the chamber of the shotgun and when it fires and hits the door (or perhaps a special part of the door), it will "unlock" it.
While it came at a substantial cost to the time to complete the project, the good news is that we shouldn't be limited by arbitrary decisions we made in the past, allowing us to make design decisions quickly and try to keep our community in balance, coordinating and communicating.
2) Game Design
Making guns, tuning guns. Making it so your aim doesn't hitch when the camera is moving to a position behind the iron sights. Making our (extremely temporary) sounds not suck so bad. Making movement feel good. Testing different forms of hit confirmation without resorting to the tried (or perhaps more appropriately: trite) and true X on your screen. The list goes on.
Good lord, kevin. At least I don't have to worry about you hitting anything.
What you're seeing is our little makeshift team deathmatch arena. We're not quite testing our attack and defend mode just yet (though it's implemented, just shelved due to performance reasons). In Counter-Strike, it's customary for a new player to spend dozens of hours in Arsenal to learn recoil management and crosshair placement before said player goes into ranked play. We're spending dozens of hours designing recoil management and... well there's no crosshair but never mind that.
So that's why we've been mostly quiet. We'll be going loud soon enough.
Ciao for now