June 17, 2014 in Dev Blog
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”.
June 13, 2014 in News
We’ll have our regularly scheduled Starbound updates tonight as well, but the Wanderlust and Witchmarsh teams are doing exciting things so I thought I’d let you in on those.
YetiTrunk has unleashed their wonderful Wanderlust Adventures debut trailer upon the world! Check out all that 4-player co-opy, character customize-y, action adventure RPG goodness!
Witchmarsh has just over two days left on its Kickstarter! It’s getting really close to its £90k stretch goal, which will unlock The Alchemist as a playable character, as well as 10 more player abilities. Let’s give it that last big push! I’d personally love it if we could unlock the next stretch goal– Freelancer mode. :D
June 13, 2014 in Dev Blog
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> 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
<kyren> I could push and you could help me debug all the problems
<OmnipotentEntity> that's fine
<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
<Tiy> would you mind doing a post today
<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
<kyren> also, I want to push it because I really want your feedback
<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> there pushed, god help you all
<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?
<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_> 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
<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_> 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
<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_> I forgot about quests
<kyren_> okay, well then the modal layer still has policy tied to it
<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_> make it so that modal windows cannot be key dismissed
<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
<kyren_> so I could just encode that into the layer
<kyren_> like, the quest dialog
<kyren_> should stay on top haha
<kyren_> so, maybe call it StickyWindows?
<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
<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> it seems to resist whatever model you assign to it
<OmnipotentEntity> because there's so many damn exceptions
<OmnipotentEntity> I love the idea of policy
<OmnipotentEntity> and then forcing policy onto the windows
<OmnipotentEntity> because that simplifies this entire problem drastically
<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
June 13, 2014 in Dev Blog
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!
June 12, 2014 in Dev Blog
It’s been strange for me to not hear the monsters vocalizing anymore. While it currently feels a little odd, there is far less repetition of sound going on and it’s less obnoxious when there’s multiple monsters together in an area. Removing these vocalizations has drawn attention to the more pressing need for their attacks to have their own samples. This is something I’ve been meaning to do for some time, but now it’s of far greater importance.
In the near future I’ll be gaining functionality that enables me to make sounds play upon the projectile’s creation. This is good because this means I can assign samples based entirely on the type of attack, whether they’re ranged or melee types. For instance, depending on what type of melee attack is being used (bludgeoning, slashing, biting), the monsters will use different projectile and play the appropriate sounds. If a monster is attempting to headbutt you, you’ll hear a fairly general whoosh and a flat bludgeoning sound when they successfully hit. Comparitively monsters that attack with claws, they’ll make more of a “slicing the air” kind of sound and do slashing damage (think the sounds swords make when they hit organic enemies).
The more gargantuan task is going to be finding suitable sounds for all the new ranged attacks that have been added recently. There was a handful to begin with, but now it’s climbed to over 60 different projectile types, and there’ll likely be more to come as Metadept and Tiy continue to add unique attacks for our flying enemies and bipeds. Sometimes finding that perfect sample can be a fairly straightforward affair, and at others it can be mindnumbingly difficult to find one that doesn’t sound horribly out of place. All that said, I’m confident that by the time I’m done, Starbound will sound better than ever.
I’m looking forward to seeing what people think of the new sound arrangement once it’s finished!
June 11, 2014 in Dev Blog
Not a great deal to report today. We’ve largely been working on the same things we’ve been involved in for the last few days. We’ve finished up the remaining quadruped head pieces and their unique attacks (some of which are hilarious, good job metadept). We’re still chugging away at the ship AI UI and how that feeds into the progression system. We’re starting to work on various other monster parts giving unique movement attacks, as well as monsters visually responding a little better to things like being surprised by a hostile enemy.
We now have a new member of the team though, introducing our office puppy:
We’re still figuring out what to call her!
June 10, 2014 in Dev Blog
I’ve been doing a bunch of things lately, mostly fixing a couple of very nasty bugs and assisting on engine side work with monsters as well as implementing the AI interface. I recently fixed a really really nasty bug where our networked animation system positions were being de-synced in position with the logical position, and this required a slight rework of the client side networked animator which pulled all of the client side code outside of the server code, making the system better overall anyway.
I’ve been doing a lot of one off bugfixes for metadept, fixing projectiles and changing the update method for our scripted entities, adding to the lua api. I fixed a nasty nasty network bug which made the server send huge amounts more data than it should, which I need to check on current steam stable. Thanks to Underbalanced for reporting this bug to omni. I actually ran into the bug independently working on the networked animator bug, but that confirms that it is occurring on the steam stable build and needs to be fixed.
I fixed a whole series of universe deadlocking bugs caused by a worker pool class we use not being COMPLETELY TOTALLY impervious to re-entry deadlocks. That was fun.
I spent maybe 3 hours tracking down some particle animation problems, which turned out be a one line fix.
Then comes the AI ui stuff… our UI code is kind of.. special.. at the moment. This has been somewhat in my way as of late getting the AI code working, so in the process of building the AI gui I’ve fixed maybe a zillion UI bugs and hopefully introduced significantly less than that in the process. None of it is particularly interesting, it’s just kinda sucky.
Finally, we’re preparing to restore the build server (it’s nearly done actually) and start doing AUTOMATED SCRIPTED NIGHTLY UPLOADS to steam. These will be AUTOMATED builds that are SCRIPTED and occur NIGHTLY, so huge huge warning signs will be placed around them, they are only for dedicated interested people to track development and experiment, not really for normal play. They could eat your dog, set your house on fire, eat your house, or set your dog on fire, who knows. They also might be broken, so don’t complain.
June 10, 2014 in Dev Blog
I’ve been working on a few nice things for the behind the scenes stuff.
First thing I did was make a few of the admin commands nicer. Banning now can take an optional timeout and unban automatically once the time is done. The cavaets are that the server needs to stay running, because temp bans aren’t stored, yet (perm bans are of course). This is useful for short term bans for someone to cool off, like 10 minutes or a few hours.
Next, I retooled a bunch of the duplicate admin commands to take a playerSpecifier instead. See my player specifiers post on the forums for more detail on how they work.
Then I changed /listcid to simply /list and modified it to also display the player’s UUID and if the player has characters that can’t normally be displayed by our font it will display the UTF escape code for the character instead. So if you have someone named “😀☃” you won’t be able to read their nickname normally but the list command will output them as $3 : \ud83d\ude00\u2603 : $$(uuid goes here).
You can use the unicode escape sequence to address them to any admin command.
Notice that I’m using the \u not the \U unicode escape sequences, which means much of my time this morning was taken up writing an encoder and decoder for UTF surrogate pairs and redoing bits of the parser to handle them better. This will save a lot of keystrokes though, because that sort of huge unicode codepoint is rare.
Next, I stuck a lua script hook into the command processor. Now you can define your own admin commands. There isn’t much to the lua API yet, but that will change as we figure out what you need.
Finally, I changed the format of the Lua callbacks so that Doxygen can parse them (some of them anyway, there’s still a lot to do), then I changed our doxygen settings to make documentation fit for public consumption (remove verbatim_headers and full_source).
You can find public documentation at: http://doc.playstarbound.com.
Currently it’s updated manually whenever I fancy it. But once we get the nightlies system working, I’ll make sure that the script that uploads the nightlies also updates the documentation. Enjoy modders.
June 9, 2014 in Dev Blog
As I’m currently waiting on some new and fairly significant assets for the Outpost, I’m holding off on starting the dungeon for the moment. It doesn’t make much sense to go designing the dungeon only to have to fundamentally re-think it from the ground up based on new ideas that have arisen in our process. So for today I started looking into some of my secondary tasks (believe me, it’s a long list).
Since Kyren implemented a more functional orientation system some time back, there are a great many of our objects that would benefit from an update to this sytem, specifically our beds and chairs.
Why the beds and chairs? While the vast majority are okay, there are a number of these objects that under the old orientation system are prone to having the player appearing misaligned when sitting or sleeping on them. Often the seating/sleeping position would be configured to an ideal spot for one orientation, while sitting awkwardly in the other. It’s a petty grievance, but it’s the kind of thing that breaks immersion and drives perfectionist folks like me up the wall.
One of the other things I’ve been playing around with today concerns our monster sound effects.
For a while now Tiyuri and I have discussed a complete restructure of how the monster sounds operate. While the current monster sounds are functional, many on the team (myself included) feel that the current batch of monster sounds don’t quite mesh with the overall aesthetic we have going with Starbound. I’m currently experimenting with new sound directions, trying to find something that sits right with both me and Tiy, but it’s proving challenging.
Seeking inspiration, we’ve been looking at some of our most beloved games, examining how they approach sound effects for the enemies that populate their worlds. In doing so, we’re hoping to find an approach that works for us. Once I have a direction nailed down, it’s highly likely that the monster sounds you know right now will be removed altogether to make way for a cleaner and (hopefully) more suitable set.
The key thing we’ve taken away from many of the greats (Legend of Zelda, Mario, Rayman Origins) is that a lot of the time the sounds from enemies are usually fairly minimal. Rather than being especially vocal, the tendency is to have sounds associated with their physical actions.
The advantage of this approach would be that it ultimately decreases the number of unique sound effects I’d need to come up with. On the other hand, I’m having quite a bit of difficulty finding an audio aesthetic that doesn’t feel jarringly out of place in the world we’ve built.
I’m confident I’ll get there eventually, but it might take some time. I’m always open to any ideas you folks out there in the community might have, so feel free to shout ‘em out in the comments! What kind of sound design would you like to see on our monsters?