MyUberConcept

Tag: gamedesigndocument

  • The Journey of building a team for my first game project

    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:

    1. Since none of us is capable of animating objects, the game doesn’t require rigs or complex animations.
    2. Since none of us is skilled in art, the game doesn’t require artwork.
    3. We don’t want to spend too much time working on level design, so the game doesn’t need complex level layouts.
    4. Our target is a working prototype, so the game doesn’t require progression systems.
    5. We want our game to be flexible, it should be playable with both a regular controller and a touchscreen.
    6. 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:

    https://gamebanana.com/members/69858

    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.

    Gunner Fury GDD – Download

    Game Asset

    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.

    Gunner Fury Asset by deepeyes on Sketchfab

    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:

    https://www.moddb.com/games/gunner-fury

  • How major game studios operate their games

    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.

     

     

  • How to prepare before writing a game design document

    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.

  • Simple vs Detailed game design document

    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.
    • Download – Simple GDD

    Detailed GDD:

    • 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.
    • Download – Detailed GDD

  • How to manage Game Asset in a game design document

    Function: 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:

  • How to write an Effective game design document

    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):

    1. 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
    2. 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.
    3. 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:

    View Document

  • A Beginner’s Guide to Becoming a Game Designer

    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.

    1. Choose a board game that is easy to learn, most importantly, pick a game you enjoy. For example: Snake and Ladder.
    2. Take notes on what you like about the game.
    3. Identify the objects needed to play your designed game. For example: Dice, Token.
    4. Determine your target players. For example: Single-player or multiplayer, children, teenagers, or adults.
    5. 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.
    6. 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.
    7. Test your game repeatedly. If a feature makes the game unplayable, remove or modify it as needed.
    8. Keep testing until you can play the game from start to finish.
    9. Document your process and start adding new features that can make the game more fun.
    10. Try playing with other people once you feel the prototype is ready.
    11. Gather feedback from other players and update your design.
    12. Continue iterating until the game plays smoothly based on their feedback.
    13. Keep improving until you have created a completely new game.
    14. This iteration process can continue as long as needed until the game reaches its optimal stage.
    15. Avoid over-engineering or overthinking that may take the game too far from its original concept (e.g., changing its genre entirely).
    16. 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.

    The procedure I have carried out:

    1. Reduced the board size by 60%.
    2. Applied 60% of the original game’s rules.
    3. Used 50% of the original game’s tokens.

    You can try the game at the following link:

    https://web.telegram.org/a/#7340377715