I love a game with a great soundtrack and hoping that you share my enthusiasm, here's my current (un-ordered, off the top of my head) Top 10 of gaming melodies. This list includes only the intros, background and mood-setting themes that have been specially composed for the games (as far as I'm aware). I've tried to limit the list to one piece of music per game - as some of the soundtracks could easily fill the entire list.
#1: Kingdom Come, Anno 1404: Dawn of Discovery, by Tilman Sillescu
#1: Sovngarde, The Elder Scrolls V: Skyrim, by Jeremy Soule
#1: Front End, Operation Flashpoint: Dragon Rising, by Christian Marcussen
#1: Reign of the Septims, The Elder Scrolls IV: Oblivion, by Jeremy Soule
#1: Main theme, Dragon Age - Origins, by Inon Zur
#1: Apocalypse, Hitman: Blood Money, by Jesper Kyd
#1: Grinder 2, Red Alert 3, by Frank Klepacki
#1: Still Alive, Portal, by Jonathan Coulton and Ellen McLain
#1: I'll Take It All, James Bond 007: Blood Stone, by Joss Stone
#1: Main theme, Assassin's Creed: Revelations, by Lorne Balfe and Madeline Bell
Wednesday, May 9, 2012
Tuesday, May 8, 2012
Its a-me, Mario!
I absolutely love to play big titles in video gaming, often wondering what makes a video game story captivative enough to invest tens or hundreds of hours of "real life" into the experience. I believe that one of the key factors is a well-represented cultural atmosphere of the story - either a historical or a make-belief backdrop on which the story is revealed. I would like to take some time here and share my thoughts and experiences on one of the aspects of this immersion - the use of foreign language in a game. And by foreign language I mean a non-English language in a game that has originally been created for the English-speaking market.
There are a number of ways to include references in a foreign language in a game. One of the easiest ways to do this without affecting gameplay is in the form of in-game art, as signs or loading screens. Since a gamer cannot be expected to be able to read such messages, this is less common on functional user interface elements, such as in-game menus or heads-up displays (HUD-s). For me at least, this feels really pleasing when recreating a local (Earth-bound) atmosphere in lovely and lively cities like Paris, Beijing, Rome or Moscow or in less crowded environments, where background speech cannot be used. An artificial language, on the other hand, works better as story-telling elements, as it seems to draw conscious attention to itself, not being a part of an average gamer's cultural background.
The aforementioned background voices are another tool for setting the mood. Like in real life, these emphasize the "foreignness" of the environment while creating a lively atmosphere. As an interesting idea that I witnessed in what I believe was a well-known shooter, the background language depended on the difficulty setting selected by the player. A harder difficulty setting meant that the background voices (the voices of the "enemies") were switched to their "native" language. Although being able to vary with the background language creates a really cool option to experience the game world from different perspectives, the most effective way to incorporate elements of foreign language would still be through the voice of the main characters (either playable or non-playable).
One of the common options - creating a stereotypical accent via purposeful voice acting can be a double-edged sword. If kept consistent and believable throughout the game, it works as a tool for distinguishing the character's story, while not requiring the player to spend time reading in-game subtitles. At the same time, using a single stereotypical character seems like a deliberate balancing act on the edge of good taste. Still, nothing beats the creepy results of voice acting in a language that isn't one of the languages the actor uses every day. I am not a fluent speaker of Russian, but having been brought up in a mostly Russian environment, I find it somewhat difficult not to chuckle every time I hear an English-speaking actor attempting to sound "local". This is not always the case, though. I really like the sound of Soviet March from Red Alert 3, although it's neither written nor sung by Russian (or Soviet, for that matter) artists.
Another technique that really stands out in my mind is what Ubisoft has been doing in their Assassin's Creed series. In AC2, AC: Brotherhood and AC: Revelations, the main story-line takes place in 15th-16th century Italy and Constantinople. A truly believable and a player-friendly atmosphere is created by mixing English for plot-related speech, Italian for rudimentary small-talk and occasional Latin as a "cherry" on top of the dessert. When switching on subtitles, translations for the non-English phrases are provided, adding an educational aspect to the gameplay.
All in all, what works best, then? I think that there are three ways to include non-familiar languages in a game:
- as an illustrative background element,
- as a device for emphasizing character diversity,
- as a part of the story, given that this part can also be perceived through alternative channels.
In other words, an unfamiliar language should not function as a puzzle, but rather as a story-telling construct in the game world.
There are a number of ways to include references in a foreign language in a game. One of the easiest ways to do this without affecting gameplay is in the form of in-game art, as signs or loading screens. Since a gamer cannot be expected to be able to read such messages, this is less common on functional user interface elements, such as in-game menus or heads-up displays (HUD-s). For me at least, this feels really pleasing when recreating a local (Earth-bound) atmosphere in lovely and lively cities like Paris, Beijing, Rome or Moscow or in less crowded environments, where background speech cannot be used. An artificial language, on the other hand, works better as story-telling elements, as it seems to draw conscious attention to itself, not being a part of an average gamer's cultural background.
The aforementioned background voices are another tool for setting the mood. Like in real life, these emphasize the "foreignness" of the environment while creating a lively atmosphere. As an interesting idea that I witnessed in what I believe was a well-known shooter, the background language depended on the difficulty setting selected by the player. A harder difficulty setting meant that the background voices (the voices of the "enemies") were switched to their "native" language. Although being able to vary with the background language creates a really cool option to experience the game world from different perspectives, the most effective way to incorporate elements of foreign language would still be through the voice of the main characters (either playable or non-playable).
One of the common options - creating a stereotypical accent via purposeful voice acting can be a double-edged sword. If kept consistent and believable throughout the game, it works as a tool for distinguishing the character's story, while not requiring the player to spend time reading in-game subtitles. At the same time, using a single stereotypical character seems like a deliberate balancing act on the edge of good taste. Still, nothing beats the creepy results of voice acting in a language that isn't one of the languages the actor uses every day. I am not a fluent speaker of Russian, but having been brought up in a mostly Russian environment, I find it somewhat difficult not to chuckle every time I hear an English-speaking actor attempting to sound "local". This is not always the case, though. I really like the sound of Soviet March from Red Alert 3, although it's neither written nor sung by Russian (or Soviet, for that matter) artists.
Another technique that really stands out in my mind is what Ubisoft has been doing in their Assassin's Creed series. In AC2, AC: Brotherhood and AC: Revelations, the main story-line takes place in 15th-16th century Italy and Constantinople. A truly believable and a player-friendly atmosphere is created by mixing English for plot-related speech, Italian for rudimentary small-talk and occasional Latin as a "cherry" on top of the dessert. When switching on subtitles, translations for the non-English phrases are provided, adding an educational aspect to the gameplay.
All in all, what works best, then? I think that there are three ways to include non-familiar languages in a game:
- as an illustrative background element,
- as a device for emphasizing character diversity,
- as a part of the story, given that this part can also be perceived through alternative channels.
In other words, an unfamiliar language should not function as a puzzle, but rather as a story-telling construct in the game world.
Friday, May 4, 2012
Persisting mutable objects in Tapestry
Since Tapestry makes it easy to persist application state by using the @Persist annotation, I tend to have a habit of using mutable state objects and then stumbling on problems when changing these mutable persisted values do not result in updates to the underlying session store.
Here's a sample page class:
On the page template, we simply display the current state and an action link to call the onActionFromChangeState event. Everything seems to work - the state object (List) is lazily initialized and new items are appended to it.
Long story short, Tapestry does not detect the changes to a mutable persisted state object. Unfortunately, the way HTTP sessions are usually implemented in many servlet containers, changes to the mutable state are still persisted (bypassing the Tapestry's persistent field invalidation mechanism). This can cause unexpected and hard-to-trace problems later, when trying to switch the persistence strategy for a specific state variable, e.g. from the session to the client strategy.
For instance, here we try to change the previous sample to use client-side persistence instead:
But when calling the onActionFromChangeState, nothing seems to happen. The state is transferred from the server to the client and back, but this always contains an empty List. This corresponds to the empty List initialized on the first render request.
To demonstrate that this is really the case, we can use a simple hack:
Now the changeState action works once again, since the PersistentFieldConduit responsible for recording the change of the field value is used. Although this kind of a "hack-y" approach works, the moral of the story seems to be quite clear - be very careful when persisting mutable values.
Here's a sample page class:
On the page template, we simply display the current state and an action link to call the onActionFromChangeState event. Everything seems to work - the state object (List) is lazily initialized and new items are appended to it.
Long story short, Tapestry does not detect the changes to a mutable persisted state object. Unfortunately, the way HTTP sessions are usually implemented in many servlet containers, changes to the mutable state are still persisted (bypassing the Tapestry's persistent field invalidation mechanism). This can cause unexpected and hard-to-trace problems later, when trying to switch the persistence strategy for a specific state variable, e.g. from the session to the client strategy.
For instance, here we try to change the previous sample to use client-side persistence instead:
But when calling the onActionFromChangeState, nothing seems to happen. The state is transferred from the server to the client and back, but this always contains an empty List. This corresponds to the empty List initialized on the first render request.
To demonstrate that this is really the case, we can use a simple hack:
Now the changeState action works once again, since the PersistentFieldConduit responsible for recording the change of the field value is used. Although this kind of a "hack-y" approach works, the moral of the story seems to be quite clear - be very careful when persisting mutable values.
Thursday, February 2, 2012
Bean property expressions with Java and Tapestry
Tapestry has a couple of nice features for accessing bean properties in a loosely coupled way. One of them is a reflection-based PropertyAccess and the other one a runtime-generated proxy called PropertyConduit. Both of these are very comfortable to use - just specify a property expression and you're good to go. Unfortunately, in larger projects, these String-based property expressions tend to become a bit difficult to maintain as you're re-factoring the beans the expressions refer to.
So, just for fun, I decided to experiment with an alternative for PropertyConduit - to create the conduits during compilation and have an ability to chain these together into more complex expressions. For instance, if we would have two bean classes:
Then we could refer to and get the "bestFriend.name" property as:
This would ideally be type-safe and the *Properties classes auto-generated.
The initial proof-of-concept that I came up with contains two classes describing the property expressions:
For testing purposes, three classes were created:
To automatically generate property expressions for a set of bean classes, an annotation processor was implemented, which yields the following result (for the bean classes specified above):
And a simple test scenario to check that everything works as expected:
Will need to test this out on a larger scale now, for possible performance and memory usage problems :)
So, just for fun, I decided to experiment with an alternative for PropertyConduit - to create the conduits during compilation and have an ability to chain these together into more complex expressions. For instance, if we would have two bean classes:
Then we could refer to and get the "bestFriend.name" property as:
This would ideally be type-safe and the *Properties classes auto-generated.
The initial proof-of-concept that I came up with contains two classes describing the property expressions:
For testing purposes, three classes were created:
To automatically generate property expressions for a set of bean classes, an annotation processor was implemented, which yields the following result (for the bean classes specified above):
And a simple test scenario to check that everything works as expected:
Will need to test this out on a larger scale now, for possible performance and memory usage problems :)
Wednesday, October 12, 2011
Dynamic dispatch with a twist
Had a silly idea for trying out Tapestry 5.3's new ASM wrapper called Plastic: what if we could implement message dispatchers in patterns like Visitor without ruining the forward compatibility of the Visitor SPI?
I'm actually quite interested in the performance of this bytecode mutant, compared to a reflection-based approach, so there could be some optimization and performance testing waiting ahead.
Let's say we have a generic message interface:
When creating a message handler for this tree, we might want to handle the messages like this:
One option would be to have a reflection-based check in the handle methods defined by the MyMessageDispatcher interface. Another would be to avoid reflection and add a bunch of instanceof statements in the same method, achieving some form of type-safety. The (twisted) option described here would essentially be the second solution, but with a proxy class created on-the-fly. The main requirements for the proxy are:
Let's implement a service for creating this kind of a proxy:
The transformer responsible for implementing this proxy is:
Internally, a DispatchTarget class is used:
A dispatcher proxy can be initialized, using the createProxy() method, passing the implementation instance to the method:
and a message dispatcher (visitor):
When implementing new MyMessage subtypes, we would create additional methods in the interface, but this would also require re-implementing all MyMessageDispatcher subtypes. Additionally, when we have a generic implementation for handling MyMessage and we do not care about the subtypes in a specific scenario, we would not want to implement every possible handle() method out there.
Let's say we have a bunch of message classes:
One option would be to have a reflection-based check in the handle methods defined by the MyMessageDispatcher interface. Another would be to avoid reflection and add a bunch of instanceof statements in the same method, achieving some form of type-safety. The (twisted) option described here would essentially be the second solution, but with a proxy class created on-the-fly. The main requirements for the proxy are:
- The proxy must implement a given dispatcher interface (MyMessageDispatcher)
- When handle(MyMessage) is called, the proxy must:
- Determine the runtime class of the argument
- Find an implementation of the handle() method with the first parameter closest to the runtime class of the message in type hierarchy. Excluding the first argument, the handler must have the same signature and return type as the method specified by the interface
- Call the implementation and return the result.
Let's implement a service for creating this kind of a proxy:
The transformer responsible for implementing this proxy is:
Internally, a DispatchTarget class is used:
A dispatcher proxy can be initialized, using the createProxy() method, passing the implementation instance to the method:
I'm actually quite interested in the performance of this bytecode mutant, compared to a reflection-based approach, so there could be some optimization and performance testing waiting ahead.
Monday, October 3, 2011
An unofficial DAZ Studio 4.0 ad
The kind folk at DAZ 3D seem to be offering a free copy of DAZ Studio 4.0 until the 31st of October. Tried it and although I don't deal with 3D modelling often enough, the software itself is really fun to use and makes figure posing and customization a captivating process. It seems that DAZ 3D has a knack for implementing user interfaces that have a really smooth learning curve. I've been a fan of Bryce and its simplicity for a while and Studio 4.0 is not much different from that aspect.
Here's a small sample of what I came up with on my first go:
Here's a small sample of what I came up with on my first go:
Monday, September 26, 2011
Integrating YUI3 with Tapestry 5.2
I have become a fan of the YUI's patterns for modular architecture and the idea of executing JavaScript in a restricted "sandbox". Unfortunately, I haven't found many examples for integrating this pattern in Tapestry 5.2. The closest example for integrating YUI at the time was the tapx-yui module, but as the project is more related to YUI 2, I thought to give it a go and try to implement something for YUI 3 myself.
Step 1: importing YUI JavaScript modules and CSS
As far as I've understood, there are two ways for importing YUI modules:
In this case, all assets from the YUI build are expected to be stored under the src/main/webapp/yui directory.
The CoreYuiStack class needs to be contributed to the JavaScriptStackSource service:
Step 2: Creating a component that defines a YUI module
As soon as YUI libraries can be auto-loaded, we can start defining our own custom modules. Here is an example of a component that wraps the YUI Panel functionality. Not much augmentation here compared to the YUI's Panel, but the idea should be clear enough.
A new JavaScript namespace, appcore is defined, containing a component called Panel. The corresponding Tapestry component class looks like this:
After the component's body is rendered, we add an initialization call for passing configuration data to the new component. There is no special API here, just a simple code snippet rendered into the page body. There is some room for improvement here. Although we would very much like the initialization call to be wrapped in a sandbox, the dependency on a local variable called Y looks a bit iffy design-wise.
The YuiSupport service is responsible for wrapping the initialization calls into a YUI sandbox:
Step 3: Using the new component
The Panel component can now be used like any other Tapestry component:
The output should now contain a panel similar to this:
Step 1: importing YUI JavaScript modules and CSS
As far as I've understood, there are two ways for importing YUI modules:
- By importing (creating a script tag for) every YUI JavaScript asset that is required on a page.
- By importing the yui(-min).js asset and using the auto-loading feature.
In this case, all assets from the YUI build are expected to be stored under the src/main/webapp/yui directory.
The CoreYuiStack class needs to be contributed to the JavaScriptStackSource service:
Step 2: Creating a component that defines a YUI module
As soon as YUI libraries can be auto-loaded, we can start defining our own custom modules. Here is an example of a component that wraps the YUI Panel functionality. Not much augmentation here compared to the YUI's Panel, but the idea should be clear enough.
A new JavaScript namespace, appcore is defined, containing a component called Panel. The corresponding Tapestry component class looks like this:
After the component's body is rendered, we add an initialization call for passing configuration data to the new component. There is no special API here, just a simple code snippet rendered into the page body. There is some room for improvement here. Although we would very much like the initialization call to be wrapped in a sandbox, the dependency on a local variable called Y looks a bit iffy design-wise.
The YuiSupport service is responsible for wrapping the initialization calls into a YUI sandbox:
Step 3: Using the new component
The Panel component can now be used like any other Tapestry component:
The output should now contain a panel similar to this:
Subscribe to:
Posts (Atom)