Q:
Let's talk about the enemies. How did you implement their A.I. ?
Each game "entity" (enemies and objects, such as gold)
is implemented as a very simple finite state machine, as described
here: http://ai-depot.com/FiniteStateMachines/
Each entity can subscribe to various different events; an object-manager
notifies all objects which have subscribed to event X whenever event
X happens.
So, for instance, one of the events is "collision with player";
each game entity which registers his event has a callback TestVsPlayer()
which returns true if the player collided, and false otherwise.
It ALSO has to provide additional info in the case of "true".
this way each object can respond differently to collision.
E ach event is implemented in the same way -- the object registers
to receive notification of an event type, and must provide a callback
function.
The other event types are very basic:
Update: this happens every time the game simulation
is advanced; typically, objects "do" something, such as
move or shoot, in response to this event.
Think: this is a special function; some AI processes
such as raycasts are fairly expensive, and we need to make sure
the simulation runs at at least 30fps. so, objects which need to
run expensive calculations register for the Think event, and are
notified once every FEW frames, instead of once per frame.
This way, we update the AI in small groups instead of all at once,
and the cost of the calculations is spread over many frames. The
idea comes from various AI articles in the "Games Programming
Gems" series.
T he finding for moving objects is very simple and based on the
tile-grid; grid cells which are empty can be moved through, and
cells which contain non-empty shapes can't be moved through.
Q: An interesting element, among the enemies, is the homing
missile. How did you implement the path-finding routines ?
The steering behaviour of the homing missile is another case of
us simply implementing someone else's great idea; Craig Reynolds
(who many will know in relation to "boids") wrote some
articles about chasing behaviours for AI -- we simply implemented
them exactly as described. ( http://www.red3d.com/cwr/steer/
)
Q: How did you plan the game engine ?
Our engines are sort of constantly evolving things. We start out
with ideas for games and features we'd like to see in an engine,
and we think about which ideas overlap enough to share an engine.
We think about plausibility in terms of whatever platform we're
using, how the engine can be tweaked and modified for future use,
and how the systems will be broken down.
We often incorporate little projects we've been working on through
the year, so the engine isn't built all at once, instead, it's progressive.
In this case, we'd been making various physics-simulators and tile-based
collision systems for the past year or two, and so we took the latest
version of each, modified them to be more game-friendly (they were
designed as general simulators), and built the engine around that,
adding things like the player logic and the object-manager as we
needed them.
Q: Did you use strict OOP ?
Yes and no.
W e DID use the OOP idea of an "interface", but (since
we were using actionscript 1) this was never explicitly defined,
instead we simply made sure to document and follow these rules.
N ear the end we resorted to the tried-and-true solution of make
hacky global variables, because the 2004flashinthecan
award deadline was only a day away -- sadly, the judges thought
that "starsky and hutch pinball" was a better video game
than N
Q: Did you use Actionscript 1 or 2 ? Which one do you prefer/use
?
Actionscript 1, because we didn't have mx2004; we downloaded a demo
and used that to publish the projectors so that they'd use the faster
flash7 player.
We're beginning to use Actionscript 2 now though, but really --
the whole attraction of flash is how simple and fast it is to work
with. The more rigid the language becomes, the less useful it is
for quickly throwing together ideas. Specifically, we're not sure
that investing the time to use AS2 is worth it, when we could instead
invest the same amount of time and learn Java, and have access to
the faster calculations and hardware acceleration.
Q: Did you use any particular "optimization trick"
to squeeze every bit of performance out of the flash player ?
The only real technique we used was one which every games programmer
should follow: never, ever use O(n2) algorithms.
A ll of the algorithms we implemented run in constant or linear
time, which is the biggest "optimization" you can make
in terms of performance.
S pecific to flash, function calls incur some overhead, so we actually
eschewed using get/set methods for very-frequently-accessed properties,
and instead simply referred directly to them (i.e. .pos instead
of GetPos()).
I n hindsight this might now make as much of a difference now as
it did in flash5.
A nother "trick" we used was return
value optimization. Also, an important point to make is that
the bottleneck of any flash game will almost never be the code (if
it is, you're doing something wrong). it's the player's renderer
(~60% of each frame is waiting for the screen to be drawn).
The speed of the renderer varies based on the area of the screen
which changes, so if you want a large screen, use small moving objects.
if you need scrolling/etc., you'll need to use a smaller screen.
Q: How long did it take to develop ?
6 weeks / 150 hours - plus hours developing physics sims/etc. in
the first place (which took a few months of very lazy part-time
work)
very roughly:
2 weeks: porting physics-sim into a more game-friendly collision/physics
system
2 weeks: writing game code (enemies, etc.)
2 weeks: content (levels, graphics, sound) and testing/etc.
Q: What were the most difficult parts to develop ?
Ned, the editor, is a mess. Basically, it was written in a single
day, and it's over 3000 lines of code, so that might tell you about
how well-thought out it is we consider it a beta, for the most part
-- it wasn't written for ease of use or for the general public,
and still requires a number of changes.
soon we'll have to face that and rewrite it properly, but currently
we're working on other, more fun things, such as a series of tutorials,
and an online highscore system.
Q: Why did you choose to make the game a download-only
executable ?
Speed. It's pretty CPU intensive, and the addition of a browser
doesn't help.
M acromedia should invest some real time in developing some modern
compiler technology for their language. for instance, even in flash7,
the _length_ of a variable's name affects the speed of referencing
it!!
T his is clearly done for no reason other than ease-of-implementation
on the part of their programmers, and was fine in flash5, but now
that they've had a couple years to get their footing, they should
look at other byte-code-interpreted languages (such as Java) and
see that their technology is obsolete.
Q: The flash player speed was recently enhanced with version
7. Do you think its performance is enough for games ?
well, it worked for N...
But we _were_ faced with limitations in terms of speed and graphics.
however, our project was more ambitious in certain areas than many
of the webgames being developed. the answer to this question really
depends on what you're developing in Flash.
Q: The inevitable question: what would you expect from
the next version of Flash ? Any wishlist ?
Other than a proper compiler/virtual machine (and maybe a JIT compiler),
the only thing it really _needs_ is a faster renderer. I'm not sure
if they can do anything about that without using OpenGL/DirectX,
which I don't think they'll do.
we'd kill for the ability to read/write text files. _Kill_.
It's silly that this ability is still not included in the stand-alone
player, since you can take your flash .swf, embed it in a director
app, and use the director app as a "projector" which allows
file IO. so basically, a home-brew projector made using macromedia's
own tools is more functional than their official projector.. wtf?!
one of the biggest problems with macromedia is that they seem content
to let 3rd party developers add the functionality they're too lazy
to include themselves. I guess it's great for them -- they don't
have to pay for adding basic features such as resolution-changing/etc...
but in the end, it's the flash users who pay, which is pretty rude.
their excuse is always "we need to keep the player size small",
but.. one of our friends wrote a .dll in c to let us read/write
files, and it's less than 1k in size.
we like flash, and think it's a great development tool, but there
are certain aspects which make us think that maybe macromedia has
too many marketing and PR people, and not enough good engineers.
Q: What about future projects ? Have you already planned
new games ?
W ell, we want to first add the features we had to cut from N in
order to finish it on time; for instance, the next release will
feature an integrated online highscore system, including replays.
In terms of actually "new" stuff, we've started working
on a new engine which will be polygon-based instead of tile based,
and which will feature scrolling. We've also got a bunch of stuff
we developed for N but didn't include, such as a little rope-physics
simulation. And of course we have lots of ideas, but right now we
haven't had time to properly work any of them out. Hopefully by
the end of the summer we'll have a new game.
Right now, tutorials for N are our first priority -- we feel it's
important to give back to the game dev community we've learned so
much from.
|
