Most game designers begin their projects with scribbled notes in sketchbooks, loose ideas on sticky notes, or detailed concepts written in Word documents. This approach can be effective for capturing raw ideas, but it often leaves critical gameplay elements undefined. What if you began instead by designing the user interface and user experience ?
Starting your game project from a UI/UX perspective doesn’t mean skipping creative ideation. It means anchoring those ideas in visual structure and interaction early on. This approach helps you visualize how your game will look and feel, test assumptions, discover hidden features, and define platform specific behavior before writing a single line of code.
In this guide, we’ll walk through the benefits of starting with UI/UX, outline a detailed process, provide examples from real world projects, and recommend tools to help you bring your vision to life.
Author’s Note: This article is written for game designers of all levels. Whether you’re an indie dev, a student, or a team lead at a studio, starting from UI/UX can enhance your design thinking and production pipeline. Try it on your next prototype and watch your ideas take form faster than ever.
Why Start with UI/UX ?
1. Visual Clarity Early On
Creating UI/UX wireframes gives you an immediate visual anchor. You can understand screen layout, information hierarchy, and user flow at a glance. This helps clarify gameplay concepts and surface challenges that aren’t obvious in text.
2. Platform and Control Compatibility
Designing with UI/UX first forces you to consider your target platform. Is the game mobile first ? Will players use a touchscreen, mouse, or controller ? Sketching your interface helps determine what feels natural, what fits the screen size, and how much information the player can process at once.
3. Gameplay Discovery and Iteration
When you design how players interact with the game, you often discover mechanics you hadn’t thought of. For example, when designing an inventory UI, you might decide to add item crafting simply because the interface suggests the possibility. UI mockups help explore these possibilities faster than prose or code.
4. Team Communication and Rapid Feedback
A visual mockup is easier for your team to interpret than a written description. Developers, artists, and producers can align around the same vision faster, leading to quicker iteration and fewer misunderstandings.
5. Smooth Transition to Documentation and Prototyping
Once you have a complete UI/UX flow, translating that into a formal Game Design Document (GDD) becomes much easier. The mockups serve as both a visual prototype and a roadmap.
The UI/UX-First Design Process
Step 1: Sketch Core Screens
Start with the essential screens:
Main menu
Gameplay interface
Pause screen
Game over screen
Settings or upgrade menus
You can do this on paper, whiteboards, or using wireframing tools. Focus on layout, not aesthetics.
Step 2: Define Player Interactions
Ask: What can the player do on each screen ? Are they swiping, tapping, clicking, dragging ? What feedback do they receive ? Mapping these interactions helps you define the gameplay loop and detect missing elements.
Step 3: Build Flow Diagrams
Create a navigation map showing how players move between screens. This highlights UX flow and reveals potential issues, like dead ends or confusing loops. Tools like Whimsical, Miro, or Figma’s flowchart tools work well here.
Step 4: Simulate Gameplay Mechanics
Use your wireframes to simulate core gameplay actions. How does the player start a level ? What happens when they win or lose ? Sketch mini scenarios to understand the players journey. You’ll often spot logic holes or moments where the player needs more feedback.
Step 5: Iterate with Feedback
Test your UI sketches with teammates or play testers. Even without a working prototype, you can use static wireframes or clickable prototypes to gather feedback. Note what’s confusing, what needs explanation, or what can be streamlined.
Step 6: Layer in Game Feel and Visual Hints
Once structure is solid, start thinking about how the interface supports your game tone and feel. Does the layout communicate a frantic pace (like in a roguelike) or a thoughtful, strategic rhythm (like in a city builder) ? Add mood notes, animations, and visual references.
Case Studies and Examples
Example 1: Mobile Endless Runner
A small team began by wireframing their core gameplay screen. They quickly realized that placing the jump and slide buttons on the same side of the screen made one handed play difficult. This insight led to a major control redesign that made the game more accessible.
Example 2: Strategy Game for PC
While mocking up the heads up display (HUD), the team realized that the minimap and unit panel competed for the same screen space. This early catch avoided a UI collision that could have caused major rework during development.
Example 3: Educational Puzzle Game
By building UI flows first, designers found a natural opportunity to insert learning prompts between levels. These weren’t part of the original concept but became a key feature that improved engagement.
Recommended Tools
You don’t need a massive toolset to get started. Here are a few accessible options:
Figma / Adobe XD – Industry standards for UI design, with collaborative and prototyping features.
Whimsical / Miro – Great for mapping UX flows and feature diagrams.
Pen & Paper – Still incredibly fast and effective for early ideation.
Unity UI Builder / Unreal UMG – In engine UI tools to connect layout with actual gameplay early.
Trello / Notion – Organize your interface ideas, game flow, and screen references.
Transitioning to a Game Design Document (GDD)
Once your UI/UX sketches and flow diagrams are in place, turning them into a structured GDD becomes a smoother process. Use your mockups to:
Define each game screen and interaction
Outline core loops and reward structures
Identify asset needs (buttons, icons, screens)
Detail how players receive feedback and progress
In other words, your UI/UX becomes a living backbone for your GDD, not a separate or afterthought element.
Real World Example
When I worked on the design forGunner Fury, I started with the UI/UX. I looked for references that matched my idea. Several games could be used for inspiration, and I chose a submarine simulation game calledCold Waters. I took some screenshots that suited the main interface camera.
Camera Navigation
The main camera in the game can move freely, following mouse input. I needed information that clearly indicated both the camera direction and the heading of the warship I was controlling or observing. To improve situational awareness, I decided to add a compass marker at the top of the screen, along with key supporting information.
Weapon and Sensor Interface
The warship I designed is equipped with modern weapon systems and advanced sensors. To ensure the design accurately represents the technological capabilities and the timeline of the game, I needed a visual style that communicates both sophistication and realism. I researched and referenced modern warships that align with the game setting and era, using them as a foundation to shape the look and feel of the vessel in a way that supports immersion and believability in the gameplay experience.
Weapon Camera
The warship’s primary weapon systems, particularly the main cannon, are designed to be manually controlled by the player. To enhance this mechanic, I developed a dedicated gun camera interface inspired by real world modern naval vessels. I studied how targeting systems work on actual warships, focusing on elements such as camera tracking, crosshair behavior, and real time feedback for aiming and firing. These references helped me design an interface that feels authentic yet intuitive for players. By integrating this system into the game, I aimed to create a more immersive and engaging combat experience one that gives players a sense of control and precision during naval engagements. This manual targeting feature not only adds tactical depth but also reinforces the modern and realistic tone of the game.
Ship Coordination and Navigation
The game is designed to allow players to control multiple ships simultaneously, making fleet management a core gameplay mechanic. To support this, I needed to create an interface layout that effectively communicates several layers of critical information in real time. These include:
The exact location and status of each player controlled ship
The position of allied or friendly ships
The whereabouts of neutral or civilian vessels
The movement and threat level of enemy ships
A dynamic navigation map to support situational awareness and route planning
Given the complexity of naval engagements and the need for tactical decision making, it was essential to consolidate all of this data into a single, streamlined interface. I approached the layout design with a focus on clarity, responsiveness, and precision. Each icon, marker, and visual indicator was carefully placed and scaled to avoid clutter while still maintaining immediate readability.
The interface functions as a command and control center, allowing players to quickly assess the overall battlefield situation, switch between units, and issue strategic commands without losing track of key information. The visual hierarchy and color coding help distinguish between different types of vessels and their threat levels, ensuring the player always knows what’s happening and where.
This design supports real time fleet coordination and enhances the players ability to respond to evolving combat scenarios, making it a vital component of the gameplay experience.
Naval Base
Equally important, I also needed to design an interface for managing the players warships outside of combat. This interface serves as the central hub for all fleet management activities, providing access to key features such as:
Repairing damaged ships
Upgrading weapon systems, sensors, and hull components
Assembling or customizing new warships
Selling or decommissioning unused ships
And other related maintenance and strategic planning functions
The goal of this interface is to give players full control over their naval assets in a clear and engaging way. I designed it to feel like a command dock or shipyard control room, where players can review detailed ship stats, apply upgrades, manage resources, and make strategic decisions about their fleet’s development.
The layout emphasizes usability and information hierarchy. Each ship is represented with visual thumbnails and status indicators, while deeper customization options are available through expandable panels or dedicated screens. Tooltips, visual cues, and confirmation prompts help guide the player through more complex actions, ensuring the interface remains accessible even for new players.
This system not only supports gameplay progression and resource management but also reinforces the game themes of modern naval strategy and technological advancement. It serves as a critical bridge between combat missions and long term fleet development, making it a core pillar of the overall game experience.
Transition to Document
Through the development of this concept, I uncovered several valuable insights that had not been considered in the earlier stages. This process brought new clarity to critical gameplay elements, including ship control schemes, navigation flow, weapon systems, and methods for detecting and engaging enemy targets. These considerations helped shape the foundation of the game core mechanics and user interaction models.
Once all the required information was gathered and refined, I transitioned from visual ideation to documentation. This involved translating key gameplay systems, interface concepts, and functional requirements into structured written form. The result is a comprehensive Game Design Document that serves as a blueprint for development detailing everything from player interaction and UI behavior to mechanical systems and combat scenarios.
Designing games from a UI/UX perspective is more than layout and menus it’s about interaction, discovery, and structure. By grounding your creative ideas in user experience early, you improve clarity, encourage better team collaboration, and reduce development risks.
Next time you start a game project, try reaching for your wireframing tool before your writing software. You might find yourself with a clearer vision, a faster workflow, and a better game.
This guide is designed for aspiring level designers and game designers who also take on level design responsibilities. It offers a structured approach to creating an effective Level Design Document (LDD).
Case Study “The Last Stand: Aftermath”
To illustrate how to craft a compelling LDD in Notion, this guide will use The Last Stand: Aftermath as the core example. It’s a survival action shooter game, from the creators of The Last Stand: Union City.
“After you are infected by the zombie virus, set out to explore the apocalypse and find hope for your colony. You can make a difference. Don’t give up.”
By using The Last Stand: Aftermath as a case study, I’ll show you how to:
Structure a clear, actionable LDD
Communicate design intent effectively
Support collaborative iteration throughout development
Pre-Documentation Analysis
Before diving into the LDD, it’s essential to thoroughly analyze the game. Key components to review include:
Game Specifications
Gameplay and Core Loops
Game Mechanics
Game Economy
Core Features
Key Assets
Storyline and Lore
Missions and Objectives
Characters and Factions
A solid understanding of these elements ensures that your Level Design Document aligns with the overall game design and communicates a cohesive vision.
Why Use Notion for LDD ?
I strongly recommend using Notion as your primary tool for game documentation. With its intuitive interface, rich content formatting, and seamless real-time collaboration, Notion is one of the most versatile platforms for generating, organizing, and sharing game design materials. Whether you’re working solo or as part of a team, Notion keeps everything accessible, structured, and connected.
This guide is designed for aspiring level designers and game designers who also take on level design responsibilities. It offers a structured approach to creating an effective Level Design Document (LDD).
Case Study “BATTLETECH”
To illustrate how to craft a compelling LDD in Notion, this guide will use BATTLETECH as the core example. It’s a turn based tactical game centered around strategic Mech combat. Developed by the creators of the award winning Shadowrun Returns series, alongside franchise founder Jordan Weisman, battletech represents a modern evolution of tactical Mech warfare.
By using BATTLETECH as a case study, I’ll show you how to:
Structure a clear, actionable LDD
Communicate design intent effectively
Support collaborative iteration throughout development
Pre-Documentation Analysis
Before diving into the LDD, it’s essential to thoroughly analyze the game. Key components to review include:
Game Specifications
Gameplay and Core Loops
Game Mechanics
Game Economy
Core Features
Key Assets
Storyline and Lore
Missions and Objectives
Characters and Factions
A solid understanding of these elements ensures that your Level Design Document aligns with the overall game design and communicates a cohesive vision.
Why Use Notion for LDD ?
I strongly recommend using Notion as your primary tool for game documentation. With its intuitive interface, rich content formatting, and seamless real-time collaboration, Notion is one of the most versatile platforms for generating, organizing, and sharing game design materials. Whether you’re working solo or as part of a team, Notion keeps everything accessible, structured, and connected.
With over 8 years of experience in designing and developing competitive maps for Counter-Strike 1.6 and Counter-Strike: Source, I have built a strong reputation within the Indonesian Counter-Strike community and beyond. My maps are known for their detailed environments, unique concepts, and frequent appearances on international servers.
I specialize in gameplay focused level design with an emphasis on optimization, simplicity, and player navigation. I believe a great map should be intuitive, easy to memorize, and offer a seamless gameplay experience.
Beyond designing, I actively contribute to the community by teaching aspiring level designers. I run a dedicated website that features tutorials, tools, videos, and a discussion forum helping others build and refine their own maps for Counter-Strike.
Introduction
The purpose of this final year Practical Project is to design and develop a multiplayer map, created according to the principles and specifications of game level design. The main objective of the entire process is to support the designer’s ongoing development in this field.
The structure of the report follows the guidelines provided in the project handbook. According to this structure:
The first section outlines the main aim and detailed overview of the project.
The second section presents the actual design and configuration, along with analysis.
The third section describes the implementation procedure in detail.
The fourth and final section covers the evaluation and results.
As a personal reflection on this Practical Project, it was a valuable opportunity and an essential learning experience. It provided a wealth of insights while significantly enhancing my level design skills.
I would like to express my sincere appreciation and gratitude to everyone who supported and guided me throughout the course.
I am truly thankful.
1. Project Aims
Overview
This 60 credit project focuses on computer game level design, specifically tailored for team-based multiplayer gameplay (LAN or online) in Counter-Strike: Source (Source Engine).
The concept is rooted in hands-on experience with game editors and aims to deliver a first-person shooter map with clear mission objectives for each team.
The level will be set on the Teesside University campus. For privacy and security reasons, the design will exclude building interiors, the battleground will take place entirely outdoors.
The level will incorporate the following key elements:
Balanced gameplay to allow each team to develop their own tactics.
Simple and memorable navigation paths to support exploration and mission completion.
Straightforward, fast-paced gameplay.
A variety of available weapons.
Designated mission objective areas.
Strategic ambush locations.
Clearly defined spawn points.
The Idea
It all started with The Expotees catalogue, which was distributed for free on the opening day of the Practical Project module, led by the Head of the module. The catalogue featured a variety of student work from previous expos and provided valuable information on how projects would be displayed at the upcoming event.
Categories included Character Design, Animation, Game Design, Music for Games, and Game Level Design. Based on the available criteria in the catalogue, the author decided that his Practical Project would focus on Game Level Design.
While exiting the lecture building, he noticed an interesting object near the Athena Building, a large neon advertising board featuring an illustrated map of the university.
The map was presented in a perspective view, showcasing various assets and information about the campus:
Based on that, the author decided to design a multiplayer map set in the location of Teesside University. After meeting with his supervisor, they both agreed that the author’s Practical Project would focus on designing a multiplayer map for Counter-Strike: Source, based on the Teesside University campus.
Research
The game level design will be informed by analysis of existing multiplayer games that are popular among FPS gamers (both LAN and online). Research sources include popular game editors, online tutorials, and books.
Key considerations during research and development include:
Competitive gameplay dynamics.
Level design theory.
Architectural style.
Visual aesthetics.
Level Layout Illustration
A 2D top-down plan map will be created, complete with a legend. It will display all essential gameplay elements, including rooms, open areas, and objectives.
Level Design Document (LDD)
A comprehensive document will outline all necessary information and events to be implemented in the level.
Concept Development
Concept illustrations will be derived from Google Earth imagery and the interactive campus map from the official Teesside University website.
3D Implementation
Based on the level layout, design document, and reference materials, the full level structure will be modeled in the game editor to reflect the author’s intended vision.
Report
All research, development stages, problems encountered, solutions found, and the final output will be documented in a formal report.
Timetable
The project began in mid-November 2010. The map is expected to be ready for testing by January 2011.
Game and Engine
The primary objective of this practical project was to design and develop a unique piece of work that would help the student achieve his academic and creative goals. As a game design student, the author had long aspired to create a project inspired by the games he had enjoyed over the years, particularly those in the first-person shooter (FPS) genre. Through his experience with these games, he became familiar with advanced editors, game engines, and emerging technologies.
Given the limited timeframe, the author had to manage his workflow efficiently. This involved careful time management, conducting in-depth research, and capturing reference photographs of the university campus to ensure the accurate scaling of the map, just one example of his hands-on approach. This project represented a meaningful opportunity to create high-quality content for one of his favorite games, with the aim of delivering a distinctive and memorable practical submission.
Following extensive research, the author chose to enhance his expertise with the Valve Hammer Editor (VHE), the level design tool for games running on the Source Engine. His goal was to create a multiplayer map for Counter-Strike: Source, a title that has had a long-lasting influence on him as both a player and designer.
This game level design project was approached from the perspective of an experienced level designer. The objective was to develop a single, fully playable game level using VHE. This editor was selected not only because of the author’s familiarity with it but also due to its robust features and straightforward asset requirements, which made it ideal for the project’s scope and timeline.
Counter-Strike: Source (CS:S) is a first-person shooter developed by Valve Corporation. It is a full remake of the original Counter-Strike, rebuilt using the Source Engine. As in the original, players are divided into two teams Counter-Terrorists and Terrorists and compete across a series of objective-based rounds, which can involve scenarios such as bomb defusal, hostage rescue, or team elimination.
The Source Engine, developed by Valve Corporation, made its debut in June 2004 with the release of:
Counter-Strike: Source
Half-Life 2
Other notable titles built on the Source Engine include:
Left 4 Dead
Team Fortress 2
Garry’s Mod (GMod)
Vampire: The Masquerade – Bloodlines
Dark Messiah of Might and Magic
Portal and Portal 2
Zeno Clash
Vindictus
Why did the author choose Counter-Strike: Source?
The reason is that he has played it for years. He also enjoys using the editor, the Valve Hammer Editor (VHE). Compared to other editors from different games he has tried before, VHE is the most reliable for him. Additionally, it provides everything he needs to build a simple map without requiring many assets that would take a lot of time to create.
Specification and Materials
After obtaining approval, the author had to gather supporting materials. The map was designed as a defuse map. The level specification was based on the standard configuration of a defuse map, particularly for Counter-Strike: Source
Map Type
DE Map (Defuse)
Max Players
32 (Online or Offline)
Map Location
Teesside University (Middlesbrough)
Map Theme
Real World
Textures
Custom
Meshes
Custom
Environment
Outdoors
Weapons
All
Mission Objective
There are 2 teams in this mode: Counter-Terrorists and Terrorists.
The Counter-Terrorist mission is to prevent the Terrorists from bombing one of the two available bomb sites. Team members must defuse any bombs that threaten the targeted areas or eliminate the Terrorist team members.
The Terrorist mission is to destroy one of the two bomb sites or eliminate all members of the Counter-Terrorist team.
In the author’s opinion, the map needs to be easy to memorize and straightforward.
Location
As the author mentioned before, the map is set at Teesside University. His first task was to gather information, such as blueprints or anything that would represent the area, in order to create the level.
After speaking with the receptionist at the information center, it was unfortunately not possible to obtain this. The only option was to use a picture from Google Maps.
As seen in the illustration above, the location is marked within the red square (box). It consists of 5 main buildings:
Around the middle of December 2010, the weather conditions improved for a few days. During that time, there was little activity in the area, and only a few cars were in the parking lot. I took advantage of this opportunity to gather a set of pictures with a digital camera, representing each main building, before it started snowing again.
There are thousands of them. Each picture represents a variety of information, such as measurements, dimensions, details, textures, lighting, etc.
From the information gathered:
The university is surrounded by residential houses, offices, and shops.
Most of the buildings are constructed from red bricks.
Each building has numerous windows covering every corner and wall.
The architecture is box-shaped and modern, with some buildings being quite tall.
The parking areas are large and can accommodate around 48 to 50 vehicles.
There are plenty of trees and bushes growing around the area, with approximately 40% of the ground covered in grass.
Measurement
After gathering the necessary visual assets, it was time to collect measurements, or at least estimates close enough to the real dimensions. I asked a friend to act as a model to help me compare the sizes of two windows located at the Grieg building.
His measurements were suitable to start with, he is approximately 175 – 180 cm tall, which is standard for a male body. I asked him to stand between the windows at the Grieg building. After that, the author had to convert the information from the illustration above directly into the Game Editor.
2. Actual Design
The workflow of the Hammer Editor is actually quite easy to follow. By adding a random box or block of frame directly into the editor, the user can create or rapidly manipulate an object into something different.
The Block Tool within the editor is generally used to produce simple objects such as arches, blocks, cylinders, spheres, spikes, tori, and wedges. Once the brush is ready, the user can manipulate it, e.g., stretch or deform it into different shapes, directly within the editor, without the need for scripts or code.
Character
The character shown in the illustration below is a standard character for Counter-Strike: Source.
It is essential to set a scale based on the visual asset to match the player character in the game editor. Once the character is properly displayed, the next step is to scale down the information taken from the photo of a friend acting as a model between two windows at the Grieg building, and apply it directly into the game editor (VHE).
The first thing that needs to be configured is:
“The Windows”
Why the windows? Because every building in the area is filled with a similar set of windows. Their scale provides a reference point for starting construction. By recreating the number of windows that match the original building, the overall size of the building in the editor can be accurately estimated.
There are two windows between the default character in the illustration below. By matching a picture of the model with the character, it becomes a quicker method to get a closer look at how the measurements should appear in the actual game.
By repeating this process, a more accurate measurement of each structure can be achieved. The guidance from Google Maps and the set of pictures should not be forgotten, as they work together to make progress possible.
The illustration above shows the Grieg building, which is nearly complete. It includes a character standing between two windows, mimicking the model.
Construction
After completing a building, the procedure continues with the nearest structures. The next picture shows a connector bridge. It is important to follow structures like this closely, as they serve as a sequence and guide to achieve the correct scale.
By adding multiple character players around the connector, it helps maintain an accurate sense of scale. Frequently revisiting the actual location can also help the designer memorize details or gather additional information for the asset.
After many revisions, the bridge is now successfully connected to the nearest building, the Student Union. However, considering the overall dimensions, the map was still too large to meet the project specifications. Although the map can support up to 32 players, the standard configuration for international Counter-Strike competitions is 5 vs. 5.
Based on this regulation, the author ultimately decided to cut the entire map in half.
Finally, the result of hard work is a full-scale model of Teesside University, consisting of three main buildings:
Grieg Building
Student Union
Europa Building
The most challenging structure to construct was the Europa Building. It has a very complex design, especially at the entrance, which connects the bridge to both the Student Union and Grieg Building. The author frequently had to revisit the location, conduct additional research, and take extra notes until the problem was finally resolved.
The rest of the buildings were easier to construct, as most of them are box-shaped. The main focus was adding accurate scale and details.
3. Procedure of implementation
At the moment, the map is dull and empty. To qualify as a defuse map, it must be equipped with at least two bomb sites and two spawn points for both teams (Counter-Terrorist and Terrorist) in order to function properly.
Bomb site
There are two bomb sites in the map:
Bomb Site A is the parking lot at the Grieg Building. It contains valuable crates/goods that need to be either protected or destroyed.
Bomb Site B is the loading bay at the back of the Student Union building. It consists of chemical tubes and toxic barrels. Some of the barrels can explode if hit by bullets or a knife.
Player spawn
There are two player spawn points on the map:
The Counter-Terrorist spawn point is located in the parking lot near the Grieg building. It consists of 16 available slots. The yellow box surrounding the players is a trigger that serves as a buy zone for the Counter-Terrorist team only, meaning only Counter-Terrorist members can purchase weapons within this area.
The Terrorist spawn point is located near the end of the Europa building. It consists of 16 available slots. The yellow box surrounding the players is a trigger that serves as a buy zone for the Terrorist team only, meaning only Terrorist members can purchase weapons within this area.
Background
The buildings at the corners of the map are made from props taken from the default prop stock in the Source Engine 2011. They work effectively to create the impression of a lifelike, more realistic environment and improve the map’s aesthetics. This effect makes the player feel as though they are in the middle of a town.
Fast paced gameplay
Despite the map being quite large (from a character’s perspective), the author found that the map is easy to explore. The player can reach the main mission objective without needing to reroute. The entire layout is very easy to memorize, even for a beginner player. The invisible barriers around the map will keep players within the boundaries.
They work perfectly to prevent a player from accidentally leaving the war zone and ending up stranded in an unknown location.
Element of surprise
By adding plenty of stationary trucks, players can jump in to hide. Some of the trucks are equipped with a pair of explosive barrels in their cargo area. These barrels will explode if hit by a bullet, killing anyone standing too close to them.
To fill the gaps within the map, this problem can be solved by adding a variety of stationary vehicles and crates of different sizes. Players can use them for cover if spotted by the enemy or to climb to higher ground. The trees on the map also provide cover, as they contain collision detection that blocks both visual contact and bullets.
Props list
List of props that currently are in use in general:
8 types of Vehicles
7 types of Trees
2 types of bushes
5 types of Crates
2 types of Barricades
4 types of Barrels
5 types of Tubes
2 type of Fences and plenty of small items which work as additional details.
Sky Box
The sky surrounding the map is made from a blue texture intended to represent a specific theme, which is a combination of a set of images.
Textures
Some of the textures in the map represent the actual materials of the structures, such as red bricks, while others do not. The purpose of this is to achieve a different look and to avoid repetitive textures.
Special Textures
Surfaces that are not visible to the player’s view are marked with the ‘nodraw’ texture. This prevents the engine from rendering those surfaces, effectively optimizing map performance and reducing compile time.
The barrier (invisible wall) surrounding the map is marked with the ‘clip’ texture. Its function is to keep the player within the designated mission objective area.
Mission objectives in the map are marked with the ‘Trigger’ texture. It functions as a command to activate special events when a player enters the area, such as a Buy Zone, Planting Area, or Hurt zone.
Compiling the map
To build a detailed map like this, the editor requires a powerful computer capable of handling complex lighting instructions from the latest version of the Source Engine (2011). The information below shows the specifications of the computer used by the author to compile the map:
Operating System:
Windows Vista Ultimate – Service Pack 2 – 64-bit Edition
Processor:
Intel Core 2 Quad Q6600 (4 cores) @ 2.40 GHz
Memory (RAM):
Corsair XMS2 DHX DDR2, 2 GB x2 (Dual Channel)
Hard Drives:
Seagate 80 GB
Seagate 1 TB x2
Graphics Card:
XFX Nvidia GeForce GTX 260, 896 MB
Motherboard:
Gigabyte X48-DQ6
Monitors:
Acer X223HQ 21.5-inch x2
Sound Card:
Realtek AC’97
Note
The compilation was run using the default lighting configuration. The author decided not to activate the HDR feature, as the map is still in the testing phase. Full lighting features will be available in the final version, which is currently under development.
Gameplay and Trial
Now that the author has completed the construction of the entire building, he needs to test how it performs in-game. The author tested the map by playing against computer-controlled players (bots) to get a sense of how the map plays. It has been run through a series of tests. By doing this repeatedly, the author is able to identify vulnerable areas that need improvement.
The map mode is a defusal type, meaning it is configured to have at least two bomb sites. Each bomb site serves as a mission objective that players must achieve. The first bomb site is located in the parking lot of the Grieg Building, and the second is at the loading bay of the Student Union.
The map is populated with a variety of props (provided by the Source Engine in the props directory) to fill gaps around buildings. These props are not only functional but also enhance detail and aesthetics. Invisible barriers (clip walls) within the map prevent players from jumping out of the designated mission area.
The author kept updating the map every time I played it. The structure of the map is not the only thing I need to build. One very important part that also needs to be achieved is:
“The Gameplay”
The map looks nice now, but that is not enough. It needs to be played in order to gather valuable feedback, which is a key element in improving it. The author has also asked some of his friends to test the map and share their thoughts.
4. Evaluation
After receiving feedback, the author gathered some insights he had never thought of before, such as adding more trees, lights, barriers, covers, and textures, as well as deciding what to add or remove. The author kept updating his map every day based on this information. Apparently, three servers (two from France and one from the USA) have added this map to their map list.
Although it’s still in a testing phase, they liked the map even more than I do. The map was heavily modified from its original design to improve gameplay and achieve better optimization.
Bomb Site Update
The original Bomb Site A was surrounded by fences that blocked access to the planting area. These fences limited the terrorist team to only one way of reaching the site. Because of this, the fences around Bomb Site A were replaced with a variety of stationary vehicles, providing more space for access and additional cover. However, this new configuration also gives the counter-terrorist team more opportunities to camp.
The planting area on Bomb Site A has been improved by adding two stationary trucks, which serve as new locations for the terrorist team to plant the bomb by jumping into the cargo bed. This creates a good opportunity to hide and protect a planted bomb from the counter-terrorists. A counter-terrorist trying to defuse the bomb would be in a vulnerable position, as they wouldn’t be able to see anything outside the truck’s cargo area.
Explosive barrels have been placed at Bomb Sites A and B. These barrels will explode if hit by a bullet. Players (both terrorists and counter-terrorists) who camp near these barrels will take significant damage or even die if they stay too close to the blast area. This discourages both teams from camping near the bomb sites.
Bomb Site A is hard to reach but easy for the terrorist team to defend. The site is located in a wide-open area where anyone providing cover can be easily spotted. However, it also gives the counter-terrorist team an opportunity to flank terrorists approaching the site. Meanwhile, Bomb Site B is easier for the terrorists to reach because it is very close to their spawn point, but it is much harder to defend. The planting area is small, lacks cover, and is surrounded by fences, giving the counter-terrorist team opportunities to hide and camp around it.
Roof Access
To address balance issues, access to the rooftops has been removed, especially for the Grieg building. If a counter-terrorist player managed to reach the roof, they would have the opportunity to observe both bomb sites and exploit this advantage to target terrorists attempting to plant the bomb.
Spawn Update
The author discovered that the spawn point for the terrorist team was too close to Bomb Site B. This allowed terrorists to reach the site too early, giving them an unfair advantage before the counter-terrorist team could respond. This situation affected the overall map balance.
To address this issue, the author moved the terrorist spawn points slightly farther from their original location.
More Cover
The use of various sizes of stationary vehicles clustered around Bomb Site A provides both teams with extra protection. Although the chance of being exposed remains high, players are able to fight back or retreat at the same time. A similar vehicle cluster is also used in the parking area near the Student Union.
The number and variety of crates has been increased for tactical purposes, such as camping, providing cover, or climbing to higher ground.
Shortcut
Players can climb on stacks of crates to bypass or escape from enemy barricades. For example, a player can jump onto a pile of crates to reach higher ground or access the bridge without using the stairs.
Dark place
Some areas are intentionally left dark without any light sources, such as the narrow space beneath the entrance of the Europa building that connects to a bridge. This location, situated in the middle of the map, can be occupied by either team.
A sniper can use it to sneak in and intercept enemy movement with a low chance of being exposed, thanks to the cover of shadows. It is an ideal spot for ambushing unaware enemies.
More Trees
Although trees are effective for enhancing the map’s aesthetics, a row of trees can also provide additional protection. This is because they have collision properties that block bullets or anything that hits them.
Why the map is good?
An experienced player who recently tested the map told the author that he was impressed with the map’s characteristics. He found that the map is highly competitive. The tactics to dominate the game continue to evolve each time he plays. The design and features keep expanding, providing more opportunities for players to explore various ways to win.
The result of cooperation between players and designers has created a mutually beneficial combination, allowing both sides to continue developing a great product.
Conclusion
As an experienced level designer and the author of this final year practical project, he discovered that cooperation between designers and players is crucial for developing a good map that provides a sense of satisfaction for both sides. As a result, players will continue to engage with the map and, in fact, will promote it to attract more competitors.
This kind of experience is invaluable for a designer looking to further develop their work. Although the map is still in its beta version, development continues to move forward to achieve the best possible result.
Do you enjoy playing First Person Shooter video games, or are you interested in creating levels (maps) for Counter-Strike? You can use a level editor, such as the Valve Hammer Editor, to create maps or levels for Counter-Strike.
The Valve Hammer Editor (often shortened to “Hammer”) is Valve’s official level editor for games built with their GoldSrc , Source, and Source 2 engines. It’s used to create the game environments, including geometry, textures, and placing entities within the level.
History
Originally named “Worldcraft,” it evolved through various versions for different engines, with versions 3.x for Source and 5.x for Source 2.
Functionality
Create and manipulate basic game geometry using brushes.
Apply textures to the geometry.
Place various entities within the level, including lighting, triggers, and other game elements.
Configure entity behavior and scripting.
Build maps with complex systems of logic and gameplay.
Use Cases
Hammer is the standard tool for creating levels in Valve’s games (e.g., Half-Life, Counter-Strike, Portal) and is also used by many modding communities for those games.
Availability
Hammer is typically included within the SDK (Software Development Kit) for the respective engine, allowing developers to create custom content. For Source 2, it’s available as a DLC for Workshop tools.
Requirements for creating maps (levels) for Counter-Strike
After downloading Counter-Strike (CS 1.6), the next step is to install and set up the Valve Hammer Editor. The video below was made for the non-Steam version of CS 1.6, but it is still valid for use with the Steam version, you will need to locate the following directory:
The video below explains how to create a basic level (map) for Deathmatch mode. Pay close attention to all the steps involved in the level creation process.
Keyboard shortcut keys:
Control camera – left click mouse (hold) + ASDW
Pan camera – right click mouse (hold)
Zooming in and out – mouse scroll
Step 3
After finishing the basic map, the final procedure is to compile the map (.rmf) into a playable level (.bsp).
Congratulations, you have become a level designer! 😉
Alternative download
I’ve provided the .RMF file, created using the tutorial – download
The story goes back to 2012, when I had just graduated from university as a newly minted game designer. I returned home and made a plan to work at a game studio that was still relatively new in Indonesia at the time.
To get in, I needed a portfolio in the form of a playable prototype. I saw it as the perfect opportunity to apply the skills I had learned during university.
Gather the team (ID, UK, US)
Additionally, I needed a team to create this portfolio, so I started with my closest circle. I have friends from university who are in the same situation as me, as well as friends from previous projects.
I made a deal with my first programmer, who lives in the UK. We were in the same class and had worked together before, so I was familiar with his skills in using the Unity game engine. One problem solved (profile).
Next, I needed the help of a 3D artist to handle some game assets and textures. I knew someone from a previous project who was highly skilled in his field. He lives in the US, and when I invited him, he was interested (profile).
As for myself, I live in Indonesia. I can handle game research, game concept, game design, level design, UI/UX, sound editing, and 3D modeling. FYI: I can’t do art-related tasks like texturing or graphic design.
With that, the minimum team needed was complete.
Important Note: as for game designers, understanding the technical aspects required for game development and recognizing the strengths and weaknesses of the development teams is highly beneficial when making decisions about what games their team can create.
Game that fit our skills
Okay, based on the skills we’ve mastered, we need a game concept that fits our skills:
Since none of us is capable of animating objects, the game doesn’t require rigs or complex animations.
Since none of us is skilled in art, the game doesn’t require artwork.
We don’t want to spend too much time working on level design, so the game doesn’t need complex level layouts.
Our target is a working prototype, so the game doesn’t require progression systems.
We want our game to be flexible, it should be playable with both a regular controller and a touchscreen.
The game should be expandable to accommodate new features during full production.
Search for references
I’m starting to look for a game concept that suits our skills, and more importantly, one that I will enjoy.
I like FPS, simulation, and RTS games. FPS isn’t a good starting point because it heavily relies on level design.
Although I’m skilled at creating level designs, it still takes a long time to make a good one. Plus, testing these levels requires good bots and multiplayer, and we don’t have the time or resources for that. Also, there are just too many FPS games out there.
You can view my level design work through this link:
Simulation and RTS could be a great alternative, so I’m trying a combination of both.
I looked at a list of games on my Steam account and found a good match: “Wargame: Airland Battle,” with over 400 hours of playtime. Okay, this seems like a concept I can try.
I did deep research on what makes this game fun for me, from the FTUE (First Time User Experience), the theme, the game setting, the function of each unit, and so on. But I realized what’s missing in this game: “NAVAL BATTLE.”
Then I realized there aren’t many modern naval battle games being released, so I decided to focus on creating a concept for a wargame with a naval battle theme.
So, I started researching the types and classes of modern warships, their weaponry, sensors, strengths and weaknesses, the role of each ship, its missions, and how they work in real-world applications. I compiled everything into a Game Design Document, which gets thicker every day.
Most of the units in this game will be warships and shipyards, which involve hard surface modeling which I can handle myself, but my only issue is texturing, which can be managed by a 3D artist, along with the additional warships that need to be modeled.
The asset itself will not require a rig for animation, since the only moving parts are the gun barrel, radar rotation, and silo door, which can be easily handled by the programmer.
The level design would consist of flat ocean surfaces, nothing complex, and can be easily handled by the programmer.
Game SFX will be handled by me. I’ve found tons of sample free audio through Google and YouTube searches, which will allow me to make clean cuts for each ship and weapon.
For UI/UX and the overall game theme, I plan to primarily draw inspiration from Wargame: AirLand Battle, while adding my own unique twist.
The rest, including the game code, will be handled by the programmer.
Game Spec
After I was confident with the game concept we wanted to work on, I shared this concept with the team members. After receiving feedback on what we needed
Platform: Desktop (Windows OS).
Genre: Simulation
Screen layout: Landscape
Camera: Bird Eye view
Input: Keyboard and Mouse
Player: Single player
Connection: Offline
Distribution: MODDB
Project Management
In addition to being a game designer, I also participate as a Project Manager, where I create tasks and distribute them.
To simplify task distribution, we use the Trello app. I created a card for each team member. From these cards, I can see the status of each task, which greatly helps me monitor the progress of this game.
Working Prototype
After working hard for several months, we finally have a working prototype that can be played.
Since we are still beginners, bugs or absurd things are events that we enjoy every day. For example, “the Drunken Torpedo”.
We don’t stop at one, two, or even a million bugs. We keep pushing forward with the continuous iteration of game development.
We try to make this game as authentic as possible. For example, in the Protection feature, modern warships commonly use CIWS as close-defense against missile attacks.
Aim for full production
After we felt that the game had potential, I tried reaching out to several game studios/game publishers to secure funding for full production.
I received a response from a representative of Wargaming. They requested a prototype of the game we were developing. After waiting for a while, we didn’t receive any funding because our concept didn’t meet their expectations visually.
As I mentioned before, we lacked artistic skills and didn’t have the resources for that. In the end, we decided not to continue the development of this game.
It would have been interesting if we had secured the funding to polish the game.
Try Gunner Fury
If you’re interested, you can try playing Gunner Fury through this link:
Are you looking to start your own game studio ? Do you have clients, investors, or a clear target market in mind ? If so, this workflow might help you run your game business.
I would like to share some tips on preparing to write a Game Design Document (GDD), especially for those who are new to the world of Game Design or for those who are still unsure about what is needed before embarking on the development of a new game.
Based on my personal experience, the process begins with the origin of the game idea, which I will explain using the flow/diagram provided below.
I created a comparison between a simple Game Design Document (GDD) and a detailed GDD, using the concept of an endless run game as the context.
What differentiates a Simple GDD from a Detailed GDD ?
Simple GDD
A simple GDD serves as an initial concept or a high-level overview of the game.
Its primary purpose is to present the core ideas, features, and gameplay mechanics in a concise manner in order to secure approval from stakeholders or decision-makers before the production phase begins.
This version of the GDD typically focuses on essential elements, such as the game’s overall vision, basic gameplay loop, and key features. Since it is designed to be a quick reference, it doesn’t require much time to develop, usually taking around 1 to 2 days to create.
The simple GDD is mainly used to communicate the concept and direction of the game, and is not as detailed or refined as the subsequent iterations.
It serves as a preliminary document to ensure that the game concept aligns with the expectations of the project team and management before moving forward.
On the other hand, a detailed GDD comes into play once the initial concept has been approved. After receiving the green light to proceed with production, the detailed GDD becomes the living document that guides the entire development process.
Unlike the simple GDD, which is focused on the overarching ideas, the detailed GDD provides an in-depth breakdown of every aspect of the game, including game mechanics, levels, art style, character designs, sound, user interface, and much more.
It also outlines the specific requirements for programming, production schedules, and resource allocation.
This version of the GDD is constantly updated throughout the development cycle to reflect changes, iterations, and new ideas as they emerge. It becomes a vital tool for coordinating between different departments (e.g., design, art, and programming) and ensuring that all elements of the game are aligned with the original vision.
The detailed GDD plays a crucial role in facilitating communication and ensuring that the project remains on track throughout the production phase.
Each developer may have different experiences and standards when it comes to creating and naming assets. If there is no standardization, other team members may become confused due to the inconsistent formats. This can hinder the process of asset creation and implementation.
Example
Let’s consider two game artists assigned to create prop assets. One artist uses English while the other uses Indonesian. One writes “house” while the other writes “rumah.” Without any clarification, it becomes unclear which version of the house asset it is or where the “house” asset should be placed. Now, imagine if there are thousands of assets and each one needs to be opened individually just to determine its purpose. It would consume an entire day’s worth of time.
Solution
Lies in establishing a standardized naming convention right from the beginning. By following this convention, the type, function, and placement of an asset can be understood without needing to open the file. This facilitates greater efficiency for all parties involved. For instance, if a developer needs a button asset for their game UI, they can immediately recognize from the code “btn_nor_play_1” that it is the original version of the normal state button. There is no need to open the file to confirm if it is the asset they are looking for.
You can see an example of its usage in the image below:
To display the changes made in the latest and previous versions of the GDD.
Problem
Let’s say there are five versions of the GDD, from version 1 to 5. Each version contains different updates and varying amounts of information. Now, imagine there’s a new update, and both new and existing team members need to read everything from the beginning just to understand what has changed. That would be time consuming, right ?
Solution
This version update page is designed to save time and streamline the development process by allowing team members to quickly see which pages have changed without needing to read the entire document from the start.
You can see an example of its usage in the image below:
Hello everyone, I would like to share some tips on writing a Game Design Document (GDD), especially for those who are new to the world of Game Designers. Based on my experience, not all team members of developers enjoy reading GDDs, resulting in outdated information. As a result, they frequently approach Game Designers with various questions, which slows down the work process. To address this, I have devised a new GDD format:
60% visuals (images)
40% text
With this new format, team members who were initially reluctant to read lengthy texts can quickly absorb information because all the information is presented visually, eliminating the need for imagination to understand it. An example can be seen through the image below:
This new format utilizes PowerPoint (pptx) or Google Slide, and I will also share its GDD anatomy, which can assist in development (pay attention to markers 1, 2, and 3):
Document Tags: These tags serve to explain the status of the features to be used. Tags are represented by various code:
WIP (Work in Progress): Indicates that the feature is still in the design phase
Done: Indicates that the feature has received approval and is ready for development.
Pending: Indicates that the feature is awaiting approval
Scrap: Indicates that the feature will not be used
Short Codes: These codes function as unique identifiers for each feature. During development, task allocation or discussions can simply refer to the code, and all team members will immediately understand the feature being discussed. This approach effectively reduces misinformation, especially in games with numerous similar features.
Reference Links: These links serve to explain the features that will be developed. Including as many references as possible will facilitate the work of the development team.
You may view an example of a GDD that has already implemented the new format through the link below:
Do you want to become a Game Designer but don’t know where to start?
A great way to begin is by designing a tabletop or board game. Why? Because you can create a prototype using paper and simple objects, without needing any programming or software.
Choose a board game that is easy to learn, most importantly, pick a game you enjoy. For example: Snake and Ladder.
Take notes on what you like about the game.
Identify the objects needed to play your designed game. For example: Dice, Token.
Determine your target players. For example: Single-player or multiplayer, children, teenagers, or adults.
Write down the features you want to add, remove, or modify to make the game more interesting. For example: Making the game simpler to play and more engaging.
Create a rough prototype by drawing the game board and rules on paper card (if possible) or using objects to represent features in your design. For example: Using LEGO pieces.
Test your game repeatedly. If a feature makes the game unplayable, remove or modify it as needed.
Keep testing until you can play the game from start to finish.
Document your process and start adding new features that can make the game more fun.
Try playing with other people once you feel the prototype is ready.
Gather feedback from other players and update your design.
Continue iterating until the game plays smoothly based on their feedback.
Keep improving until you have created a completely new game.
This iteration process can continue as long as needed until the game reaches its optimal stage.
Avoid over-engineering or overthinking that may take the game too far from its original concept (e.g., changing its genre entirely).
At this stage, you should be able to create a Game Design Document (GDD) based on your experience from testing and player feedback.
Congratulations, you are now a Game Designer!
Implementation
An example of a game I have worked on using this technique is a simplified version of Ludo, designed to make the gameplay much faster.
