Take a look at the video of Dragon Age on the left. More specifically take a look at the Mini-map in the top right hand corner when the camera pans around a character (this happens most after the 45 second mark).
You'll notice that the highlighted field of view changes to reflect where the camera is pointing, but the map itself stays fixed with up as north.
Now take a look at this video of Grand Theft Auto 4 on the right. You'll notice there is no marker indicating where the camera is currently facing, but instead the map itself rotates so that up is forward.
This difference in UI functionality is probably more down to the fact that Dragon Age was developed primarily as a PC game (as opposed to say, Mass Effect) and as such has quite a few similarities with the real time strategy genre (you'll notice in the video above - if you watch it all the way through - that the player pauses to order his troops around the battlefield).
Usually in an RTS game, the mini-map will display up as north, and overlay a marker with the camera's orientation and position.
In the version of the game for 360, the game has been retrofitted to work on a control pad, and for the most part it works fine, but this change means it's closer again to Mass Effect than your typical RTS, played predominately from the 3rd person perspective of your character.
What this means for the mini-map at least is that you'll look on the map for the exit to the room you're currently occupying, see that it is on your left and then get momentarily stumped by the lack of door in the west wall. You then of course realise that it wasn't left but east.
You'll notice for instance, that any good SatNav will display driving instructions in a manner relative to the driver - before Google Navigation, I was stuck with Google Maps, which is a great program, but as the name would imply it is as useful as giving a driver an A-Z with a route drawn out on it's pages. Driving south for instance means that a turn to the west is actually to the right, which is (generally speaking) the opposite of what you expect, convention placing the west to the left.
So, in summary, relativity is king.
Wednesday, 4 August 2010
Relatively directional
Labels:
360,
comparison,
dragon age,
gta4,
hud,
mini-map,
relative,
relativity,
rts
Friday, 30 July 2010
Zoom and the RTS
| Source: Wikipedia |
I'm talking about the kind of zoom that allows you to start in the thick of the action, camera on the ground, and with a scroll of the mouse wheel you're transported up an away until you can see the entire map at once.
Then, with a second spin of the mouse wheel, you're sent to a different part of the battlefield, giving orders to your support troops or a secondary base.
In fact, this method of navigating the map becomes second nature incredibly quickly, that the more traditional methods of moving the camera about the place (scrolling when the cursor reaches the edge of the map, arrow keys, bookmark hotkeys) are quickly forgotten.
Yet, despite this, most RTS games still conform to the old methods, a mini-map in the corner, a camera that's relatively fixed in position, the only zoom available being one that lowers the camera slightly and alters the angle.
Supreme commander, in an act of brazen showing off, allows you to turn on a mini-map (which is disabled by default) which is actually a second view port identical to the main one you play the game through, so if you want you can even zoom in to ground level with the mini-map. Of course, this kind of functionality isn't without performance costs, which is why it's disabled by default. A mini-map is also relatively superfluous when you're used to zooming out to see what's going on at a global scale.
I sincerely hope that this becomes a standard "can not do without" feature for RTS games, as I find trying to do without in a game of Company of Heroes (which is a very good game) exacerbating at times - so cut off, do I feel, from the big picture, without my zoom.
Labels:
rts,
supreme commander,
zoom
Thursday, 29 July 2010
Jucey
I discovered Juce via the rather handy list on Wikipedia. It's actually really easy to get started with and provides lots of documentation for the burgeoning front end developer. And like any decent GUI toolkit it's cross compatible on Windows, Linux and Mac (and even iPhone).
And that's why I'm talking about it today. Where most GUI toolkits seek to wrap the native functionality of the platform or at least emulate it in some way, Juce has it's own look and feel (which is actually quite similar to OS X) which it maintains across all platforms.
This has the end result that (for the most part at least) an application developed with Juce will look the same no matter if it was run on Windows or Linux or OS X. This also means it won't blend in with your standard window decorations.
I'm in 2 minds about whether this is a good idea or not. On the one hand, variety is what keeps things new and interesting, and if you can pull it off well, like Google Chrome or Steam, you can get away with it. There's also the idea that if you have to use the program in an unfamiliar OS you won't succumb to culture shock doing so.
But on the other hand, consistency (across your platform of choice) with window decorations makes new programs easier to figure out and understand, and can also make them feel a lot more polished and professional. I've downloaded many applications from Sourceforge that are perfectly good at what they do, but because they've used a GUI toolkit that draws the widgets differently from the native application, it can stick out like a sore thumb. Take BoncEnc - it's a fantastic program that I use to rip my CDs for playing on my MP3 player, but it doesn't invoke confidence to look at. The strangely thin menu buttons (and drop down items), and the title bar with it's minutiae minimise/maximise/close buttons - it just feels so out of date.
Another thing that Juce does is adopt the OS X traffic light system for the close/minimise/maximise buttons. Unfortunately (in Windows at least, and probably Linux too) to stay consistent with the standard order of these buttons the colour order is amber->green->red. Also, in my personal opinion, I don't really consider "maximise window" to be the opposite of "close window". For me, it would be "Run", but that's not really applicable in this context. In the standard Windows XP theme, the close button is indeed red, but the other two are just blue, the same as the rest of the window decorations.
And that's why I'm talking about it today. Where most GUI toolkits seek to wrap the native functionality of the platform or at least emulate it in some way, Juce has it's own look and feel (which is actually quite similar to OS X) which it maintains across all platforms.
This has the end result that (for the most part at least) an application developed with Juce will look the same no matter if it was run on Windows or Linux or OS X. This also means it won't blend in with your standard window decorations.
I'm in 2 minds about whether this is a good idea or not. On the one hand, variety is what keeps things new and interesting, and if you can pull it off well, like Google Chrome or Steam, you can get away with it. There's also the idea that if you have to use the program in an unfamiliar OS you won't succumb to culture shock doing so.
But on the other hand, consistency (across your platform of choice) with window decorations makes new programs easier to figure out and understand, and can also make them feel a lot more polished and professional. I've downloaded many applications from Sourceforge that are perfectly good at what they do, but because they've used a GUI toolkit that draws the widgets differently from the native application, it can stick out like a sore thumb. Take BoncEnc - it's a fantastic program that I use to rip my CDs for playing on my MP3 player, but it doesn't invoke confidence to look at. The strangely thin menu buttons (and drop down items), and the title bar with it's minutiae minimise/maximise/close buttons - it just feels so out of date.
Another thing that Juce does is adopt the OS X traffic light system for the close/minimise/maximise buttons. Unfortunately (in Windows at least, and probably Linux too) to stay consistent with the standard order of these buttons the colour order is amber->green->red. Also, in my personal opinion, I don't really consider "maximise window" to be the opposite of "close window". For me, it would be "Run", but that's not really applicable in this context. In the standard Windows XP theme, the close button is indeed red, but the other two are just blue, the same as the rest of the window decorations.
Sunday, 25 July 2010
Rock Band 2 vs Guitar Hero 4
For the most part I consider Rock Band to be the superior franchise. This is clearly evidenced by the sheer number of hours my friends and I have logged playing Rock Band over Guitar Hero. I think there are several reasons for this, the most obvious being the hugantic™ amount of tracks available to buy on the Rock Band store (A large proportion of which we have in fact purchased).
But the other reasons are a lot more subtle. Take a look at these two screenshots, on the left, Rock Band, and on the right, Guitar Hero:
But the other reasons are a lot more subtle. Take a look at these two screenshots, on the left, Rock Band, and on the right, Guitar Hero:
In Rock Band, you'll notice at the bottom of each player's respective highway is that player's current score multiplier and the overdrive power bar. This is even true of the singer whose highway is at the top of the screen - you'll notice the score multiplier disc is in line with the target line, which is the place on the screen where each player's eyesight will be focused for the majority of the song.
By comparison, the Guitar Hero score multiplier is displayed up and to the side of each highway, which, whilst not a particularly large distance, is still enough that you're not really looking at the target line any more. The star power metre (the Guitar Hero equivalent to Rock Band's "Overdrive") is well out of the way in the top left corner. Of course, Guitar Hero's star power is combined for all players, which explains why it's as it is, but I think there's an argument for duplicating the information on each of the three highways so that player's don't have to look away from the target line to know how they're doing in that regard.
Rock band also has the "crowd metre" on the left, which shows the players how well they're performing or how close they are to failing a song. All player's are presented on a vertical bar as simple, clear icons which are easy to separate. Guitar Hero has combined this aspect of the HUD with the star power metre. You've got glowing yellow icons for each of the players on 4 separate power bars which has the end result of creating a very murky looking interface item that takes more than a brief moment to see how well you're doing.
I think the fact that each player has their own bar means that, if you think about it, a player has to find their icon amongst the 4, and then look at the bar above (which is 2 steps). Whereas in Rock Band, once a player has found their icon, they know how well they're doing as it's the icon itself that moves, and the bar is very clearly visible in the periphery.
It may sound a bit pedantic, but I think this kind of game bears a lot of similarities to driving a car - you must minimise the amount of time you take your eyes off the road. That's one of the reasons road signs are designed to be as simple (and non-distracting) as possible (the other of course being that if it's a long or complicated message on a sign you'll have driven past it before finishing reading it).
There are a few things though, that Guitar Hero does right, and they're so obvious as well, that I can't imagine why they're not present in Rock Band:
Singers are presented with a choice of scrolling text, where the text is constantly scrolling on screen from the right in a similar fashion to the other instruments, or paged text, meaning the text is static on screen, and the whole line changes at once (to a new "page") when the marker reaches the end. Rock Band only has scrolling text.
The other is a simple countdown from the pause menu. Rock Band simply throws you back into the action, usually meaning you'll miss the first few beats or notes as you get back into it, but Guitar Hero gives you a fighting chance by giving you a 3-2-1 at the same tempo as the song no less!
There is a lot of polish to be found in the little things - of any game - that I think can be what separates the good from the great.
By comparison, the Guitar Hero score multiplier is displayed up and to the side of each highway, which, whilst not a particularly large distance, is still enough that you're not really looking at the target line any more. The star power metre (the Guitar Hero equivalent to Rock Band's "Overdrive") is well out of the way in the top left corner. Of course, Guitar Hero's star power is combined for all players, which explains why it's as it is, but I think there's an argument for duplicating the information on each of the three highways so that player's don't have to look away from the target line to know how they're doing in that regard.
Rock band also has the "crowd metre" on the left, which shows the players how well they're performing or how close they are to failing a song. All player's are presented on a vertical bar as simple, clear icons which are easy to separate. Guitar Hero has combined this aspect of the HUD with the star power metre. You've got glowing yellow icons for each of the players on 4 separate power bars which has the end result of creating a very murky looking interface item that takes more than a brief moment to see how well you're doing.
I think the fact that each player has their own bar means that, if you think about it, a player has to find their icon amongst the 4, and then look at the bar above (which is 2 steps). Whereas in Rock Band, once a player has found their icon, they know how well they're doing as it's the icon itself that moves, and the bar is very clearly visible in the periphery.
It may sound a bit pedantic, but I think this kind of game bears a lot of similarities to driving a car - you must minimise the amount of time you take your eyes off the road. That's one of the reasons road signs are designed to be as simple (and non-distracting) as possible (the other of course being that if it's a long or complicated message on a sign you'll have driven past it before finishing reading it).
There are a few things though, that Guitar Hero does right, and they're so obvious as well, that I can't imagine why they're not present in Rock Band:
Singers are presented with a choice of scrolling text, where the text is constantly scrolling on screen from the right in a similar fashion to the other instruments, or paged text, meaning the text is static on screen, and the whole line changes at once (to a new "page") when the marker reaches the end. Rock Band only has scrolling text.
The other is a simple countdown from the pause menu. Rock Band simply throws you back into the action, usually meaning you'll miss the first few beats or notes as you get back into it, but Guitar Hero gives you a fighting chance by giving you a 3-2-1 at the same tempo as the song no less!
There is a lot of polish to be found in the little things - of any game - that I think can be what separates the good from the great.
Labels:
comparison,
guitar hero,
hud,
rock band,
versus,
vs
Friday, 23 July 2010
Search
These days it seems that more and more interfaces are emphasising the use of search over more traditional methods of navigating applications.
Microsoft have replaced the Windows start bar with a search field, Apple have a context sensitive system wide search called "Spotlight" in OS X, my android phone even has a dedicated hardware search button.
Google of course are the reigning champions of things search. Take Chrome for instance, It's almost insidious in how it's changed how I browse the web, so used am I to just partially typing an address or search term into it's all knowing all powerful "Omnibox" and expecting it to pick up on exactly what I want, that when I have to resort to using another browser such as Firefox - which I used for years without complaint, I might add - I end up typing searches into the address bar (instead of it's separate search bar) and wondering why it's not working.
This shift in the paradigm of how we use computers is one I wholly support. How many minutes have you wasted searching each of the drop down boxes in a program like Word, looking for a specific feature?
For where games are concerned, I feel it's imperative to integrate a decent search feature into the tool chain, including (but not limited to) things like the world builder and string and asset libraries.
For games themselves, it's a slightly different matter, for big MMOs like World of Warcraft or Eve Online which have huge numbers of craftable items, enemies, locations and of course players, you obviously need a way to sift through it all to find what you're looking for.
For your regular triple A first person shooter, a search function is probably not going to help the game itself, but if you've got more than a dozen preferences in the options menu it could be a benefit. How about a console command search feature for first person shooters from the likes of Valve software and id?
Obviously a text based search is pretty pointless on consoles, which don't really support keyboards as standard. On consoles, simplicity is king, as you have a limited number of controls in which to grant the player access to your world.
For the most part though, Search is becoming more and more predominant in user interfaces and with good reason.
Microsoft have replaced the Windows start bar with a search field, Apple have a context sensitive system wide search called "Spotlight" in OS X, my android phone even has a dedicated hardware search button.
Google of course are the reigning champions of things search. Take Chrome for instance, It's almost insidious in how it's changed how I browse the web, so used am I to just partially typing an address or search term into it's all knowing all powerful "Omnibox" and expecting it to pick up on exactly what I want, that when I have to resort to using another browser such as Firefox - which I used for years without complaint, I might add - I end up typing searches into the address bar (instead of it's separate search bar) and wondering why it's not working.
This shift in the paradigm of how we use computers is one I wholly support. How many minutes have you wasted searching each of the drop down boxes in a program like Word, looking for a specific feature?
For where games are concerned, I feel it's imperative to integrate a decent search feature into the tool chain, including (but not limited to) things like the world builder and string and asset libraries.
For games themselves, it's a slightly different matter, for big MMOs like World of Warcraft or Eve Online which have huge numbers of craftable items, enemies, locations and of course players, you obviously need a way to sift through it all to find what you're looking for.
For your regular triple A first person shooter, a search function is probably not going to help the game itself, but if you've got more than a dozen preferences in the options menu it could be a benefit. How about a console command search feature for first person shooters from the likes of Valve software and id?
Obviously a text based search is pretty pointless on consoles, which don't really support keyboards as standard. On consoles, simplicity is king, as you have a limited number of controls in which to grant the player access to your world.
For the most part though, Search is becoming more and more predominant in user interfaces and with good reason.
Labels:
comparison,
options,
search
Monday, 19 July 2010
Customising the Visual studio debugger
If you delve deep into the bowels of your install of visual studio you might come across autoexp.dat. "What does this file do?" you might ask. Well, you're in luck.
The default behaviour of the windows that display the contents of your variables (autos/locals/watch) in visual studio is, if it's a basic type, such as an int or a float, to display it as is.
If it's a struct or a class, then allow the user to navigate it's structure revealing all variables contained within.
The autoexp.dat file allows for the customisation of this process (and if you look in the file you'll notice Microsoft has already pre-populated it with lots of entries, predominantly for things in the c++ standard library).
Why would you want to customise something if the default behaviour is perfectly acceptable?
Well, here's an example. Say you've got a 3D Maths Vector class which contains 3 floats: X, Y and Z. It's also got all the usual functions you need for doing all the various things you might with a vector, such as dot and cross products etc.
You might then think of a great idea to include some common vectors as static const members to the class. These could include a definition for "UP" where you have Y=1, or another could simply be "ZERO" for when you want a comparison but don't want the overhead [or hassle] of creating a new instance.
It's a good plan, but has the unfortunate side effect of bloating the debugger display to showing you all of your constants every time you expand a vector variable.
In steps autoexp.dat, and here's a simple example of how to write a definition:
First things first, any line that begins with a ";" is treated as a comment and ignored.
Next you have the name of the type you wish to define. In this case it's my 3d vector class. This also supports templates, so "SomeType<*>" is perfectly acceptable, as is template specialisation, e.g. "SomeType".
You'll notice the opening brace "{" is immediately after the type rather than on it's own line. This is because the parser is very unstable and prone to breaking easily. If there is any space between the type and the brace, it just doesn't work.
Next you have your categories. In the example I've given there's "preview" and "children", but there's also "stringview" available, should you require it.
Preview defines what is displayed in the value box for the main type. In this case it will be "[X,Y,Z]" where X, Y and Z are floating point numbers. $e means display in scientific notation should the number be large or small enough to warrant. If you take a look at the top of the autoexp.dat file, you will notice that you have a choice of several different types. $f for instance should allow you to display the number as a standard floating point and never factorise into scientific notation, though, again for me at least, the parser preferred to crash rather than work with anything other than $e.
The "#()" notation simply means here is a comma delimited list of values.
The Children section defines what should be displayed when the user expands the variable. As you can see I include the three members of the vector and an escape clause, if for some reason I need to see the original default formatting of the variable.
I learned everything myself from this wonderful post over at virtualdub.org.
The default behaviour of the windows that display the contents of your variables (autos/locals/watch) in visual studio is, if it's a basic type, such as an int or a float, to display it as is.
If it's a struct or a class, then allow the user to navigate it's structure revealing all variables contained within.
The autoexp.dat file allows for the customisation of this process (and if you look in the file you'll notice Microsoft has already pre-populated it with lots of entries, predominantly for things in the c++ standard library).
Why would you want to customise something if the default behaviour is perfectly acceptable?
Well, here's an example. Say you've got a 3D Maths Vector class which contains 3 floats: X, Y and Z. It's also got all the usual functions you need for doing all the various things you might with a vector, such as dot and cross products etc.
You might then think of a great idea to include some common vectors as static const members to the class. These could include a definition for "UP" where you have Y=1, or another could simply be "ZERO" for when you want a comparison but don't want the overhead [or hassle] of creating a new instance.
It's a good plan, but has the unfortunate side effect of bloating the debugger display to showing you all of your constants every time you expand a vector variable.
In steps autoexp.dat, and here's a simple example of how to write a definition:
;-----------------------------------------------------------
; Vector3d
;-----------------------------------------------------------
Vector3d{
preview
(
#(
"[",
$e.x,
",",
$e.y,
",",
$e.z,
"]"
)
)
children
(
#(
X : $e.x,
Y : $e.y,
Z : $e.z,
[actual members] : [$e,!]
)
)
}
First things first, any line that begins with a ";" is treated as a comment and ignored.
Next you have the name of the type you wish to define. In this case it's my 3d vector class. This also supports templates, so "SomeType<*>" is perfectly acceptable, as is template specialisation, e.g. "SomeType
You'll notice the opening brace "{" is immediately after the type rather than on it's own line. This is because the parser is very unstable and prone to breaking easily. If there is any space between the type and the brace, it just doesn't work.
Next you have your categories. In the example I've given there's "preview" and "children", but there's also "stringview" available, should you require it.
Preview defines what is displayed in the value box for the main type. In this case it will be "[X,Y,Z]" where X, Y and Z are floating point numbers. $e means display in scientific notation should the number be large or small enough to warrant. If you take a look at the top of the autoexp.dat file, you will notice that you have a choice of several different types. $f for instance should allow you to display the number as a standard floating point and never factorise into scientific notation, though, again for me at least, the parser preferred to crash rather than work with anything other than $e.
The "#()" notation simply means here is a comma delimited list of values.
The Children section defines what should be displayed when the user expands the variable. As you can see I include the three members of the vector and an escape clause, if for some reason I need to see the original default formatting of the variable.
I learned everything myself from this wonderful post over at virtualdub.org.
Labels:
c++,
gui,
visual studio
Sunday, 18 July 2010
The Lobby Divide
I have a strange curiosity with a certain aspect of the Gears of War 2 menu system, which is this: it's split into two stages.
When you host or join a custom multiplayer game, you're taken to the first lobby screen (or "Multiplayer party lobby" as it's officially called), where the host can choose game mode (such as Horde or Wingman) and options (number of lives, game duration). When the host is satisfied and selects play, you're taken to the second screen (or "Pregame lobby") where the host can then choose the map (players can also select character and starting weapon at this point).
There's a 5-10 second loading screen between the two. Which is odd as I can't tell what it's loading, if indeed it's loading anything at all (the game itself loads in the background once the map has been picked and the game start countdown reaches 0). It can't be loading the map or characters as they're picked afterwards.
Friends can't join the game once you're in the "Pregame lobby" either, though most games allow joining in the middle so it's not a huge issue, just another strange quirk of the menu.
It seems to have been designed this way so that they could fit all the options on screen rather than splitting them off into a separate menu and displaying a simple summary instead in the lobby.
Ultimately I think this could easily have been refactored into a screen for the lobby and an options screen for the host to configure the game properties. Whilst this is still two screens, there would be no cumbersome loading screen separating the two (and you would be able to travel back and forth between them without having to incur the wrath of the loading screen multiple times either).
When you host or join a custom multiplayer game, you're taken to the first lobby screen (or "Multiplayer party lobby" as it's officially called), where the host can choose game mode (such as Horde or Wingman) and options (number of lives, game duration). When the host is satisfied and selects play, you're taken to the second screen (or "Pregame lobby") where the host can then choose the map (players can also select character and starting weapon at this point).
There's a 5-10 second loading screen between the two. Which is odd as I can't tell what it's loading, if indeed it's loading anything at all (the game itself loads in the background once the map has been picked and the game start countdown reaches 0). It can't be loading the map or characters as they're picked afterwards.
Friends can't join the game once you're in the "Pregame lobby" either, though most games allow joining in the middle so it's not a huge issue, just another strange quirk of the menu.
It seems to have been designed this way so that they could fit all the options on screen rather than splitting them off into a separate menu and displaying a simple summary instead in the lobby.
Ultimately I think this could easily have been refactored into a screen for the lobby and an options screen for the host to configure the game properties. Whilst this is still two screens, there would be no cumbersome loading screen separating the two (and you would be able to travel back and forth between them without having to incur the wrath of the loading screen multiple times either).
Labels:
360,
gears of war 2,
loading,
lobby,
menu,
multiplayer
Subscribe to:
Posts (Atom)

