June 13th – Specialization

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 12th – Sound it out!

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 11th + Puppies

June 11, 2014 in Dev Blog

Hey guys,

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:

rosie

 

We’re still figuring out what to call her!

 

 

Jun 10 things

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, Documentation, UTF Surrogate Pairs, and Lua Admin Commands

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 9th: Chairs, Beds & Monsters

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?

9th June Progress

June 9, 2014 in News

Hi there,

Today we mostly continued on the tasks we’ve been talking about lately. The AI interface is coming together nicely, work on the outposts is ongoing and we’ve added a whole ton more monster attacks. Here are just a couple. We’re aiming to make sure every unique monster piece has it’s own attacks and affects the monsters behaviour differently.

 

boulder

bubble

snot

6 June, admin commands

June 6, 2014 in News

So in our internal build we’ve just implemented admin login/passwords, banning, kicking and some other obvious bits and pieces. Here is a non exhaustive list of current implemented commands available to server admins. We’re interested in hearing what you think might be missing from this list.

  • listcid lists all users and their associated client IDs
  • kickcid <clientID> [reason] kicks a player based on their CID
  • kick <username> [reason] kicks a player based on username
  • ban <username> [reason] kicks and IP bans a player based on their username
  • bancid <clientID> [reason] kicks and IP bans a player based on their clientID
  • softban <username> [reason] kicks and UUID bans a specific players character based on their username
  • softbancid <clientID> [reason] kicks and UUID bans a specific players character based on their client ID
  • globalalert <message> Issues a global alert to all players in large text
  • spawnitem <itemID> [count] [item param] Spawns specified item
  • spawnsword <level> [color] [kind] Spawns a randomly generated melee weapon
  • spawngun <level> [kind] Spawns a randomly generated ranged weapon
  • spawnshield <level> [kind] Spawns a randomly generated shield
  • spawnliquid [liquidID] [quantity] Spawns a liquid at mouse cursor
  • spawnmonster <type> [level] [param] Spawns a monster at mouse cursor
  • spawnnpc <species> [type] [level] Spawns an NPC at mouse cursor
  • timewarp <amount> Changes the current planet’s clock
  • togglelayer <layernumber> Toggles the visibility of specified draw layer
  • fullbrightDisables the lighting engine
  • setgravity <amount> Sets your local gravity
  • resetgravity Resets your gravity
  • debug Enables debug mode
  • togglelogmap Displays performance info (requires debug mode)
  • boxes Displays collisions (requires debug mode)
  • itemID Displays information on given item
  • reload Reloads local assets
  • serverreload Reloads remote assets

June 5th – Admin logins

June 5, 2014 in Dev Blog

Today, I finally slightly retooled the admin system to allow for admin logins on servers, and also admin logins for local client, which means that all of the commands that have previously been disabled can now be enabled if you type in /ruinthefun (local only). This will be ridiculously helpful for modders and such. I think we might look into segregating characters where admin has been used and where it hasn’t been in the future into different universe directories.

Also, I fixed a few UI and API bugs. The find random button was allowing you to leave the system when you technically could not leave the system.

I spend a good chunk of my day doing an interview. We’ve been interviewing various people for the programming position on the Pirate game.

5th of June: GeorgeV BlogV

June 5, 2014 in Dev Blog

Here’s a little something that you might find around outposts.  It’s just one example of a store you’ll find in Starbound.  This one is a re-purposed shipping container made into a TerramarT, a chain store where you can buy a variety of gardening supplies.

TerramarT

TerramarT

Short message as always. Until next time…

-GeorgeV

spiele