Welcome back followers of the fearsome!
This week we’ll be taking a quick look at our home base in Viking Squad! It’s gone through quite a few changes but as we get closer to completion we wanted to really nail it down. The main hub initially only had a few options that our players could do but we kept adding more and more elements that needed to be represented with characters, doors and other elements. So that means a bunch more artwork which is great!
Backgrounds have always been a weak point in my artwork but the sheer amount of artwork in Viking Squad has really kicked me around and forced me to get better quickly. Above you can see how I approached the reworking of the home village. Initially I was working on a smaller canvas and building things as they came up. I was constantly getting frustrated because I just couldn’t get anything to feel right. So I just took a whole bunch of screenshots and strung them together so I could approach the artwork on a bigger scale and I like to think that it worked out a lot better! It’s really awesome to know that you’ll constantly be getting better all the time.
Here you can see the first half of our Viking’s home base. Here our players can outfit their Vikings with the super cool gear that they’ve discovered, buff up with our prairie-born trainer, and test out their new item combinations on the attack dummy! Below is a quick detail on the locations of these elements. Making the town bigger let us separate everything a little more so it was easier to take in as a newer player. It also made the main area feel more grand which is something I’ve always struggled to be able to do as an artist.
Also our very talented team of Audio-Monsters is in Minneapolis sponsoring and donating their time and skills for the incredible Games Done Quick event! All the proceeds are going to Doctors without Borders and there is some AMAZING gaming going on so be sure to check it out! And if you’re lucky you’ll be able to catch a peek at those handsome dudes at Power Up Audio while they make the event sound smooth and amazing!
And don’t forget that today we will be dev-streaming at 4pm pst! be sure to drop by and say hey to the team, ask questions, and be part of the conversation while we craft our brawler in front of your very eyes!
So that’s it for this week! We’ll be showing you guys what’s up with our super awesome town in future dev-blogs hope you’ve liked this quick look at our progress and until next time, keep those home bases looking awesome!
Last weekend Caley and myself took part in the coolest game-jam we’ve ever attended: The roomscale Vive VR jam! Valve and HTC came by Vancouver and set up 3 complete VR rooms of about 12’x10′. There were about 100 attendees making several VR games, and everybody shared the rooms for testing during the two days of the jam.
My personal goal for the jam wasn’t to make an actual game though. I decided I want to get my engine up and running with the Vive! Even though Scrap Metal was the last real 3d game we made, and Shellrazer and Viking Squad are mostly 2d, the guts of the engine are still all in 3d. Of the about 100 people at the jam, there were only 3 people working on their own tech, the rest were all using Unity and Unreal. As a programmer this makes me sad.
Getting the engine converted to be able to render with the Vive was actually very straightforward. The VR library that steam provides is free to download, and it even works with the Oculus DK2! I was able to test small things using just my laptop and the DK2, and when I created a build to test on the Vive setup, it worked straight-away! I had a few problems with the transform matrix coming from the controllers (different coordinate spaces), but once that was solved it was all working!
Working with the Vive, we learned a few things very quickly. First off, you have to run at 90 frames per second. Anything lower than that, and you will start feeling sick very quickly. Most console games nowadays run at 1920×1080, either at 60, or sometimes at 30 fps. For 60fps, you have about 16 milliseconds per frame to fill 2,073,600 pixels. The Vive has two screens of 1200×1080, and each needs to run at 90 fps, meaning you have 11 milliseconds to fill 2,592,000 pixels. To really put that in perspective, for a 1080p game at 60fps you need to fill just over 124 million pixels per second, for a Vive game at 90fps that number is 233 million(!). So, you need to have some serious consideration for what you’re rendering, and how it’s being rendered!
The second thing I learned was that the controllers are a HUGE part of the VR experience. I drove down to Valve to test their prototype VR setup about half a year ago, and at the time they were only showing the headset. That experience blew my mind, because I could feel my brain being conflicted about whether this was real or not. Of course I could reason ‘this is not real, I am just in a room with a headset on’, but at the same time every nerve in my body was resisting when I was asked to step off a virtual ledge. This weekend was the first time I got to try out the controllers, and it blew my mind all over again. When you put the headset on, you can see the controllers in VR on the floor below you. It’s just so natural to bend your knees and grab them and not even think about it twice. That is amazing! And now suddenly you have all this interactivity in the scene. You can grab things, you can throw things, etc. I think the controllers are an essential part of making VR actually work properly. Selling just the headset won’t cut it (looking at you Oculus!)
Alright, so what did we end up making? Well, I just made a little toy where you can play around with our particle systems. But in my own engine! :) Each controller has the same 5 different particle effects you can rotate through by pressing the touch-pad on the controller. All there is to do is to play around with the particles! Somehow it’s pretty fun and satisfying though. :) Here’s a photo of Colin Northway of Northway Games playing around with the particle systems:
I forgot to record the actual output to the Vive in a video, and since I don’t have a Vive here, I modified the code a bit to place a few controllers and move them around in circles. So this is an example of what he might have seen, except then in 3D and using the actual vive controllers. :)
Caley used Unity to make a super sweet VR Tennis game in Unity where a ball-launcher shoots balls at you, and you try to hit them with a racket and try to bounce them back over the net to score a point. He also forgot to fraps it. Maybe he’ll do another blog post in the future if we can somehow record some footage on a real Vive at some point.
In conclusion, it was a super fun weekend, and I cannot wait to get my hands on an actual Vive to experiment with for our future projects. Thanks again to Valve, HTC, Radial Games, Cloudhead games, Nvidia, Unity and Unreal for putting this on!
Hi everyone, welcome to another Wednesday post! This is the magic 180!!
We’re busy working away on Viking Squad preparing for some upcoming milestones which we will announce shortly.
Lately our tasks consist of adding areas of interest to the levels. These are unique scenes or events that help the player get their bearing as they travel through the game. We can use these scenes to foretell something in gameplay, help the player remember where they found a certain item, or tell a small story that may give people a chuckle. Below are captures from various places in the game. Can you tell what may be coming next for our goggled tour guide?
The grumpy bartender.
Who or what could have put this here?
This doesn’t seem to be your average door…
This is one of the most exciting times when developing games. You get to let your imagination run with fun scenarios that fit in to already established locations.
Also with Jesse out of town the weekly dev cast is on hold. The next cast will be on July 22nd.
This week Jesse is on a sweet trip to Japan with our good friend Ryan Clark of Brace Yourself Games, so I’ll take over and do another Tech blog. This one is about the Texture Tool I’ve build a while ago. This tool fills a very important role in our pipe line, but because it’s all behind-the-scenes it doesn’t really get much attention. This is its time to shine!
First a bit of history so the requirements of this tool become clear. When I first started building my engine, we were making N+, a game that doesn’t have a lot of textures, so no special care was taken to manage the textures in an optimal way. Then, when we started building Scrap Metal, and later Shellrazer, the number of textures increased drastically. The need for an extra step in our pipeline became clear. We needed a tool that could convert all of the source art to a format that is more optimized for the final game, while giving us the control to convert/change/compress the textures as we saw fit.
The first step to optimize the source data is to create texture atlases. The thing with many separate textures is that each of them needs a separate draw-call, which in turn means that you get draw-call bound very quickly. A common way to fix this issue is to combine multiple textures into texture-atlases. This way you can batch all the calls that use the same texture atlas into one draw call, and therefore drastically reduce the number of calls needed to draw your frame, generally resulting in a faster frame-rate. Here’s a screenshot of our texture tool showing how it combined a bunch of textures into a texture atlas:
How do you decide which textures to combine into an atlas? If you just randomly start combining textures, there’s still a chance of doing lots of draw-calls if you require a texture that’s in atlas A, and then a texture that is in atlas B, then another texture from atlas A, and so on. So you will want to combine textures into one atlas if they are likely to be drawn in order. In our case, our puppets use many separate textures, but they will all be rendered in one go, so they could easily be combined. Luckily, Jesse creates a new directory for each character he creates, so the first filter we added is to group textures by the sub-directory they are located in.
There are also textures that generally belong together, such as textures that are used only in the world map. So we added a way to set the category of a directory (recursively), or an individual file. This allows us to easily combine all ‘user interface’ textures into the same texture atlas, so that the user interface can be drawn in a single draw call.
The last filter we need is of course how you want the texture to be compressed. Some textures require RGBA8888 (such as visual effects that do multiple layers of overdraw), and some are fine to be compressed using DXTC5. The entire atlas texture is compressed, so all the textures within that atlas require the same texture compression. The required compression is again set on a directory basis, or on an individual file basis.
Another wish for this tool was a way to easily re-size textures manually. Some textures are used in ways where cutting their size in half isn’t noticeable in the final result. For example textures that were blurred can easily be reduced to 50% or even 25% of their original size. Keep in mind that all of this is happening while building the game package, so none of the original art is resized or altered. The resize factor can be set manually per texture.
Because some of the art we use is actually drawn on a higher resolution that it will ever be shown at in the game, I came up with a way to try and reduce all textures to exactly the size they require on screen. The way this works is that each entity is drawn at the size they appear in the game, and the size at which the textures were rendered is recorded as this is going on. It keeps the average size each texture was rendered at, as well as the standard deviation and min/max values. In the end, the recorded sizes, as well as a recommended resize factor is exported. These values are visible in the image above: The bow image is resized to 57.43% of its original size.
When I checked the game with NVidia’s awesome NSight, you can see that it draws large chunks of level data in single draw calls:
The lanes are drawn using multiple separate textures, but because they were combined in a texture atlas, we were able to draw it in one draw call.
Same goes for the puppet of the shield guy. One draw call is all it needs to draw the entire puppet, which consists out of 30 or so individual textures.
All in all, this tool saves us large amounts of texture space, and it really optimizes the way we draw our frames.
Oh and as a reminder, because Jesse’s in Japan, we won’t do a dev-stream today. We did one yesterday though! Check it out here and here.
Welcome back followers of the fearsome! This week we are out of the office celebrating Canada Day! Hope your guys’ week has been awesome and we’ll be catching you guys up with us next week on all that’s been happening here at Slick! In honor of our non-offensive country we have drawn it a viking moose and hockey-playing beaver braving the icy waters with a billowing and patriotic sail! Ford onward into victory O’ Canada!
And just to let you guys know, we’ll be skipping this week’s Dev-Stream but be sure to drop by next week where we’ll have everyone down and catch them up on the cool new developments of Viking Squad. We’ve been having a great time opening our processes to the community and fellow developers and it’s going to keep on happening in the future so be sure to keep showing up! And If you are super desperate for some Slick-Style Dev-Stream-age, you can always drop by our Youtube and watch old episodes!
So have an amazing holiday and be sure not to imbibe too much Fishbier during the celebrations or you’ll end up like our dozy friend down there! And until next time, keep those halberds honed and those helmets horned!
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 […]