11/22/2014 – State of the Game


It’s been a week of squashing bugs and reading posts. Here are a couple of things I’ve learned from watching everyone play. From roughly MOST to least important:

  • Inventory bugs are the worst bugs. The inventory bugs really seem to spoil everyone’s day. Nobody likes it when their stuff disappears. So I’m putting a lot of work into those. You’re not seeing many big updates, but case by case that stuff is getting fixed. The trickiest part is getting older save games to behave – I’m sort of embracing the challenge of making that work instead of just saying ‘start a new game,’ because I want to preserve save-game integrity after we launch on Early Access.
  • Crashes after the Prologue are far too frequent. The move from the Prologue to the Unviersity is very resource heavy and as a result even mid-range machines are experiencing crashes. My changes to the character textures should help a bit, but I need to do more.
  • Players need more information about basic gameplay. And I don’t mean hand-holding, just information. The Prologue is tiny, self contained and very short. Once that’s over I get the sense that people are overwhelmed by what they don’t know. The game is simple once you know the basics (I think?), so I’m going to write a little guide book similar to the interface guide book. That will be what you find when you wake up in class – it will give you some bullet points on how to play. (I really want to implement some tutorial missions as ‘classes’ in the University, which is something Hannah has suggested. But that’s probably too ambitious.)
  • Saving and loading. It’s getting better. But players should never spawn inside an empty building, it kills the fun dead.
  • Resources aren’t obvious enough. For instance, wild animals are way too good at staying hidden. They’re actually all around you – dozens of them, seriously – but nobody ever sees the frickin’ things. I’m going to make them dumber because they’re intended to be a resource, and you can’t gather what you can’t see. Same goes for mine-able rocks, trees and so on.
  • The main survival elements seem ‘fair’ to most people, but the weather system is confusing. I haven’t heard any complaints about how quickly you get hungry or tired or thirsty, so it seems as though these elements are fairly well balanced. The exception is temperature which (on top of being buggy) seems to just confuse everyone. I need to work on that.
  • People don’t seem to mind buggy updates as long as they’re frequent. I could be misreading this one, but I’ve broken the game several times with my 2-3 builds per day goal, and people haven’t complained. So I’m going to keep doing that. (Now’s your chance to stop me if you were just biting your tongue earlier.)

Alright. I still don’t think we’re ready for an awesome Early Access launch yet, but we’re getting there, especially if this pace keeps up. Several systems have really started to come together since the beta was launched. Onward!

Read more here: 11/22/2014 – State of the Game

11/16/2014 – GitHub: Now what?


Alright, here it is. I’ve chosen GitHub and set up a profile, an organization and a public Repository under the GPL 3.0 license. This is where FRONTIERS’ code is going to be made available for modders and enthusiasts.


Now what? Organizing this is… daunting.

First off, I won’t be uploading the entire project to GitHub because there are third-party libraries that I can’t redistribute (yet). Instead I’ll be uploading the pieces that I know for sure are free and clear. Over time I’ll add dependencies as I secure permission from the authors.

That means people won’t be able to compile something that, you know, runs. They won’t even be able to supply the missing dependencies from a third party because in most cases I’ve modified the middleware I’m using. They’ll just be able to look at pieces. Does this break some kind of GitHub code? Are repositories for projects expected to be complete? I dunno.

Then there’s the problem of how to incorporate other people’s changes back into the main project. (I’m assuming someone, somewhere may actually want to change something.)

Right now I’ve got a local project. I edit that, then commit my changes to a remote CVS repository. Given that setup, what to do if someone out there sees fit to commit a change to GitHub, and I see fit to incorporate that change into my local project? Is it even possible to mix and match two svn repositories at once? If not, what happens if I slip up and don’t commit my local changes to GitHub for a week and that person has now altered an outdated version of a class?

*Mind boggles*

Alright. Well. I’ve created the repository. First step: complete.

Read more here: 11/16/2014 – GitHub: Now what?

11/15/2014 – Day One: *WHEW*


Well, that was a hell of a day. Let’s count off some numbers:

  • 543 keys activated
  • Average number of concurrent players: 20
  • Median play time: 3 hours 5 minutes
  • Number of builds pushed: 4
  • Number of bugs fixed: ~9
  • Number of bugs reported: ~38
  • Number of games saved / loaded (by me): 51
  • Number of pigs killed: 58
  • Number of emails answered: ~60

Overall a good day. Exhausting but good. And I think FRONTIERS held up okay. There were moments where it was creaky – there were even a handful of unfortunate on-board graphics card owners for whom it wouldn’t start up – but it held together slightly better than I’d hoped. And it’s only going to get better as more of these bugs get fixed! Here’s today’s changelog:

Added additional logging to save game process
Containers added to inventory on startup will no longer spawn items when opened
Characters no longer disappear in previously loaded buildings
Switched from SHA256CryptoServiceProvider to SHA256Managed for group hash generation
Switched to .NET 2.0 subset (grr)
Examine no longer opens / closes doors
Fixed startup history book formatting
Changed liquids to require liquid container on removed from container
Changed startup fill categories for Prologue & Act I
Added fill instructions to Canteen on examine
Changed container fill time to OnVisible instead of OnOpen by default
Inventory items can no longer be moved while popup menu is active
Made pig den smaller in prologue to avoid clipping
Fixed motile action start without live target
Creatures can be looted with remove item skill Clean Animal
Removed ‘E:Search’ from HUD on characters before death / unconsciousness
Fixed some (not all) dangly ragdoll bits on characters
Added examine message to drawbridge
Fixed DenSick exception in Creature
People should no longer disappear from Camp Reuna on load
Added FOV setting to cutscenes
Tweaked prologue cutscene intro to make text more readable
Disabled nighttime LUT temporarily
Added nighttime LUT setting to kill over-vibrant greens
Fixed bookcase colliders interfering with item placement
Recepticles only show placement options when placement mode is enabled
Added throwing
Created placement mode toggle
Added ‘Mine’ HUD item for damageable / mineable scenery
Created item placement toggle for recepticles

Wow, what is this feeling? Is that… optimism? It kind of stings.

Read more here: 11/15/2014 – Day One: *WHEW*