Ad Lib Game Development Society
Zero Lodge
Session 3 (Saturday June 12, 2 days, 8 participants)
Project: NetSlack
Participants:
Charon,
David,
Josh,
Lucas,
Shawn,
Squirrel,
Tom,
Zach
Downloads:
Synopsis:
This one was a close tossup between doing a tile-based top-down Zelda/Gauntlet/FF2
type game and a game based on rope physics. At the last minute we decided to go
with the RPG idea, calling it "NetSlack" (after the popular unix game "NetHack").
The player has six different spell-attacks, each of which has its own resource
meter and recharge time. Gauntlet-style monster generators pump out endless
numbers of enemies.
We had a lot of work to do with this one, but we did pretty well anyway.
There were a lot of systems written from scratch, including: a general-purpose
text parser, tile rendering code, and a materials system (including gameplay
properties such as "blocks player", "spawn monster generator", "stairs up",
etc). Several really kickass maps were done using a half-stolen, half-hand-drawn
graphic tileset, including two desert maps, two dungeon maps, and a near-exact
replica of the outdoor map from the original NES Zelda. We also put in a
basic attract / play / game over state, complete with catchy screens.
Unfinished business:
We only got 1 spell effect, 1 monster generator type, and 1 monster type
implemented. Lots of other pieces were missing, too. Part of this was
due to coders needing to spend lots of time writing systems rather than
gameplay. Production was also halted somewhat when a
family of four teeny tiny kittens was found
abandoned in a bush in our backyard, near to starvation. Several
team members spent a number of hours each feeding and "pooping"
the little fellas, as directed by the all-knowing Internet.
(For the cat-loving readers out there, the kittens
are now in the good hands of a lady who specializes in taking care of
infant cats.)
Postmortem notes
What went right
- The Materials and Scripting system(s) turned out to be a huge win. Designers were able to add gameplay elements such as treasure chests, mutually-exclusive-state gates and switches, and secret walls (to name a few) with little or no code changes.
- The quality of art was excellent, and a perfect fit for the game type.
- Using RGB values in TGAs to define maps in terms of a variety of Materials was a really great idea... at first, anyway. It allowed map creation to occur with absolutely no tools work whatsoever, since we leveraged existing tools (Photoshop, Paint Shop Pro) and tool knowledge.
- Tile rendering came up fairly quickly and worked well.
- Screen-shake and screen-blend when taking damage was a nice effect.
- Engine worked great; asset creation and inclusion was straightforward; code was easy to modify and extend.
- Stealing 2d tile art from online sources was an excellent way to get the game up and running with placeholder art while actual / final art came online later.
What went wrong
- Too ambitious: by the end of this session, we had gameplay but nowhere near a complete (or interesting) game. This game concept ultimately ended up taking every bit of 4 days (two sessions) to complete, and then some.
- Instead of using what turned out to be a C-style monolithic Entity class, we should have used inheritance with an Entity base class and specific derived classes. What seemed "simpler" (monolithic C-style) actually turned out to be more cumbersome and time-wasting.
- Using RGB values in TGAs to lay out Materials in maps quickly ballooned out of control when we found that instead of the 15 or 20 Material types we initially estimated / expected, we ended up with 117. The principal problem being that each Material type requires a unique RGB color to represent it in the map TGAs, and with 117 different colors it quickly becomes confusing as to which color means what.
- No instance data: what ended up being possibly the single largest gap in our game systems was the fact that there was actually NO WAY WHATSOEVER to specify instance data for Entities or Material tiles. The Materials and Scripting system, being the most flexible piece of the puzzle, became the obvious candidate for abuse in order to make up for this shortcoming. Thus a rapid proliferation of different Material types came about; for example, the mutually-exclusive blue/red gates and buttons required the use of no fewer than 6 different Material types AND the abuse of a self-modifying "ChangeMaterial" command (which, admittedly, was added expressly to support and encourage this sort of abuse).
- Funny or clever class names (e.g. "Playah") aren't funny or clever after you've misspelled them forty times.
- Using TGAs for map data also ended up biting us because the second we tried to stray outside the capabilities of a paint program (or a pixel format) -- say, for adding instance property data -- we were screwed.
- Had a really annoying bug with tile rendering in which, on certain drivers, texture coordinates seemed to be slightly off.
- Less experienced artists needed help but couldn't get it due to time constraints and lack of organization, thus feeling (understandably) left out / unused / discouraged.
- Needed smaller, more well-defined goals that are specifically assigned to individuals, rather than just swimming around making assets or features without a unified purpose or direction.
- Need to get everyone -- coders, artists, designers -- working on the most game-critical stuff first, instead of spending time on fluff or polish before the game is even complete.
ALGDS and page content are Copyright 2004 Brian
"Squirrel" Eiserloh. Note that neither Brian Eiserloh nor the ALGDS
makes any claims of ownership, expressed or implied, of content
generated by ALGDS Lodge members. All code and content created
in Lodge sessions is owned solely by its individual creators
and governed entirely by the decisions thereof. We do, however,
reserve the right to freely release and redistribute any code,
assets, or games submitted to the ALGDS by their rightful owners
for that purpose.