Storm Tanks: HUD Design & Radar
by Tim Dix (Raverix) · 09/01/2010 (1:02 am) · 6 comments
The first HUD gui element I worked on after the crosshairs for the tank controls was the radar. I actually still like the look and feel that I wanted in the old version, but was unable to attain satisfactory. For the new version, I broke out Blender, and actually created and rendered the full 3D version of the radar, and I think the result was worth the effort, for comparison, here's what my old faux 3D photoshop created radar looked like.I really wanted to have that hi-tech gadget look, without being too heavy. I ended up going through about 10 iterations where I progressively trimmed it back and back to the final result you see here. I’d like to go back at some point and add a bit of imperfections, scratches etc, but I had used up all the time I allotted, so decided that this was good enough for now, and I’ll consider retouching it at the polishing stage.
I still need to create crosshairs to give it the feel that I want, but I haven’t come across anything which I really like, and I’m not sure how to tie it into the hi-tech gadget feel I have above. Anyone have any recommendations?
To create the radar, I started with the Radar/Map/Compass Resource and then started modifying. For my game, I’ve got both the tank’s direction, and it’s turret direction to track, so I added two new images to the radar. One shows the orientation of the tank, and the other shows the current field of view. I wanted to improve upon what I had in the old, so with the new one I decided to have the radar support three modes, where one of the three orientations will always be up, and the other two rotate about it. The old version, only had what I've now named "North Up."
- North Up
- Tank Up
- FOV Up
Right now, the field of view is fixed at 90, so it’s not quite right when zoomed in. I’m planning on revisiting this later and instead of rotating an image to point the right direction, I’ll make the view a circle graphic, and then render just the portion of it which corresponds to the current FOV. This will make it always match up when the player zooms in and out. I could in theory just export another image to show just the zoomed in mode, but that feels like a cop out, and wouldn’t support varying FOVs.
Video Demonstration:
Edit: One thing I forgot to mention was that you can switch modes on the fly. I'm not sure if I'm going to hook this into the different camera modes, but I at least I have that option.
About the author
#2
09/01/2010 (2:05 pm)
Very cool. Personally I'd use Tank Up mode, and maybe North Up mode. I found View Up mode difficult to follow. 
#3
09/01/2010 (2:09 pm)
The radar looks great and the modes support the game well. "North Up" and "Track Up" are essential for navigating but nothing beats "View Up" for combat.
#4
Part of the reason why I implemented all three modes was because I didn't know which modes I wanted. Again, I saw validity with all, so I figured I might as well just develop them all, and then let play testing / player preference decide.
I for example, found North Up, and View Up to be my favorites, but regardless of which mode I was in, I got used to it and figuring out orientations came very quickly.
Switching, is simply a matter of HUDRadar.orientation = "tank", so it might be interesting to see how I can just script this into the control / camera code... for example, maybe it switches automatically to Tank Up or North up when you go into tank view? Maybe it should automatically switch to View Up when in barrel mode?
I think these options make it definitely make sense, that even if you don't send .cs with your games, you should prob always send default.bind.cs as a CS, so that end players can really customize their controls.
09/01/2010 (2:25 pm)
@Daniel, Steve, and Patrick - Thanks for your feedback!Part of the reason why I implemented all three modes was because I didn't know which modes I wanted. Again, I saw validity with all, so I figured I might as well just develop them all, and then let play testing / player preference decide.
I for example, found North Up, and View Up to be my favorites, but regardless of which mode I was in, I got used to it and figuring out orientations came very quickly.
Switching, is simply a matter of HUDRadar.orientation = "tank", so it might be interesting to see how I can just script this into the control / camera code... for example, maybe it switches automatically to Tank Up or North up when you go into tank view? Maybe it should automatically switch to View Up when in barrel mode?
I think these options make it definitely make sense, that even if you don't send .cs with your games, you should prob always send default.bind.cs as a CS, so that end players can really customize their controls.
#5
I really don't think you should ship any .cs files with your game, though. Gamers shouldn't have to edit a text file to get the feel they want.
Any options available should be able to be set in-game through the options gui. Just set up a new tab with a drop down box for radar view, default tank view, etc and call it a day.
It's nice watching your progress. I think a tank game suits this engine really well. My only advice is to constantly test new features in multiplayer (if you intend to have it), as I've noticed even the slightest changes can do weird things over the network.
09/01/2010 (3:36 pm)
The radar options are great. The graphics are quite nice as well. I do think it's a bit large and taking up a bit too much screen real estate. I'm sure as you add more elements (like ammo) it will all start to come together quite nicely.I really don't think you should ship any .cs files with your game, though. Gamers shouldn't have to edit a text file to get the feel they want.
Any options available should be able to be set in-game through the options gui. Just set up a new tab with a drop down box for radar view, default tank view, etc and call it a day.
It's nice watching your progress. I think a tank game suits this engine really well. My only advice is to constantly test new features in multiplayer (if you intend to have it), as I've noticed even the slightest changes can do weird things over the network.
#6
As for whether or not to ship the scripts, perhaps I should have been clear. I'm absolutely planning on setting up a GUI for all the options I want to support, but realistically, it's impossible for me to create an options GUI which isn't overly complex, and allows every possible configuration option.
My point about shipping default.bind.cs, is that it allows someone who wants to go above and beyond to mod their controls. Other games have shipped in this way, and the tech savvy among them have created some mods. I'm reminded of World of Warcraft, where despite having a completely adequate GUI, almost no serious player uses it because there are a whole slew of GUI mods that tailor themselves to different play styles.
So, basically, no matter how much time I spend trying to come up with every combination of options and interfaces, if I ALSO ship the default.bind.cs, I'm making it just a bit easier for someone to mod if they want to.
I'm planning on making this game (like Legions, tribes, tribes2) multiplayer only. Single player campaign will only be made 1) after release, and 2) if I feel like it. As for weird things over the network... yeah, that one has bit me more than a few times. It does get easier though, you just need to always remember "Am I on the client, or server" and make sure you're sending enough information to keep them in sync.
Still, I had a problem just the other day where I thought for sure I was on the client, and I wasn't, so my changes were only half taking effect. That'll actually be the topic of my next blog. Modifying ShapeBaseImages for my needs.
Once again, thanks for the feedback J.P.
09/01/2010 (4:14 pm)
The radar is definitely too big, I made it much larger for the sake of the video. Or rather, I made it stay the same size it would be at 1600x900, and dropped my resolution to 640x480 for the video.As for whether or not to ship the scripts, perhaps I should have been clear. I'm absolutely planning on setting up a GUI for all the options I want to support, but realistically, it's impossible for me to create an options GUI which isn't overly complex, and allows every possible configuration option.
My point about shipping default.bind.cs, is that it allows someone who wants to go above and beyond to mod their controls. Other games have shipped in this way, and the tech savvy among them have created some mods. I'm reminded of World of Warcraft, where despite having a completely adequate GUI, almost no serious player uses it because there are a whole slew of GUI mods that tailor themselves to different play styles.
So, basically, no matter how much time I spend trying to come up with every combination of options and interfaces, if I ALSO ship the default.bind.cs, I'm making it just a bit easier for someone to mod if they want to.
I'm planning on making this game (like Legions, tribes, tribes2) multiplayer only. Single player campaign will only be made 1) after release, and 2) if I feel like it. As for weird things over the network... yeah, that one has bit me more than a few times. It does get easier though, you just need to always remember "Am I on the client, or server" and make sure you're sending enough information to keep them in sync.
Still, I had a problem just the other day where I thought for sure I was on the client, and I wasn't, so my changes were only half taking effect. That'll actually be the topic of my next blog. Modifying ShapeBaseImages for my needs.
Once again, thanks for the feedback J.P.
Torque Owner D Fasel
Game 3D