2 WEEK SOURCE PROJECT

Rebel_Bunker_Title2

‘Rebel_Bunker’ is a Half-Life 2: Episode 2 map I recently finished working on; the primary goals of this project being to get me back into actually creating levels on a regular basis, and more importantly giving myself a strict deadline and making sure I delivered a finished product at the end of it. Though this was a 2 week project, it had to effectively be worked on a few hours a night balanced against other work, effectively serving as a test for time management and motivation when working on future projects like this. The map is certainly not as well designed or polished as I’d like, but I am pleased to have managed my time well enough to ensure a map actually reached a finished state (more or less), and because of that this now sets me up nicely for the work ahead on maps I have lined up for the near future. Here are some of my thoughts on the final map:

  • Due to the strict time schedule I gave myself, very little time was spent on pre-production and layout for the map. This was not good. I adapted to a more freestyle workflow which I enjoyed at first, but when working on a single player level this ultimately ended in a lack of flow and coherence in the spaces, with poor placement of puzzles resulting in odd pacing for the level.
  • Due to the lack of planning, at the beginning I originally decided on using a underground mine as the starting point, to immediately give myself restrictions with designing the narrative and layout of the spaces. I usually would want to begin with what kind of story I would like to tell with a first person game, but starting with the theme effectively cut off other options for me, limiting my decisions and resulting in me being able to get on with the work a lot quicker.
  • The environment themes started to change as I worked on the map, and I ended up with two very aesthetically different areas of the bunker. The first half was a more organic, dimly let space with low ceilings, wooden walls and beam supports, rusted metal doors and fences. The second half of the map was in one large open space, with very oppressive concrete architecture with harsh edges. I like the different aesthetic styles as they differentiate the two different areas, but due to the small size of the map the two visual styles were not blended together naturally. At all.
  • The second large, open concrete area with elevators mining cart tracks was undoubtedly very rushed. The strict time schedule and freestyle workflow resulted in me having a lack of direction of the actual finishing point for the player, and far too much was crammed into the final open area to get the player to gradually scale upwards through a few physics puzzles towards the final elevator.
  • The lighting is pretty terrible. This again was due to the fact it was rushed, both in where and how it was implemented and also the fact I should have spent more time researching the lighting. I also had some problems with sewing displacements which resulted in shadows forming in floor textures that were aligned next to each other. The solution involved redoing the displacements completely and re-sewing them, and for now I’ve left them as they are. I know for future reference however.
  • There were a couple of elements I liked in the map. One example was the elevator that has its switch around a corner, meaning the player cannot actually press the switch and reach the rising elevator in time. To solve this, the player had to push the mine cart onto the elevator, using it as a heavy object to weigh the elevator down once the switch had being pressed, and having the the player go back to push the cart away off the elevator resulting in it rising up with the player on it. After a lot of trouble designing ways to move the elevator, the mine cart puzzle came together nicely as it served as a object within the actual narrative space and was coherently used as part of a physics puzzle.

Though this project resulted more as a test of personal workflow and as a prototype for future projects, everything that was learnt during this project has proved useful for approaching development of future projects I want to work on, of which I’ll be posting about here soon. Here’s some images of the map:

2013-03-18_00017

2013-03-17_00007

2013-03-18_00021

2013-03-18_00026

2013-03-18_00037

Advertisements

USING HEAT MAPS TO INFORM DESIGN

Heat maps are an incredibly useful way to visualise critical player data  from game sessions. They can collect and represent important statistics, with this data then being compiled and presented to the developers to analyse. For example, they can be utilized effectively in an online multiplayer shooter to observe the intricate details of a game, such as what particular weapon was used to gain a kill in a specific point of a map. Observing this data is crucial as it allows designers to be incredibly specific in distinguish what parts of the map are working well and what areas are cause for concern, in ways which may not have been possible just using player feedback alone.

Team Fortress 2 - 2Fort

Team Fortress 2 – 2Fort

It is important to note the difference between heat map data targeted at the players, and the data collected for the developer’s purpose. My first real encounter with using heat maps as a consumer was with Bungie’s fantastic data service incorporated into Halo 3. I was absolutely amazed by the depth and scale of information provided for matches you had played, working both as a springboard for personal skill development and interest in how other players approach a map. Bungie was not the first developer to provide feedback data to its players, but they were certainly the first to hook my interest in heat maps and telemetry data as a player.

Halo 3 - The Pit

Halo 3 – The Pit

On the other hand, developers have been observing data provided by their players for years, both during development and post release. Companies such as Valve are infamous for their consumer/implementation feedback loop, collecting data from the players and continuing to iterate on design issues through updates after a game is launched. Alpha/Beta testing, in-house QA and focus groups have all been ways in which data has been collected pre-release, and it’s become increasingly popular for developers to reach out to fans with an early build of the game, providing valuable telemetry data for the developers regardless of any additional blatant marketing intentions. As well trying to keep the product as balanced and bug free as possible, this data also benefits future players by ensuring better compatibility with different hardware. A great recent example of this is Echo, Splash Damage’s telemetry and analytics system being used on the closed Alpha of their upcoming game Dirty Bomb. In this case the fantastic technology is provided by a dedicated team, where the cloud-based technology can collect data from every single game played worldwide.

Besides the data collected in online games both during development and after launch, developers are increasingly incorporating feedback from players in unique ways through new technologies and business models, and it’s gradually become evident that telemetry data can be incredibly interesting for the player as well as the developer.