Good evening/afternoon/morning!

The first automatic nightly build is live! If anyone is interested, you can opt-in the same way you opted into the unstable branch.

Nightly builds are there for people who really wanna track our progress– not for people who just want to play the latest version of the game. Please back up any saves or worlds you care about. No, seriously. Back up your saves. It’s always best to assume they will be destroyed and the game will be at least somewhat broken.

Tonight, for instance, because we’re working on monster spawns, monsters aren’t spawning. This is the sort of thing you should expect from nightly builds.

(Tiy note: Also, because we’re currently working on progression, the very first thing you’ll probably notice is that your ship is damaged and the fuel system doesn’t work (sparks flying out of it). The only way to currently fix the ship is through admin commands so unless you know them you’ll be stranded. This is *really* for people that want to see progress + modders. You have been warned!)

I’ve updated the support page with a guide, but I’ll paste it here too:

What is the “nightly” branch and how do I switch to it (or back)?

The “nightly” branch of the beta receives updates automatically every single day. This means that using the nightly branch will frequently destroy your saves or contain other game-breaking issues depending on what we’ve been working on that day. Only use this branch if you really really want to follow our progress and don’t care about breaking the game. 

To switch between branches (click on images to enlarge them):

• Right-click on Starbound in your Steam client’s “Library” tab and select “Properties”:
  
• In the window that appears, select the “Betas” tab and then select the branch you want to use from the first drop-down.
• You should receive a confirmation message along the lines of “Successfully opted into the ‘nightly’ content beta.” below the textbox next to the “Check Code” button (note: no beta access code is required to opt into the nightly branch).
• Click close and let Steam download the update for the new branch. If you’ve switched to the nightly branch, Starbound should now be listed as “Starbound [nightly]” in your Steam library, otherwise it will be listed as just “Starbound”.

If you ever wondered what it’s normally like in the developer chat and the shit we talk about all day, I’ve copy pasted some stuff here without further comment.


<OmnipotentEntity> kyren, did we ever implement an ordered set?
<kyren> yes!
<kyren> I just did actually
<kyren> it's not comitted yet
<kyren> but I'll hopefully be committing it today
<OmnipotentEntity> ok cool
<OmnipotentEntity> I need to use it too
<kyren> do you need it right now?
<OmnipotentEntity> if it's not too much trouble
<kyren> okay, let me make sure it works then
<kyren> I'm debugging now anyways
<kyren> I'd actually just like to merge
<kyren> but it will require some debugging
<OmnipotentEntity> ok
<kyren> I could push and you could help me debug all the problems
<OmnipotentEntity> that's fine
<OmnipotentEntity> yeah
<OmnipotentEntity> I think that will be great
<kyren> well, let me make one pass on it at least
<OmnipotentEntity> that's definitely better than what I'm working on right now
<kyren> because it's really REALLY not working yet
<kyren> like the title screen doesn't work
<OmnipotentEntity> that's fine
<Tiy> hey metadept
<metadept> hey
<Tiy> would you mind doing a post today
<metadept> sure!
<metadept> i'll get right on that
<kyren> hey omni, I'm almost ready to push the thing
<kyren> I just need to make sure it mostly works
<kyren> and then I'm going to go get something to eat
<kyren> and come back and we can debug it
<OmnipotentEntity> ok
<kyren> also, I want to push it because I really want your feedback
<OmnipotentEntity> roger
<kyren> will anybody be super mad
<kyren> like metadept
<kyren> if I push something that is somewhat broken
<kyren> but still playable
<kyren> so omni and I can team debug it
<metadept> nah i won't be mad
<kyren> omni needs a thing
<metadept> will i be fine if i don't rebuild or is it still going to be broken?
<kyren> and this phase is nearly done-ish
<kyren> eh... I THINK it's fine if you don't build again
<kyren> I don't think I changed assets much?
<kyren> oh, maybe I did
<metadept> don't worry about it in any case
<kyren> okay it's still pretty broken but
<kyren> I'm going to push because I have to leave, and I'm going to continue working on it when I get home
<kyren> like haha
<kyren> the HUD items are key dismissable now
<kyren> that's not really too good
<metadept> i'm on the fence between saying you should wait on the nightly builds, and saying you should start nightly builds right now so players know how bad it's going to be lol
<kyren> pff, no that won't be for long
<kyren> it's literally
<kyren> everyone wants to go eat burgers
<kyren> and I'm hungry
<kyren> and then when I get back home I'm going to fix it all
<kyren> but omni needs a class in it, and I want omni's help in stuff, and blah
<kyren> so I'm going to push it in the meantime
<Katzeus_> is the plan to do nightly builds just to bridge the time until progression goes to live?
<metadept> yeah i'm at least half joking
<metadept> go forth and eat burgers
<Katzeus_> or like ongoing
<kyren> ongoing
<kyren> there pushed, god help you all
<kyren> brb
<OmnipotentEntity> kyren liar
<OmnipotentEntity> I thought you said that the title didn't work
<OmnipotentEntity> the only bug I've found thus far is if you press escape a bunch it takes away part of your UI
<metadept> hey OmnipotentEntity, kyren, what do you guys think of a 'fixed camera' mode?
<metadept> it would be really helpful for recording gifs
<OmnipotentEntity> fixed camera?
<OmnipotentEntity> hmm...
<metadept> just having the camera locked to world position instead of player
<OmnipotentEntity> yeah useful for dev work
<OmnipotentEntity> I'll add that right now
<OmnipotentEntity> it's super easy
<metadept> also i could see it being used for machinima
<metadept> i figured
<OmnipotentEntity> hi there kyren
<kyren_> Hello
<kyren_> Set up phone irc
<kyren_> How bad are things
<kyren_> I know you can dismiss hud elements at least
<kyren_> Which is bad
<OmnipotentEntity> that's it that I've seen
<OmnipotentEntity> and I think that's like, one configuration line to fix
<OmnipotentEntity> I was waiting on you to get back so I could ask you what you were talking about with the title screen
<kyren_> Oh i fixed that i think
<kyren_> O
<OmnipotentEntity> what's up?
<kyren__> hello again
<OmnipotentEntity> hi there again
<OmnipotentEntity> welcome back
<kyren__> so, okay things that have changed
<kyren__> mostly center around PaneManager
<kyren__> and I have some questions
<kyren__> for example, key dismissing windows
<kyren__> do you think that maybe like
<kyren__> instead of setting key dismissable in the Pane
<kyren__> you should set it key dismissable in the pane manager?
<OmnipotentEntity> that's probably better
<OmnipotentEntity> I think the reason why it was in the pane was so that it didn't become desynced
<kyren_> also, how much policy should there be on each layer
<kyren_> right
<kyren_> so, as far as policy on each layer
<OmnipotentEntity> what do you mean by policy?
<kyren_> each layer is just like.. A layer
<kyren_> well, okay for example
<kyren_> I need to set up the modal layer differently
<kyren_> IF there is anything in the modal layer
<kyren_> THEN only send input to the TOP of the modal layer
<kyren_> and ignore all other windows
<kyren_> that's like.. the modal layer is special
<kyren_> so, what if
<kyren_> by policy, we just made all windows and modal windows key dismissable
<kyren_> then we don't even need a falg
<kyren_> flag
<OmnipotentEntity> well, a quest dialog shouldn't be key dismissable for instance, right?
<kyren_> the only thing I think that even uses key dismissable is like
<OmnipotentEntity> you don't want to accidentally fuck yourself out of a quest
<kyren_> right, I suppose so yeah
<kyren_> right
<kyren_> I forgot about quests
<kyren_> okay, well then the modal layer still has policy tied to it
<OmnipotentEntity> right
<kyren_> for modal windows
<OmnipotentEntity> I can't think of modal windows that you shouldn't be able to key dismiss
<kyren_> why don't we make quests modal windows
<kyren_> and
<kyren_> make it so that modal windows cannot be key dismissed
<OmnipotentEntity> well
<OmnipotentEntity> hmm...
<kyren_> well, no that doesn't work either
<OmnipotentEntity> yeah, because
<kyren_> what about if there's a special layer for windows that cannot be key dismissed
<OmnipotentEntity> if you have your escape window up
<kyren_> right, the escape window doesn't work
<kyren_> what if we split it into 5 layers
<kyren_> first layer hud, cannot be key dismissed
<kyren_> second layer normal windows, can be key dismissed
<kyren_> third layer essential windows, cannot be key dismissed, fourth layer modal can be key dismissed
<kyren_> fifth layer tooltip, cannot be key dismissed
<kyren_> so only normal windows and modal windows can be key dismissed
<kyren_> OR we could have a flag, the thing is
<kyren_> it's kind of redundant
<kyren_> like, HUD windows should NEVER be key dismissable
<kyren_> and tooltips should never or always be key dismissable I can't decide but it will always be the same
<OmnipotentEntity> right
<kyren_> so I could just encode that into the layer
<kyren_> also
<kyren_> like, the quest dialog
<kyren_> should stay on top haha
<kyren_> so, maybe call it StickyWindows?
<OmnipotentEntity> hmm...
<OmnipotentEntity> it seems weird having a modal dialog that's above all windows
<OmnipotentEntity> and then StickyWindows which are also above all windows,
<kyren_> yeah, I suppose
<kyren_> but
<OmnipotentEntity> but not above modals, and there can be several of them instead of just one
<kyren_> I feel like maybe eh
<OmnipotentEntity> it just seems strange is all
<kyren_> what if
<OmnipotentEntity> I'm not saying it's wrong
<OmnipotentEntity> it's just really hard to model
<OmnipotentEntity> like,
<OmnipotentEntity> it seems to resist whatever model you assign to it
<OmnipotentEntity> because there's so many damn exceptions
<OmnipotentEntity> anyway
<OmnipotentEntity> I love the idea of policy
<OmnipotentEntity> and then forcing policy onto the windows
<OmnipotentEntity> because that simplifies this entire problem drastically
<OmnipotentEntity> like
<OmnipotentEntity> key dismissable quest dialogs are not a complete disaster
<OmnipotentEntity> if you can regain the quest dialog somehow
<kyren_> right, eh.. I think I'm going to try this
<kyren_> and see how it looks
<OmnipotentEntity> Roger


Most of this week was spent finishing up a full set of ranged attacks for each of the quadruped head styles, so now Tiy and I have moved on to the next stage: special abilities! We’ve accumulated tons of ideas (including lots of great suggestions from players) for ways that monsters can act to keep combat exciting and strategic. Most of these are still in the design phase, so I’ll explain a little about our ideas so far and the reasoning behind them.

We started by reexamining the special abilities currently in the game. Attacks like Grab, Gust, and Gravity Slam are interesting conceptually, but don’t add much to the experience. They take control away from the player without incentivizing any particular strategy, so they end up just getting in the way. These have all been removed for now. Charge, Pounce and Stomp, on the other hand, we’re polishing up and adding to more monster types. These attacks help the monsters fight in a variety of circumstances (different terrain, ranges, positions relative to the player, etc) and also force the player to move and adapt, adding interest to the combat experience.

As far as new attacks, there are several different kinds which may or may not end up as distinct categories within the code. Some will be like Charge, Pounce and Stomp: offensive abilities that aren’t standard ranged/melee attacks. Others will be reactive, defensive abilities. For example, some monsters may raise a shield to block projectiles for a short duration after being hit with a ranged weapon. Some will retreat to heal when reduced to low health, while others may go berserk and attack in desperation!

In addition to offensive and defensive abilities monsters also need ways to interact with terrain, using it to their advantage and avoiding getting stuck by natural (or player-built) formations. This is going to take some experimentation to get right, so we’ll be testing some things out and seeing how they work in practice. The first and simplest thing to try will be a ‘burrow’ ability that allows a monster to dig their way through intervening blocks to reach a player. More subtle abilities might include monsters digging pits to hide in, building small walls of dirt to block projectiles, or even constructing nests where they can spawn offspring! One big challenge with these sorts of abilities is to avoid eroding planets into hellscapes of craters and tunnels (except for the ones that are meant to be cratered hellscapes!) We also need to be picky about which types of tiles monsters can damage so that a stray enemy doesn’t destroy a player’s carefully-crafted home. Ultimately, I’m confident that we’ll be able to balance these in a way that both allows monsters to interact with the world they live in, and limits the effectiveness of placing tiles as a combat strategy for players.

Hopefully this gives you a bit of a window into our thinking about monster special abilities. Have a great weekend, and check back next week for more progress!