Who we are
The Ad Lib Game Development Society (ALGDS) is an fledgeling
organization of intrepid game developers who attempt to challenge,
amuse, and better ourselves through the frequent practice of
spontaneous, rapid game design and development.
The society itself comprises different local area chapters,
called Lodges, each of which adheres to the principles and patterns
of the whole while maintaining its own diversity in terms of
specific practices.
What we do
The particulars vary from session to session and Lodge to Lodge. The
basic gist is the same, however:
A group of Lodge members gathers at some predetermined time and place,
usually with computers in tow. After everyone gets set up, the group
comes up with a basic game idea. This process is usually limited to
a fixed amount of time. The group then sets out to create said game
as fast as possible. This can involve code, sound, art, map design,
game design, even limited tools development, depending on the makeup
of the participants. It requires a fair amount of expertise on the
part of each individual, a lot of caffeine, and a huge effort towards
teamwork, coordination, and communication.
After a predetermined amount of time has passed (8 hours, 24 hours,
even 48 hours) and a large amount of Chinese food has been consumed,
game production finally comes to a stop and the group steps back to
see what it is they've created -- or failed to create, in some cases.
Some games get finished in time, some don't. Some unfinished games
get picked up again at a later date. Often a session postmortem
is held afterward (in person or via email) to discuss what worked
and what didn't.
Ultimately, more important than whether or not the project was
successfully completed is that each participant gained something
from the experience, improved his or her craft, and had fun in
the process.
Why we do it
So what's the point? Why are we participating in this nonsense?
We believe that, as game developers, there are many ways of improving
our craft. Reading books, attending seminars, enrolling in university
programs, enlisting the help of a mentor -- all of these are worthwhile
and can contribute to the breadth and depth of one's game development
skillset. In the end, however, there's just no substitute for
experience.
As most game industry veterans know, experience is a precious and
valuable commodity. Unfortunately, many modern game projects have
development cycles between 1 and 4 years (or longer!). Thus, opportunities for
hindsight and growth are few and far between. Mistakes are often
forgotten by the time postmortems come around at the end of the project.
Developers become burned out or jaded. Thus, the benefit of
experience, though valuable, comes at a high cost.
"Experience is a hard teacher because she gives the test first, the lesson afterward."
-Vernon Law
Enter rapid game development.
The benefits are numerous:
- Speed - Improve your ability to perform tasks quickly, even under pressure.
- Adaptation / Agility - Learn to hit a moving target and adapt to radical shifts in design and requirements.
- Hindsight - Benefit from a high frequency of postmortems and a quick turnaround on action-verses-consequence lessons.
- Fun - Have a good time. Laugh at yourself. After all, you're really quite pathetic.
- Balance - Learn to govern the balance between speed and quality, between risk and reward. Learn to avoid oversolving or undersolving problems.
- Exposure - Be exposed to a wide variety of game development domains. Move through many different diverse problem spaces. Go from 3D modeling to 2D pixel-pushing, real-time to turn-based design, from A.I. to network code.
- Experimentation - Dare to try stupid or silly ideas. They just might surprise you and turn out to be works of genius.
- Proof of Concept - Prototype gameplay concepts for immediate fun-factor feedback. Stumble onto an idea that becomes the seed for a AAA title. A fun-to-play demo speaks louder than a boring-to-read design doc.
- Cooperation - Improve your ability to work closely with other developers under the gun.
- Communication - Learn how to communicate efficiently and succinctly. Learn when to talk and when to shut up. Learn when documentation is critical and when it isn't.
- Time Management - Hone your ability to estimate task completion time. Learn to work smart, even under extreme time pressure.
- Community - Work with area game development peers. Build cross-company relationships.
- Challenge - Set the bar high. Jump higher.
- Restraint / Self-Discipline - Learn how not to bite off more than you can chew. Learn the fine art of culling the good ideas from the great ones, and cutting the great ones when they become infeasible.
- Inspiration - Become inspired by an idea prototype, then go off later and explore that avenue further and in greater depth.
- Creation - Force yourself to create. Get those "bad" ideas out. Give yourself the opportunity to create something great by allowing yourself permission to make something awful.
Lodges
A Lodge is simply a group of developers in the same area who
choose to get together and start practicing rapid, ad lib game
development. Although participation in an individual Lodges is
typically by invitation only, everyone is
welcome and encouraged to
create your own Lodge and start
putting ad lib game development into practice in your area.
The following is the list of known active ALGDS Lodges:
Although other Lodges are currently rumored to be in the
process of forming up, a new Lodge must conduct at least two
sessions before it will be listed on the ALGDS page.
How to Participate
Simple:
Go and do likewise.
Get some folks together.
Make some fun stuff. Start an ALGDS Lodge. Tell us about it.
We'll even give you a free subdomain
(like zero.algds.org).
Feel free to download the
Zero Lodge Game Engine
which is somewhat ghetto, but it gets the job done (and it's free). Or, go
to the downloads page and grab the source code
from a previous game submission.
How to Create a Lodge
The following are the ALGDS guidelines for the creation of a new Lodge.
Note that none of these rules is by any means set in stone. However, each
guideline attempts to help serve the greater good, whether by creating an
increased sense of community or by encouraging the correct spirit of
participation.
- Each Lodge chooses a name in the form of [name] Lodge (e.g. Pizza Lodge).
- Each Lodge consists of at two or more people.
- Send email to lodges 'at' algds.org
to let us know you exist.
- Lodges should meet regularly, not just once or twice.
- There may be more than one Lodge in a city.
- Lodges leaders should send email
to lodges 'at' algds.org
describing session activity, attendees, etc. Hopefully in the future this sort
of logging will be available via an automated web interface.
- Lodges are strongly encouraged to make their games, assets, and code readily available for
free download and use, preferably under some sort of
open source
agreement, such as GPL.
- Each Lodge is given a free subdomain (such as pizza.algds.org)
which can be set to redirect to an external Lodge web page or which can host (moderated)
content and/or file downloads on behalf of the Lodge.
- Every member of every Lodge may have an email forward set up from their Lodge
subdomain (such as john.smith@pizza.algds.org) if they so choose.
- Lodges may use existing technologies, each other's technologies, or write their own.
- Lodges may determine how often (e.g. once per month) sessions are held and how long
(e.g. 24 hours) each session lasts.
- Lodges may work on one game at a time or multiple games (or game technologies) at a time.
General Advice
Lodge members are invited to do whatever they like as
far as their specific approach. Nevertheless, the following
is a somewhat random list of pointers we've picked up through
trial and error.
- A.B.C. -- Always Be Closing.
Always keep the end in sight. Always be moving towards an
immediate goal that will pay off NOW. A tool, or system
that comes online 30 minutes before the deadline will likely
not have time to pay for its creation effort. Keep goals tight
and immediate. Coffee Is For Closers!
- Play to your group's strengths.
If you've got 4 coders and 1 artist, you'll naturally
excel at an entirely different set of tasks than would a
group consisting of 1 coder and 4 artists. If writing
new code systems isn't your thing, make a Quake mod.
If 4-day sessions work better than 24-hour sessions,
so be it. The important thing is that you give yourselves
the opportunity to create... something, anything.
- Use Tiered Development.
Try to come up with a "bare minimum" playability goal that
you can meet first. For example, it's better to have one
enemy type, one attack type, and win / lose conditions than
it is to have three attack types but no enemies (or five
different types of enemies but no way to hurt them). Once
you meet your Tier 1 goals, move on to Tier 2 (and so on).
This isn't a terrible approach for AAA titles either.
- Frontload setup.
Get your network cables, monitors, source control,
whiteboards, tables, chairs, power strips -- as much as
you possibly can -- set up ahead of time so as to avoid
delays getting started.
- Expect delays.
Nothing kills time or momentum like waffling around trying
to figure out what everyone wants to eat. Decide early,
decide fast, and try to bring food in if at all possible.
Servers crash, network cables go bad,
litters of starving
newborn kittens are found in the bushes outside the room
where you're holding your session, etc.
- Make definitive task lists,
assign them to people, and check them off when they're done.
- Tools and systems first, A.I. and gameplay later.
Frontload any tasks upon which artists, designers, and asset producers are dependent.
- Use an egg timer.
Set concrete time ceilings for open-ended tasks,
especially design tasks. Try to reach a point where
the programmer(s) can go off and start laying bricks
while the designers flesh out the rest of the design.
- Use source control.
The value of this cannot be overstated. Not only does it make
the exchange of code and data files (as well as .EXEs) easier,
it protects against crippling 4-in-the-morning-oh-my-lord-what-have-I-done bugs. Hint:
Perforce offers
free licenses for
open source projects.
Go and do likewise.
Questions? Feel free to send email to questions 'at' algds.org
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.
