Spherica: 3D Game Development
Daven Sanassy
University of Kent
()
Gavin Stannard
University of Kent
()
Nicholas Wilson
University of Kent
()
Abstract
This document details the background, design, development and implementation of Spherica, an interactive 3D computer game. The application makes use of a variety of free open-source, web-based and platform independent technologies in order to produce a universally deployable implementation of a unique game concept. Efforts have been made to emulate techniques and technologies used in a real-world game development environment.
1. Introduction
The Computer Games industry is a sizeable one, and is responsible for a fair portion of worldwide media sales. The demand for video games is ever growing as more and more people become computer literate and the technology becomes more affordable. As such, innovation is essential in this competitive field, as developers struggle to release original titles that make use of the latest technologies in order to win as great a market share as possible.
Although development of a full-scale game with any chance of competing in this market would take far more time, resources and experience than is feasible for a final-year project, it is plausible to design and produce an original game that has the potential to be developed into something far greater. That was the aim of this project.
When on a tight budget of time and money, small, simple games have proven to be the most addictive, so it was decided to produce a simple 3D puzzle game, later named Spherica.
Although Spherica is not commercially driven, the main principles of game development were applied in the production of the game. The need for a solid game concept, efficient and high quality implementation and testing are just a few examples of the crucial processes which make up game development.
1.1 Game Industry Background
Creation of computer games is undertaken by game developers either working on their own or as a team. Typical modern commercial games are built in large development teams with each developer being assigned a specific task [1]. The key roles of the developers can vary between Game Designers, Engine Programmers, Gameplay Programmers, Artists to Musicians. The number of developers in each team will be determined by how big and demanding the game is. Modern games can cost anywhere between $1 million and $15 million to develop, taking several years from the point the game is on the drawing board till it reaches the market.
Games are first thoroughly designed and documented by the Games Designers followed by initial prototypes which are created by the programmers. The game’s design is then readjusted in light of any discoveries found during prototyping and it is only then that the development stage begins. Milestones are set, for each stage of development, at the point where the game has reached certain levels of requirements. This way of proceeding enables the game publishers to monitor the game project as it is being developed. If there is any delay in reaching a milestone, game development can often slip into “crunch time”. Crunch time, is the point, just before release, where many of the game developers in the team will work extremely long hours till the successful completion of the game.
‘Indie’ games developers are independent small teams which survive on low budgets and work over the internet. They are not financed and controlled by a game publisher and hence are in sole creative control of their games and are able to self publish them over the Internet or sell them to a publisher.
2. Project Aims
The primary motivation in this project was to gain experience in the design and development of 3D and networked applications in a low-level language whilst emulating a realistic software development scenario. A field that encompasses these goals is 3D game development, and was hence our chosen project area.
Great care was taken in deciding on the exact type and style of game, with the following requirements:
2.1 Portability
From the outset, it was decided to make the game usable on as many platforms as possible. Naturally, this brought platform independent technologies such as Java into the limelight. However, multi-platform development can be complicated, so development proceeded with portability in mind, but was based and tested on a single platform.
2.2 Performance
A dominant design factor in most applications, and in particular games, is the game performance, including responsiveness to user input, and low latency over network connections. For example, this removed Java from the list of possible 3D graphics rendering options; through experience with Java3D, it has shown tendencies to be too unresponsive for our needs. The major considerations were performance versus portability, and the final choices are outlined in Section 3, Technical Background.
2.3 Ease of use
Any application benefits from a clear and intuitive user interface. Games in particular must take this into consideration as their task is to maintain user interest as strongly and for as long as possible.
2.4 Entertainment Value
A game must be enjoyable in order to be successful. Unlike other types of computer applications, gaming is a leisure activity, where the user chooses to play a game, whereas a word processing package would often be used for work, where the user has no choice but to use it. Hence, a game must be enjoyable and rewarding enough for the player to want to play it, ideally repeatedly over a period of time.
2.5 Originality
The games industry is a large and ever evolving one, with games of various scales and detail released every month. The great challenge to game developers is to produce an original game concept that raises their product above the competition. In order to simulate this real-world factor, it was decided to develop an original game idea. This adds some value to the project, rather than it simply being a reinvention of an existing game.
3. Technical Background
From the outset, we wanted the game content to be royalty free, using free open source software where possible and to be platform independent in terms of the major consumer operating systems. Due to the time constraints of this project however, the main priority was to get the game to work reliably and perform respectably on Windows, as this is the major gaming operating system. The compatibility for other operating systems was factored into the game implementation, however it was not feasible on our time scale, to fully test these systems without influencing the quality of testing on the primary operating system.
3.1 Technical choices
DirectX[2] is generally the API of choice for game developers, with its benefits being an all in one package (containing graphics, input, sound, etc.) and is highly optimised for Windows (compared to the other available libraries). On the other hand, it also locks the developer into Windows. Many top game developers abstract their game from the API such that it can use other libraries, e.g. Epic Games Unreal Technology [3] allows for many different graphics rendering APIs, notably OpenGL [4] and Direct3D [2], meaning their games can run on various different operating systems.
We, however, decided to go for a purely cross-platform solution; OpenGL (Open Graphics Library) fits the bill, as an implementation is provided for all major operating systems. The downside of OpenGL is that it is purely a graphics hardware abstraction layer, comparable to just the Direct3D aspect of DirectX; therefore libraries for the other aspects of game development such as sound and networking were required. For this reason it was decided to use G3D (Graphics 3D [5]) - a free, open source 3D graphics library, wrapping OpenGL, and importantly, is built upon SDL (Simple DirectMedia Layer [6]) which provides functionality for user input, sound and networking.
3.2 Programming Language
C++ [18] is the most common professional game development language; it combines the speed and low level memory access of C with object oriented techniques which become extremely useful in large scale game projects. C++ is a superset of C, which conveniently means that C code can be compiled and used within C++ solutions; this allows C++ to be considered a multi-paradigm programming language [7], meaning that many different programming styles can be implemented in this versatile language. C++ has a cross-platform library built-in called the STL (Standard Template Library [8]) containing algorithms, container data structures and their iterators. The language elegantly supports generics using “templates”.
3.3 Graphical Front-End
Any worthwhile game requires a pre-game menu system of some description in order for the user to configure the application to their needs and choose between game modes. With the time constraints of the project becoming ever tighter, it was decided to produce our configuration system in Java [9], a language familiar to the group, in which we felt we would be able to rapidly implement a viable solution.
The front-end is responsible for allowing the user to view and edit game options, as well as view, configure, start or join a single-player or networked game. This functionality is presented in a consistent window-style interface, using standardised UI components to ensure ease of use by anyone who is familiar with common graphical interfaces. The Grand Theft Auto 2 front-end [Appendix A] is a good example of such an approach and formed the basis of our design methodology.
3.4 Game Engine
Most game developers use a game engine as a base to start developing their games; we used G3D (Graphics 3D). G3D is a free commercial-grade C++ 3D Engine available as open source (BSD License [10]), but unlike a traditional game engine it contains no specific game data structures such as a scenegraph; G3D is essentially an abstraction layer to SDL and an OpenGL wrapper in one. From a platform independence viewpoint, G3D code will compile across three different platforms: Windows, Linux x86 and Mac OS X, making it the perfect choice for this project.
3.5 Development Environment
Visual C++ 7.1 [11] was chosen as the development environment because is the current Windows and XBOX game industry standard development software. It features IntelliSense (code auto completion) and powerful debugging functionality. The VC++ 7.1 compiler is capable of producing highly optimised code, for instance “inline” is automatically inserted by the compiler to reduce function call overheads on macro like functions at the expense of compiled binary size.
4. Design & Methodology
4.1 Game Design
A Spherica player takes charge of a central sphere in a 3D world. This sphere and any others attached to it may be rotated through keyboard interaction. Moving the mouse rotates your view around the central sphere. Holding the left mouse button whilst moving the mouse forwards and backwards controls zooming.
As the game progresses, spheres of differing colours enter the environment from random positions. They move directly toward the central sphere until they collide with it or another sphere. When a sphere becomes connected to the central sphere, directly or via other spheres, it 'sticks' and hence rotates under the user’s control.
The aim of the game is to link together spheres of the same colour. Linking three or more spheres in this way results in them being removed from the game, and points being added to the player’s score. This linking also results in the creation of a 'special' sphere, which enters the game like any other. However, the aim is to get the special sphere into direct contact with the central sphere. This is the only way to destroy special spheres and gives you many more points than linking normal spheres.
Special spheres also have another game-influencing property. If several special spheres are linked together before they impact the central sphere, the player is rewarded with a large points bonus, which increases exponentially with the number of specials linked together. As such, although it is a safe tactic to get the specials to the centre as quickly as possible, going for a special combo can be well worth it if you can pull it off. This element of risk vs reward ensures variation in each player’s tactics and hence introduces some sense of ‘skill’ into the game.
4.2 Network Design
An aim of this project was to allow the game to be played in some sort of ‘multiplayer’ mode. This means that two (or more) players are able to play the game simultaneously, and that their actions will affect the other player’s game in some way. The players will compete toward some winning condition(s), which when met will result in the game ending with for both players, with one announced the ‘winner’.
Obviously, for two players to play together, they must either be able to both control their respective game environment from the same PC, or through some networked system be able to play from separate machines. Since the controls for this game require each player to have a mouse, the networked approach is the one we will be taking.
Existing multiplayer games which operate in a similar manner tend to support several different methods of establishing connections between clients for networked play. Almost all games use a server-client architecture, in which one machine is designated the server, and proceeds to accept and handle incoming connections from client machines that intend to play in the server’s game. Game logic and processing is often handled by the server, and the client application is responsible for interacting with its user, presenting the game state as instructed by the server, and notifying the server of user input events.