Game development is my recent hobby. I am going to approach it as a project and apply enterprise architecture principals to make things clearer.
The plan is to write a game to understand the process. I want to learn anything there is to know about game development, the good, the bad and the ugly. Hopefully I will get some result and enjoy the process.
To organize everything I will use Zachman framework. WARNING: use of said framework leads to OCD and excessive knowledge sharing... or the other way around I am still not clear on that
It is a work in progress, so please bear with me...
- this indicates a decision point. If a different path is taken it may have a tremendous downstream effect. The higher the decision point is in the framework the more difficult it will be to adopt it without breaking anything.
Executive Summary (Planner's perspective)
- I want to build my own computer game because I have never done it before. Properly, that is.
- I want to build a game that I want to play.
- I want to learn about the game development process.
- If I build a game I want to share it with others and get feedback.
- Budget: 0£.
- Expected return: 0£ (+ a lot of knowledge).
- Timeframe: 6 months. It is an artificial target but it is important to have a time horizon.
The list of terms:
- Enterprise design - the detailed blue-print of the initiative. It is essentially what you are reading right now.
- Game - in our context it is a game played using a computer.
- User - the person that plays the game.
The following activities will need to be performed to address the motivations:
- Produce enterprise design.
- Develop the game.
- Distribute the game to the users.
- Gain feedback, reflect on the progress made and knowledge gained and plan the next iteration.
- Initiative is started. It has already happened as I am developing the game by planning it first (unconventional, I know). So I just leave it here for history.
- Enterprise design is ready.
- The game is in alpha state.
- The game is in beta state.
- Feedback is received.
For this initiative no marketing research will be performed to understand the game's ideal target audience.
These are the roles that are required to perform the activities:
- Enterprise architect - to produce the enterprise design.
- Game developer - to develop the game.
- Game publisher - to distribute the game.
- Community manager - to receive the feedback.
Enterprise design is going to be located on this web page.
The game will be develop for PC Windows since this is what I have access to.
If I get to the point where the game is actually playable I will make it available for download via the Internet.
The 2 ways of communication for the initiative are the following:
(Everything below this line is under construction)
Business Model (Owner's perspective)
- I want to go through each activity and understand if I can perform it and if not what the cost of outsourcing will be.
This will form the ontology.
- Game design
- Game design document - is a highly descriptive living design document of the game design for a video game
- High concept - the short description of the game
- Pitch - summary of the game selling points
- Concept - detailed description of the game
- Game's genre
- Game setting
- Game story
- Proof of concept - it is a game prototype
- RAD tools - a toolkit used for prototyping during pre-production
- Concept art - is a form of illustration where the main goal is to convey a visual representation of the game
- Gameplay - is the specific way in which players interact with a game
- Alpha - the version of the game that is stable enough and playable but does not contain all the planned features.
- Beta - the version of the game that has all the planned features working but requires QA.
- Bugs - the problems in the game that need to be fixed. Otherwise they are features.
A complete set of activities that are required to produce a game. It is organized in the form of the taxonomy.
- Game design
- Plan the idea. Choose game's genre, settings, objectives
- Research similar games on the market
- Select the target audience
- Define revenue model
- Define the game world structure, characters and background story
- Identify game world mechanics
- Identify I/O options for the game
- Define how I/O works with the game world
- Evaluate and test the design
- Approve the design
- Prototype development
- Concept art development
- Production planning
- Schedule planning
- Budget planning
- Draft initial game design document
- Art production
- Audio production
- Game programming
- 3D graphics programming
- AI programming
- Network programming
- RAD tools and utilities development
- Game testing. The process is: identification, reporting, analysis, verification.
- Functionality testing
- Compliance testing
- Compatibility testing
- Localization testing
- Soak testing
- Beta testing
- Regression testing
- Load testing
- Multiplayer testing
- Gameplay design
- Game polishing. This is a set of activities to improve the already working parts of the game. Highly uncommon for pure software development.
- Game distribution
- Gather feedback.
- Develop patch.
- Distribute patch.
- Game maintenance. In case the game is MMO the game requires constant maintenance.
- Game community management
- Supporting activities
These are stakeholders that are involved into the initiative.
First question is who will play the game? What audience do I target? Each of the following restrictions associated with people will have an affect on how the game is designed and implemented:
The game will support only English language.
- Language. If we restrict ourselves to English language we can live with just ASCII. If there are no restrictions imposed our game must support Unicode.
- Disabilities. Every single one is important to consider as they will have a huge impact on what I can and cannot do.
- Physical. Do we require a user to use a keyboard or a mouse and to what extent?
- Blindness. There are games for blind people. They are obviously not your usual 3D MMOs. It is a whole different world.
- Low vision, including colour blindness. If taken into account some of the game objectives cannot be indicated by colours for example. Do we want to support high contrast colours?
- Hearing and speech impairments. Objectives cannot be just spoken, there must be titles. You may not require internal voice communication and simple chat must be available.
- Learning disabilities. Not everyone is going to be good at the game. Do we want a wide diversity of objectives suitable for different audience?
No support for players with disabilities will be explicitly provided.
Range of possible software and hardware for the game:
- PC Windows
- PC Linux
- Play Station
- Available to download from Internet. There are options here for the actual host and method of communication.
- Burned on CD/DVD/Blu-ray and shipped. Not everyone can download gigabytes and would prefer to buy an image of the game.
- Floppy disks. Just kidding :)
Visions: group play in PvE and PvP in RPG setting
Mission: develop a game that will let people to group for PvE and PvP and enjoy the gameplay from different perspectives with a sense of progress and achievement
- Anyone can join the game but registration will be required
- Groups need to be assembled automatically
- If there is not enough players there should be NPC available to group with
This is a common vocabulary for the initiative. It is very important to get it right especially if there is a team of people involved. Making concepts explicit helps to avoid any assumptions and misunderstandings.
- Player - the user's avatar in the game
- Environment - the artificial game world
- Group - the group of player in the same environment
- PvP - player vs. player. A player can compete against other players
- PvE - player vs. environment. A player can overcome challenges in the form of computer controlled NPC
- Non-player character (aka NPC, aka mob) - a character that is not controlled by the user
- Perspective - variation of player experience achieved through different activities
- Objective - the goal an environment presents to the player as a challenge
- Progress - quantifiable way to show that the player becomes "better" in time
- Achievement - quantifiable way to show that the player has "succeeded" in the game
- World - the collection of all the objects in the game world
- World (client's copy) - the view of the world from the client's perspective. Most likely does not include everything
- UI - the view of the World as presented to the user
- Sound - the sound representation of the World
- Database - the storage for snapshot of the World
- Commands - the activities, translated to the language of the world, that need to be executed. These are triggered by events
- World synchronization - the process that align the World with the client's copy
- Physics engine - the sub-system that moves World objects
- Keyboard - a user pressed a key
- Mouse - a user clicked the mouse
- Client - the user's computer
- Server - the computer that governs the World
- User - the person that plays the game
- AI engine - the sub-system that is responsible for NPC behaviour
- AI - motivation of non-player characters
- Physics - the physical rules of the World
QA - the modern approach is to make alpha and beta versions of the game available to players.
- Player joins the game
- Player reads about environment
- Player chooses an environment
- Player reads about perspective
- Player chooses a perspective
- Player requests to joins a group
- Player joins a group
- Player completes set objectives
- Player receives the rewards
- Group is assembled and moved to the environment
- Player leaves the group
- Player joins an existing group
- NPC joins an existing group
- Player adds NPC to the group
My current understanding of what the game will consists of
- The user installed the game
- Player joined the game
- Player chose the environment
- Player chose the perspective
- A bug is found in the game that needs to be urgently fixed. I want to make this one explicit. What will happen if a major problem is discovered in the game that makes it unplayable?
- Non-urgent bug was found
Security. How much can we trust the players? The level of trust will have an impact on game implementation.
- Start screen
- Environment screen
- Perspective screen
The language of choice for me is C++. Games can be written in many different languages. But this is not a question of practicality but rather a choice of the most powerful tool there is. Hence C++.
I started gathering some information on how each component can be implemented. There is no silver bullet of course. But there are some things I would like to do so here it goes:
- Data serialization between client and server - Google protocol buffers. I have some nice experience using it in Java and C#
- Memory management - boost::heap - all the good things have already been done
- Strings - there is a whole world of problems out there if one wants to play nicely with Unicode. I haven't decided yet what I want to do here.
- Database - most likely will try MySQL to start with. It's a good database, which is free
- Logging - the new addition in 1.54.0 version of Boost
Essentially at this point I need to learn C++, libraries and technologies necessary to program the game.
- UI, Sound - DirectX
- Physics - eventually I want my own. But will try Tokamak first
- AI - my precious!!! There seems to be no ready to use engine for that
- Testing frameworks
- POCO C++ Libraries These are some nice libraries that may become useful.
Player's perspective (Functioning enterprise)