[crack-attack-devel] Future Development Ideas

[Andrew Sayman]

== Sound ==

So now we have some sound patches in, but their functionality is a bit limited.

Firstly, it would be nice to have some sounds that fit the game better. An
explosion sound doesn't fit the animation that happens when blocks shatter. The
sound that plays when many combos are happening gets way too loud when you're
playing well against the hard AI.

Secondly, I think that the music patch could have more options. I think it would
be nice to support a simple pls file that points to many different songs to go
through.

== gtk front end ==

This front end is poorly designed. Here are some proposed fixes.

Move the three gameplay modes into dropdown or tabbed panes so that you're only
looking at one at a time. There's no need to show a grayed out version of the
options for modes you're not interested in. I prefer the idea of having three
tabs that say solo, client, and server; however, I seem to recall this being bad
design.

The options common to all three modes should be moved out of the tabbed area
that the specific modes control. These options are: extreme mode (which may be
complicated/confusing because its availability is tied directly to the AI
options), graphics quality, sound control, resolution, and name. Ultimately
there will be many more generic options than ones specific to game play modes,
so we should start organizing these logically now.

Rather than showing the crack attack logo, we should show a small screenshot of
the game. Ideally, this won't be a screenshot but a demo of actual game play.
When the user changes the graphics quality, the demo/screenshot should change to
reflect the graphics choices. The problem with the idea of running a demo is
that the front end currently spawns the game through command line options. This
means we can't just put a drop-in rendering loop or something like that.

== networking ==

Why does the syncing code suck so much? Now that we can build for windows, we
need to change the protocol to something that doesn't bite. The two candidates
for other libs to use that come to mind are OpenTNL and ENet. I've actually
played with code for ENet, and I couldn't get the win32.c file to work correctly
with dev-c++. I'm sure this can be solved. ENet is one step ahead of OpenTNL
because I've actually used it before and seen how it works. Any suggestions in
this area would be greatly appreciated.