Game Development Reference
In-Depth Information
These values will stay consistent even if the stage does not. One
exception to this is if you are working with scalable content (like a
universal iPhone/iPad app) and the original size of the stage is
irrelevant to how elements on the screen need to be laid out.
Don ' t Use Frameworks or Patterns You Don ' t
Understand or That Don ' tApply
This may sound like an odd item in a list of bad practices to avoid
when you
'
re pressed for time, but it is yet another very real sce-
nario I
ve witnessed with my own eyes. It is the opposite of gross
underengineering
'
obscene overengineering
and it is every bit as
much a crime
as development crimes go. An example might be
trying to apply a complex design pattern to a very simple execu-
tion. Some developers are tempted by many OOP frameworks that
exist because of the generosity of the Flash community as a way to
speed up development in a crunch. However, if the developer
doesn
t really understand the framework and how to implement it
effectively, they will have essentially added an enormous amount of
bulk to their project for no reason and will often end up
'
how the framework is intended to function because it should never
have been used in the first place.
Another project I recently had to make edits was created with a
model-view-controller (MVC) framework designed to force adher-
ence to the design pattern of the same name. However, because of
the architecture of the framework, it meant that related code was
scattered over at least 20 different class files. Some of the classes
only had one or two methods or properties associated with it, mak-
ingitabread-crumbtrailtoattempttodebug.Itwasaclassic
example of overengineering; the game was not complicated or var-
ied enough to warrant such a robust system, but the developer
equated using an OOP framework with good programming, so they
used it anyway. As a result, it took probably twice as long to fix
bugs in the game because it was hard to track down where the
logic for different parts of the game was stored.
rewiring
Know When It ' s Okay to Phone It In and
When It Definitely Isn ' t
If you
re producing games independently of an employer or client,
either for profit or for an experiment, the stakes are much lower.
Fewer people, if any, are ever going to see your code, let alone
have to work with it. You can get away with some sloppier stan-
dards or rushed programming. In fact, some of the best founda-
tions for games I
'
'
ve seen have been born out of hastily thrown
Search Nedrilad ::




Custom Search