Dev Blog

Dev-Blog 64: Exotic space action!

05/29/2013

devblog_header02

Welcome back followers of the fearsome!

    We’ve been hard at work bringing the cosmic conflict to you! This week we’ll be talking about some of the weapons we’ve been brainstorming up and some light mechanics we are hoping to get in there. Here’s a few of those ideas so brace yourself okay?

    Exotic Weaponry:

Sledge Hammers: We wanted to really bring physical punishment into space combat so decided that big hammers and fists and spiked balls would be the ticket. When we first pictured weapons like these we thought about how great it would be if they were physics heavy and would knock enemy ships away as well as apart.

Sonic Cannons:  We were playing around with the idea of different shapes of damage. Sonic cannons would have a wider area of influence and could shake apart ships with a long blast of sonic energy. 

Rico-Shot: Kind of like a pinball gun that would bounce around close enemies and deal out the damage. Players would get the most out of this weapon when it was fired at a large group of badguys.

Starstormer: Starstormers fire out an area-of-effect storm that damages all enemies in the cloud. activation duration could determine how large the cloud is. players would need to be careful not to fly into the storm and get blown up.

starrazer_reduxDOC03

———-

Snatchers!

    We also started playing around with enemy types that would behave differently towards the player. We thought up some mean guys called Snatchers! After you’ve hooked together a decent warship, these jerks are going to fly right up to your ship, munch off some parts, then make a getaway!  Once they get that juicy laser cannon or whatever, they’ll lead you towards their mother ship or something equally dangerous. Sure you could just let the Snatcher escape with his prize but you are super angry! Go blow some holes in that terrible thing!

    Another thing We want to make sure is that we have just as much monsters in space as spaceships. It’ll be awesome to tear off a slime launcher off of a space-bug and start using it. This will also help us get our space nice and colorful.

starrazer_reduxDOC04

 

———-

    So another week rockets by here at Slick! Be sure to join us next week for some more crazy ideas and tech! Nick is hard at work getting the game running in C++ so we can get people hooking some weapons and mastering space combat right away!

-Jesse

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste SlickEntertainment: @slickentinc

Posted by: Under: Slick Entertainment,Star Razer Comments: 2

Dev-Blog 63: Weapons in Space!

05/22/2013

devblog_header02

Welcome back followers of the fearsome!

After some shifting around we are back into the groove of rapid prototyping! It’s been refreshing having something as clear to work on as our space title and we’ve been having a blast drumming up ideas for an exciting space shooter.

This week we have some basic weapon ideas for you! In our Star-Razer Redux we want big bosses and tons of cool space weapons so to start here’s four basic ones:

1: The Shield Generator:

    We want the shields to be quite active and reliant on the player’s timing and dexterity to be most effective. Our idea is to have the module generate a large blue circle that shrinks back down into the module. While enveloped with the circle (other shield configurations could have different shapes), that part of your ship takes no damage! Perfect for protecting your jarred space-brain!

2. Laser Cannon:

    Classic cosmic combat requires us to hack in a serviceable laser weapon. Our idea with these guys is that you can hold them down to deal more damage but they can overheat very easily. When laser cannons overheat they’ll explode right off your ship! Other laser configurations could have different firing patterns or damage types.

3. Missiles:

    Big damage but limited usage, basic missiles will pack a punch and track into your enemies but will disintegrate off your ship after the last rocket is fired. We want the player to be constantly losing modules and needing to re-equip themselves frantically. By limiting the amount of shots missile pods have we can hopefully adjust the pace of the enemy waves.  

4. Armor Plating:

    Sometimes you just need to be able to take a bigger beating. We are hoping something like armor plating could be used to protect more fragile and rare weapon modules. Once their damage capacity has been met they will explode off of your ship. They could very well be to passive for our game but it never hurts to write/draw down some ideas.

starrazer_reduxDOC02

———-

    So there’s a few ideas for our basic test modules. We want there to be a lot of different weapons with different behaviors that reflect the race you’ll be tangling with. Part of the fun we want to happen in our space game is chaotic combinations and synergies with all the salvageable weapons you run into. The ideas are all sounding great in theory and it’s a really fun field to brainstorm in.

    Next week we’ll have a few more exotic ideas for interacting with your enemies so until them keep those laser cannons searing holes through your foes!

 

-Jesse

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste SlickEntertainment: @slickentinc

Posted by: Under: Art Work,Star Razer Comments: 2

Dev-Blog 62: Star Razer Redux

05/15/2013

devblog_header02

Welcome back followers of the fearsome!

And now for something completely different. What?! Another change? Yes! That’s the beauty of being an indie developer; we can work on whatever we want! :) In any case, we’ve been working on this procedural generation stuff so much lately that we feel the need to let it settle and crystallize a bit before we can make up our minds about what the next most important feature will be. It’s not done and over with, it’s just that we didn’t feel like working on it this past week.

This week we decided to return to the idea of Star Razer. The awesome Chris Hadfield just returned from space, so it may be that we were inspired by his awesomeness. Since the last time we touched Star Razer we’ve had a number of cool ideas on how to change and improve the game. We’re going to take out the strategy elements out because they weren’t really working for us. Also, we’re going to take the procedural tunnel-like levels out as well. They generated barriers causing the movement of your ships to become an annoyance rather than fun.

We’re going to treat working on this game almost like a mini game jam: Cram the features into the game very quickly and see if they work. The idea we’re pursuing is actually fairly similar to Shellrazer.  The difference being that you constantly collect new guns and ball them together into a giant katamari ball, and of course that it’s all in SPACE! So we expect it to be deliciously chaotic, and hopefully not too confusing! We’ll get back to you next week on whether it actually worked the way we envisioned it.

For now, here’s our entire game design doc:

starrazer_reduxDOC01_HR

And yes, we hate game design docs. We prefer visual design cartoons like the one above. It does help to have the almighty Drawbarian around to whip up these awesome little drawings.

Alright, that’s it for this week. Keep those starcannons blasting!

Nick

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste SlickEntertainment: @slickentinc

Posted by: Under: Star Razer Comments: Comments Off on Dev-Blog 62: Star Razer Redux

Dev-Blog 61: New Desk Action!

05/08/2013

devblog_header05

Welcome back followers of the fearsome!

Nick’s gotten back from his awesome Memphis trip, so there’s not too much news on the development side of things. However, we hired the amazing Creative Shift Studio to revamp our offices a bit, and last week we received got our new super cool Human Scale desks and monitor arms! These bad boys are height-adjustable and can take us from a sitting to a standing position in mere seconds! Yay for our spines! 

new_desks01

We took the opportunity to clean out the office as well, and now there’s room for so many activities!

Here’s a before and after pic of Jesse! Notice the horrible posture while sitting, but the amazing posture while working standing up.

desk photo

Alright, next week there will be more ‘DEV” in the Dev-Blog, we promise! Once we’re sick of adjusting the height of our desks every 5 minutes, we’ll probably get some actual work done. :)

Till next week! Keep those turtle cannons blasting!

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste SlickEntertainment: @slickentinc

 

Posted by: Under: Slick Entertainment Comments: 2

Dev-Blog 60: Intermission!

05/01/2013

devblog_header01

Welcome back, followers of the fearsome!

This week is a bit of a dev-intermission. We don’t have an intermission banner, so I just put the dev-blog of the beast banner at the top. I’m currently in Memphis visiting my sister who does amazing research work at St Jude Children’s Research Hospital. So I’ve been busy catching up with her, and seeing the sights around Memphis. I visited Graceland, Sun Studios, the Gibson factory, and lots more. It’s a very neat place! Music is everywhere.

On the week-days I’m trying to get some work done, though. As most of you probably know, I usually write everything in C# first, and then convert the code to C++ once I’ve iterated on it enough to be stable. Over the last half year we’ve been making a bunch of prototypes that required a few changes in the render engine, but the changes were only made on the C# side. So this week I am trying to catch up on all the changes I’ve made in the C# version of the render engine, and putting them into the C++ engine. I guess this is the part that most people see as the main disadvantage of my method of C#–>C++, maintaining both sides at the same time. With proper SVN logs it’s not too hard though. I just look up when the last change was in the C++ engine code, and then grab all the changes from the C# branch until now. I usually remember exactly what changed, so even just seeing the filenames is often enough to remember what needed to be changed, but of course I can always see the actual changes in the files as well. This process takes me only a few days if there were lots of changes, so usually the time I saved iterating at break-neck speeds in C# vastly makes up for this.

There weren’t too many changes. I changed my shaders from .FX (directX) files to generic XML files that can hold the OpenGL shader code, as well as the direct X shader code if required. I’ve taken anything DirectX out of my engine though, it’s all OpenGL at the moment (as pretty much all platforms support OpenGL), so currently my XML shaders only support OpenGL. The XML files get converted to ‘final’ binary shader files in the build process, which allow for fast loading in the C++ engine.

Another thing I changed is the full screen post effects. I’ve streamlined the code so that it’s easier to turn parts on and off to accomodate for slower devices. The post effects we’re doing aren’t really that complex, there’s a screen distortion pass (can be used to create shimmers above fire, blast waves for explosions, etc), a tinting pass (can be used to alter the hue of the screen, alter the saturation, brightness and contrast), and a stencil pass (used for the line of sight system in the space game we were working on, and might return to at some point). I used to have a bunch of extra passes like edge detection and smoothing, but I’ve taken out this code for now as it unnecessarily complicates things. I can always put it back in if needed.

The last thing I changed was the sound system. When we were using XNA for our tools, we were pretty much required to use XACT as the sound engine. So for the C++ sound engine I built a converter that could read the XACT file format, convert it to our own sound data and play that in our C++ sound engine which was based on OpenAL. Now that I’ve converted all our C# tools to use OpenTK (a mix of OpenGL, OpenAL and OpenCL), we no longer have the dependency on XACT, so I spent some time to implement all the sound curves, random cues, etc in our own editor. Below is a screenshot.

Sound Editor

As you can see, we have pretty basic controls for sound cues: Volume, Pitch (as well as variations for both), polyphony, attenuation, as well as random samples, multiple tracks, and a ‘strength’ dependency for volume, and pitch (which is off-screen at the bottom). This is something we set from the code, so when a sample is played, a strength between 0 and 1 always needs to be passed. This allows for nicely scaled impact sounds depending on the severity of the impact, for example. We also used this for the engine sounds in Scrap Metal, where 0 was 0 rmp, and 1 was the max rpm of the motor.

Alright, that’s it for this week. Like I said before, not too many changes, but I hope this was useful to somebody out there.

Keep those turtle cannons blazing!

– Nick

Follow us on twitter: Nick: @nickwaanders Jesse: @jouste SlickEntertainment: @slickentinc 

 

Posted by: Under: Slick Entertainment Comments: 1

Follow us!

titlebutton_twitter titlebutton_facebook titlebutton_youtube titlebutton_twitch titlebutton_spreadshirt

Join our mailing list!

/ /

Dev Blog

January 20 2017

I almost can’t believe it: Slick Entertainment is a decade old! In the last 10 years we’ve made a bunch of great games, and I am super proud of what we’ve achieved with our small team: 4 fun games, custom C++ engine on 6 different platforms, 3 games feature online multiplayer, all hand-drawn art for […]