Re: [crack-attack-devel] Future Development Ideas

[Babbing]

I can definitely agree with the first two points, but I will have to
take your word on the networking points. As far as sound, some
homegrown clips would be real good. I know that TA used some sort of
trumpet and bells combination that works nicely for block shattering,
but especially nice for combos. If anyone has ever played pydance,
they have some really nice music that has been put together for them.
Maybe we could check out the credits and start asking around :).

As far as the frontend, I think it needs to be more minimalist, and
tabs are a great start. There is one other thing. When a single player
round is finished, the game window just sits there. I think it would
be a good idea if we either set the player right back onto the gui or
back into a round with the same settings. It just feels like a big
disconnect between the frontend and the game.



On 4/24/05, Andrew Sayman <address@hidden> wrote:
> == 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.
> 
> _______________________________________________
> crack-attack-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/crack-attack-devel
> 


-- 
Gentoo - www.gentoo.org
Firefox - www.mozilla.org