Author: Lao Jiu – technology big millet

Developing Games in Java

Socializing: Zhihu

Public account: Lao Jiu School (Surprise for newcomers)

Special statement: the original is not easy, without authorization shall not be reproduced or copied, if you need to reproduce can contact the author authorized

Online game development team

Online game development teams are a weird bunch because they need a combination of pie-in-the-sky creativity and down-to-Earth technology. This requires the team to be individually different, but it needs to be effective. For example, A is an interesting and creative person, so he can design very complex and elegant games. B, on the other hand, is a boring, results-oriented person who likes to code and discuss technical details. There is A conflict between the two, and most of the time A wins, although B should be right — it’s an old question: theory versus practice!

Personality issues on a team can occur throughout the development process, including designers, coders, artists, and network administrators. Harmony between these two types of people is the core of managing the team. For example, Type A people play the rudder of the creative engine. Type B acting brings Type A ideas from theory back to reality. The effort involved in this administration is enormous; A development team is difficult to drive because it is rare to encounter brain-challenged ones. The overall steps for managing a team are planned, coded, drawn and tested. These responsibilities ultimately fall on the producer and PM roles.

Principles of theory and practice

We will discuss the relationship between theory (design) and practice (development) below, mainly to give some principles.

  • Don’t build for the long term, that is, don’t try to make the code very extensible and maintainable, and if the development team pays attention to this, it will reduce the financial risk of the game.
  • We cannot focus on all quality of service, especially MTBF (mean time to failure). For example, a server failure can turn off thousands of users, while a client failure can irritate players and increase confusion.
  • Don’t underestimate the complexity of the task. Moving parts can lead to complex nonlinearity, and MMP games have many moving parts. In short, an MMP game is three times as complex as a standard game, and it’s 10 times as complex.
  • Don’t underestimate testing and concurrency
  • Overestimating the initial portion of the game and how long players spend
  • Spending too much time on game mechanics rather than game social mechanics makes it hard for players to find and keep players from playing the game against each other
  • Don’t forget that CS (customer service) is just as important as design and development, and low customer satisfaction increases the cost of running a game
  • Just think of it as creating a game, regardless of the social context in which the game takes place
  • Confidence is important, but exercising control is even more important: because online games are huge projects that can easily go unsupervised, don’t trust any promises, just track everything
  • Problems do not resolve themselves: personality conflicts must be resolved quickly, and differentiated entanglement is not acceptable. Conflicts are very valuable if they are resolved well. Tension is a great tool, if used properly. Of course it all depends on the maturity of the team. Remember: lichen doesn’t grow on Rolling Stones!
  • Since Everything in the game changes, be careful of hard-code
  • Keep repeating to yourself, “Tools! Tools! We need a lot of Tools And library code. Spend money on really cool tools to create more efficient GUI interfaces and force coders to use them.
  • If we focus on gameplay (game mechanics) rather than participation (community mechanics), then players will find our game boring after 20 hours a week. Only community mechanics can retain players

design

Most online games are developed as follows:

  • A small team approached a publisher with a project
  • The publisher agrees to the project after looking at the basic form and development schedule
  • The small team began to design the document
  • While the design document was not yet complete, the team began coding
  • The design document was not yet complete, but the programmers had already surpassed the designers, so the designers had to modify the original design.
  • About a year later, the design document had not been completed, but the programmers had already produced the alpha version of the game world, and the data had been completed, and everyone had participated in the construction behavior. Because this is more interesting behavior than design
  • After about a year and a half, some people realized that most of the game mechanics were not implemented according to the spec and were written directly into the program, but the design document was not yet complete. There was a steady stream of cool startup screens and basic “walk and talk” demos for senior management.
  • It takes about 21 to 30 months to reach the Beta design requirements of the first three months. At this point, the team realized that the plan was seriously delayed, but people were still designing the combat mechanics (magic, fighting, sieges, trade tricks, etc.), as well as database items for thousands of objects, such as maps, buildings, weapons, armor, etc. The development team decided to report the delay to management — we needed more artists and more programmers to get the game done in 36 months.
  • By the 36-month delivery time, the development team found that there were a number of bugs that needed fixing according to the design requirements. In order for game mechanics to work, previous mechanics need to be removed, including data design. So the management was not happy, but having already invested $6-8 million, they had to agree to delay.
  • Some 48 months later, and at a cost of $10 million, the half-featured game was finally ready, and the company ran the game, albeit with 1,000 bugs and a shaky technology implementation.

How to solve this problem?

In process execution:

  • Two design
  • A construct!

Design attitude

Also called proposal, treatment, or game Outline. However, all attitudes contain the following:

  • Genre — is it fantasy or shooting
  • Image appearance – is it a full 3D appearance, or does it require a graphics accelerator card? Is it a software presentation? Is it plastic or anime?
  • Interface style – This is the interface shown to the player
  • Engine – paid, use free, write your own database – use free, commercial data such as Oracle or SQL Server etc
  • Target audience — Who uses the game? Technocrats, moderates, or the general public? Does the game need to accommodate multiple levels of audience?
  • Client platform – includes development platform and port platform. Make it clear whether you’re targeting PC web viewers directly, or all client access devices: Xbox and PlayStation 2 or mobile users.
  • Host platform – What hardware and software are used for the server, including physical configuration, operating system version, development environment, database, and so on
  • Is the script licensed or original
  • Playability — Describing the player’s playability experience, describing key playability and player interface elements that set us apart from our competitors
  • Novice experience – For PW, a novice experience’s understanding of the game’s basic features and console functionality is critical. The novice experience will help us practice and entice players to play.
  • Competition – Do similar projects already exist in the market? How competitive are our games against them? How much money did it cost to make the game? Why are our games better?
  • Employees and their qualifications — How many people are needed on the team at the beginning of game development, in the middle of game development, and at the end of game development? Any special needs? What are the basic descriptions and qualifications for these jobs?
  • Core team – who is the producer/project manager, who leads the service/network engineer, who leads the database designer/database administrator, who leads the design? What qualifications do they need to develop this project?
  • Schedule – The initial estimated time for development and the test schedule. The average game is only 80% functional within six months, but the EXECUTIVE director will want to estimate the payback schedule. So a smart project manager will estimate at least six months of revenue benefit.
  • Budget – Initial budget below the total cost of building the game and running it. It includes: personnel salaries, software and hardware costs and testing costs, running server hardware costs, bandwidth costs, network maintenance costs; There are also CS/ player relationship management costs.

Here are the preliminary design steps

  • Background – The history of the game, why is the player being virtual in this PW
  • Player interface Design
  • Character racial classification, specific abilities, strengths and weaknesses
  • Character creation and growth
  • The location and environment of the game world, including all natural and man-made terrain
  • All game mechanics, including magic, combat, trade skills, and other related mechanics
  • Graphic Style Guide (The Art Bible)
  • List of all items and artifacts
  • Monster types and a list of monsters in the game
  • Fixed tasks that need to be detailed
  • List of people – number of designers and artists, when are they needed
  • First milestone, first delivery milestone, and when
  • The time when the first overall development and budget was launched

Here is the second design — the preliminary technical design. Of course the technical design must have a technical design document, which is completely separate from the game design document. The technical design document is based on the game design document, and the technical designer has to spend a lot of time with the game designer before writing the design document.

Preliminary technical design

  • Software – operating system environment (client and server), programming language and scripting language, what database will you program with, graphics software and modeling software
  • Tools — Which tools to use for building, from game world builders to CS and in-game GM tools.
  • Game server configuration and environment — You need to indicate the number of physical servers (server clusters), the cost of acquiring these hardware, how many online users the first cluster supports, and the physical space per machine (memory and disk size).
  • Bandwidth – How many bits per player per second to estimate the bandwidth required by the server cluster
  • Task list – a detailed list of codes and time periods
  • Feature list — All interfaces and game mechanic features, with priority first
  • List of people – how many programmers, engineers, and database administrators worked on the project
  • Fist cuts — Initial estimate milestones, delivery milestones, and when; And preliminary estimates of all
  • Prototype list – Determine which elements are primitives and which elements you want to demo in a rough framework?
  • Technical risk list – which hardware and software elements could be bottlenecks to development that could result in delivery delays and failures
  • The CCP — The overall course of changes to The game and when The technical designs were submitted, reviewed, approved and implemented.

After the initial technical design documentation stage is completed, a large number of technical documentation will be produced. Thousands of small task documents that are sliced and diced into hundreds of pages in project management forms. For example, the Project documentation generated by MS’s Project software can run to over 200 pages for a single role-playing game!

The last

Remember to give dashu ❤️ attention + like + collect + comment + forward ❤️

Author: Lao Jiu School – technology big millet

Copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please indicate the source.