Strides Interactive

What’s your focus?Filed Under: Weekly Tuesday Dose of goodness

In this article, I’ll talk about how to penetrate a game project, getting it to start without having an extremely large scope on your head.

Now, this will also apply to new game developers as well.

In games, it’s very much alike movies, there’re many many things that needs to be done with a limited budget. So, what’s your focus?

Read on….

Many a time, developers, whether they’re project leads or programmers can suddenly be flooded with a myriad of requirements which they might not be able to handle.

Let’s take a look at a general list of game components:

1) Graphics
2) Audio
3) Input
4) Network
5) Database and Entity Management
6) Environment (Physics and Terrain)

These are probably the highest levels in the list of requirements. At a glance, certain decision needs to be made in order quickly zoom into focus.

One of the major decisions would be what language to develop in, which engine to use, what other APIs can work with the engine and so on. This step is to reduce the amount of work required by the developers. In an ideal case, naturally, a self-made game engine that is constructed properly will go a longer distance. But in certain cases when the company wants to just touch and go, a 3rd party game engine usually suffice.

Of course, at the end of the whole thing, if the game is published and it makes a shit load of cash, then the company might consider having their own IP rather than to depend on a 3rd party game engine all the time.

Nevertheless, once these decisions are made, the team would have to zoom into a deeper focus on the smaller details.

So, who should decide on where to focus?

The company? Not exactly…
The boss? Depends….
The game designer? Possible but unlikely to be THE only one to direct the focus…
The architect? Likely to share it with the game designer
The project lead? Can contribute, but unlikely to direct any focus…
The programmer? Perhaps his own schedule…

So what in the world decides the focus?

It is the GAME REQUIREMENTS themselves.

How so?

In each game, there is a set of use case and user requirements of what the user expects to see in an application. The game designer contributes by tying down the user experience expected in the game.

User Experience is an important component, if not the most important component in any game development projects. Why? That’s where your users or players actually get the FUN (if there’s any) out of your game.

If the players don’t find it fun, reviewers find it sucky, that’s it. You get lousy reviews and poor response and the game project is a wasted investment of time and money.

However so, many so-called game developers do not really appreciate the need to understand user experience as they design their games. Without that, the game is really a blind slingshot attempt to see which crowd the rock hits.

So, by defining the user experience expected, the design and management team will be able to derive a requirements specifications while the architect will derive a technical specifications from the requirements specs itself.

The project manager will then derive a high level task specifications subjected to the management’s approval. This will include a project management schedule, manpower requirements, acquisitions, costs, quality requirements and risk management plan. Scope isn’t in the list since it’s already handled by the upper management.

The project lead will then derive a task list based on the project manager’s directions and disseminate to the rest of the team members.

The game development team will eventually know what to focus on with proper project management and requirements management.

Why is there a need to be focused?

Let me give you a reason in the face : There’s simply no time to consider your options!

The more time taken to consider, the less time there is to focus on the tasks at hand. The more indecisive the team is, the more it cost the management to sustain the team.

So let’s face it. In games there’re many genres, such as RPG, RTS, FPS, 3PS (3rd person shooter), VS (vertical shooter), HS (horizontal shooter), etc etc… The classification of genres are there for a reason. One of the main reasons is to distinguish different crowds and target audience from each type of games.

Secondly, the genre also limit some of the general scope in game development. For example, vertical shooters and horiztonal shooters tend to use more indicators than full blown user interface classes like edit boxes, list boxes, check boxes and so on. Only 2 things are usually required to make up indicators. Sprites and Textboxes.

So, is it really necessary to plug a full blown UI system into the engine?

Well, is that really your focus now? Perhaps it’ll be a good time to start thinking…

Signing off,
Jeremy