Our game is now complete! We've implemented all the features that our game requires, including sound and visual effects, and we've also considered the commercial aspects of our game and examined how to benefit financially from our hard work.
Because this is a practical guide book, we jumped straight into the development of our game in Chapter 2, Let's make a game!. Quite understandably, we just wanted to learn the required skills and get our game up and running. After all, rolling up our sleeves and getting our hands dirty is always good fun when it comes to game development!
Although it's fun to jump in and to start creating a game, when first learning the tools of the trade, in practice, it's not the most advisable way to develop a successful game—it's a good idea to put some plans into place first and also to ensure that we have all the right tools for the job.
In this final section of the book, we'll take a quick look at the basics of planning a game, and we'll also consider some of the third-party tools and resources that can help us in the development of our games. Finally, we'll reflect upon some of the legal issues that we, as developers, must take into account before presenting our completed game to the public.
The topics we'll be investigating are:
- The planning process
- Third-party tools
- Third-party assets
- Additional resources
- Legal issues
- Progressing with Stencyl game development
Planning the development of a video game is a contentious topic—every developer has his or her own ideas about planning, and many books have been written on this topic! We're going to have a quick look at how professional game studios approach the planning of a video game, and then we'll examine some of the more practical aspects that will benefit an independent or hobbyist game developer.
Professional game studios follow a very formal planning process using a game design document (GDD) that specifies every aspect of a game's design in great detail. It will include all the information required to aid the smooth running of a game development project and although a GDD is usually considered to be a living document —it is expected to be updated as the project progresses—work will not start on the development of a game until the initial GDD has been completed and approved by the senior management.
A complex game design document is probably somewhat excessive for a lone, independent developer, and especially for a hobbyist, but it's certainly a good idea to do some planning before diving into a project. The contents of a game design document will vary within each organization, but it is typical for the following items to be included:
- Game concept
- Feature set
- Genre
- Target audience
- Game flow
- Gameplay
- Mechanics
- Objectives
The given list is certainly not exhaustive—a completed game design document will contain many additional headings, each with multiple subheadings. However, rather than re-inventing the wheel and creating our own GDD, we can take advantage of the many online resources related to the planning of games, and utilize some of the excellent game design document templates available for downloading from the Internet.
Note
A selection of planning resources and links for downloadable game design document templates can be found on the following web page: thestencylblog.com/planning.
Rather than investigating the finer details of a professional game design document, let's examine some of the aspects of planning that can help beginners to achieve their goals.
Some developers prefer to start with a pencil and paper (or the electronic equivalent) and sketch out their ideas, so they can visualize the game before firing up their design and development tools. However, many developers prefer to start by creating a working prototype of the game, so they can very quickly get a feel of whether or not their idea is viable. Let's examine some of the advantages and disadvantages of these two approaches.
An individual, or team, with good graphics or drawing skills may have very firm ideas about the layout and appearance of the game. These visually presented ideas may be the driving force for the production of the game, and they will provide a good start, as the ideas will enable the developer to understand what to aim for as their final goal.
However, one of the risks for the small-scale developer of planning the graphics in great detail is that the mechanics required for the basic concept of the game may be too advanced for the skills of the developer. For example, if the plan is to have a character that travels at high speed on a roller coaster style landscape, the development of the game may fail in its very early stages if the developer has not already proven that this type of player movement can be achieved with the available development tools. Generally, it's not a good idea to spend too much time on creating detailed graphics until the gameplay mechanics have been demonstrated in a working prototype.
When initially planning our Monkey Run game, the initial concept drawing was created with graphics software, and the artwork is no more than outline drawings, as can be seen in the following screenshot:
At this stage, there is no indication of a theme for the game—it's just a platform game in which the player will traverse a landscape while collecting objects and avoiding enemies.
There's also an idea that there will be some sort of time limit applied to the game but, so far, we cannot see any evidence of a jungle!
A game may start its life as a prototype—a very basic, but workable version of the game that enables the developer to prove that the development of the concept into a working game is feasible. Very often, a prototype game will have basic graphics, and is simply used as a tool for the developer to create the type of player movement that is required. For example, if it's a game that is going to be set in space, the developer will want to be sure that the physics of the game will work as planned before spending excessive amounts of time designing the graphics.
Creating a working prototype enables the developer to ensure that their skills are a good match for the requirements of the game. If the developer can't create the mechanics for the game then the development will be abandoned at the very early stages!
Developing games should be fun! Although it's a contentious topic, it has been suggested that following strict routines and plans is not necessarily the best way for a lone developer, or very small team, to make progress and, ultimately, create a completed product ready for publishing. Different people have different ideas about the best way to get the job done but the following tips are for beginners to help them on their way.
Many new developers fall into the trap of trying to develop a blockbuster game on their first attempt, which often leads to disillusionment with the development tools.
Regular visitors to any online game development discussion forum will be familiar with reading comments from the excited beginner developer who has ideas for the most amazing game, only to read the follow-up comments of disappointment and frustration a few days or weeks later, when the same new developer realizes that game development requires a lot more hard work and planning than initially anticipated!
Before diving into a huge project, start with smaller manageable games that will enable you to build up a repertoire of skills that will, ultimately, lead you to being able to create the masterpiece that you have dreamed about.
For example, rather than trying to develop a huge, multilevel shoot-em-up game, start by creating a basic one-level game to prove that the gameplay mechanics are achievable, and that the game is fun to play. When the game concept is proven to work in practice, have a go at adding the onscreen scoring information, and then consider implementing the introduction screen. Having these skills in place helps to ensure that, when it comes to working on a larger project, there won't be delays and disappointments as numerous small problems arise.
During the initial stages of development, consider using placeholder graphics—temporary graphics that are used to get the development process up and running quickly. Of course, some developers are very artistically talented and may be able to create appropriate graphics quickly but, in many cases, the creation of the graphics for a game can cause frustration and delays in the development process.
Placeholder graphics might consist of simple shapes such as rectangles and circles, or they might be third-party graphics that have been legally obtained from the Internet—see the following section entitled Third-party assets for some suggestions as to where to find readily available resources that can be used for these purposes.
When initially planning the Monkey Run game, a mixture of placeholder and readymade third-party graphics were used. We can see in the following screenshot, which shows a very early working prototype of the game, that the tileset is the same one that we used in the final game, but the actors are basic placeholder shapes:
In this case, the player is a rectangle, and the collectible objects are circles. It was only at a later stage of development, after the platform mechanics were proven to work, that the basic actor shapes were replaced by the high-quality monkey and fruit graphics, and the animations were added.
The reason for immediately implementing the tileset was that it was very easily accessible from StencylForge, and was known to be available for use in commercial projects free of charge—an important criterion for this project! The style of the tileset led to further development of the jungle theme and, while the original concept for the game was a platform in which the player collects objects and avoids enemies, the style of the game was, in fact, influenced by the availability of the tileset! Don't forget that StencylForge is an excellent resource for actors and other resources, as well as tilesets.
Rather than setting large, unspecific goals, such as completing the development of level one in a couple of weeks, consider specifying smaller milestones and recording them in a notepad or a spreadsheet. For example, some of the minor milestones specified for the development of Monkey Run are shown in the following table:
Each of the milestones stated in the previous table is small and realistic and, when each milestone was reached, a sense of achievement was experienced as the Done boxes were checked.
It's also a good idea, where possible, to set goals that have fun targets dispersed between the less-fun targets. If your idea of fun is to create graphics, then don't spend 10 consecutive days creating graphics, leaving the less-fun milestones to the end of the project! Try to work on smaller graphics-related tasks between some of the tasks that are, perhaps, less enjoyable. Working like this ensures that there is still some fun to be had regularly throughout the development process.
Don't become disheartened when difficulties arise! When an apparently insurmountable problem raises its ugly head, take a step back and consider your options, which include:
- Asking for help from other Stencyl developers—the official Stencyl forums are a great place to start, and the Stencyl developer community is very welcoming and generous: community.stencyl.com
- Working on a different part of the project, and coming back to the problem at a later time (perhaps when help has been provided on the Stencyl forums)
- Trying a completely different way of solving the problem—think out of the box
- Eliminating the problem from the game, and introducing an alternative feature
- Taking a break—play some video games and hope for inspiration
It's very rare that a problem cannot be resolved one way or another, so be patient, take a deep breath and relax—game development should be fun.