Proposed Timeline (subject to change -- please comment)
This timeline will be listed by the number of hours spent as opposed to actual time, since I don't want to add too much confusion with timezones. The project will be 48 hours total. These are intended milestones that we should reach by the given time:
- 45min: Decide on a general concept for the game.
- 1 hour: Choose libraries/engines/framework/etc (most of this discussion should happen before the project starts) (Milestone 1 complete)
- 3 hours: Come up with basic implementation plan. Assign art responsibilities. Have basic concept art generated by this time. (Milestone 2 complete)
- 6 hours: Create stubs of necessary classes and functions. Find usable art from various resource sites.
- 7 hours: Assign coding, art, and content responsibilities (generate itemized todo list). [edit: this originally said 'assign coding responsibilities', but I've expanded it to include the main, itemized todo list]
- 12 hours: Tech demo. (Milestone 3 complete)
- 20 hours: Have basic game code in place.
- 24 hours: Have a basic, working, playable game. (Milestone 4 complete)
- 44 hours: Have a complete (or at least better) game.
- 48 hours: Have the game working on all three target platforms. (Milestone 5 complete)
This is very basic and will probably need modifications. Before commenting, please see my forum post about the game plan, as they are interrelated and will be clearer together.
Seems like a big jump between 24 and 44 hours, also this timeline doesn't mention art progress.
Art:
1. Sketches
2. Placeholder art
3. final art version
4. Additional art (menus, texts, etc.)
24-44 could differ, varying on the type of game. For example: if you create an rpg, this may be the phase where you create lots of content. Or add things like random levels..
Me as a fan of Team-OGA shouting from the tribune random thoughts:
For libraries:
The rules allow you to choose/discuss/learn your libraries (weapons) beforehand and in my opinion you should do that completely beforehand. And then do what you can with these once the competition starts. Maybe just decide on additional libs when really really really necessary (better convert data?). Just being pragmatic.
For art, theme and goal:
Once you know the theme-key-word you may try to gather available open art in a brainstormy parallel fashion. Then review what you all found. And then decide for the concrete goal/plan (depending on the available art). Sure adding complementary art where necessary.
(2d or 3d should be clear rather early. If I'd be you I'd say 2d for simplicity and the ability to use all 2d art + pre-rendered 3d art)
For portability:
Compiler option -Wall helps to get rid of (some) possible portability-/version-issues in your source, too. Of course make sure that there are precompiled/packaged libraries for your three platforms. "/" works on windows, too - at least with mingw which is the best option for cross-platform.
As for Tech-Demo and implementation steps:
"Tech Demo" sounds bad to me. Don't demonstrate technology. Demonstrate your primitive game mechanics or your primary-game-loop and enhance it. Iterate as often as time permits. Refine mechanics and refine art.
And remember to keep everything real simple - no time for elegant code that may be useful someday.
I want a clean fight. Now get it on! ;)
How about deciding on the language? Yes, there is C++, but several of us also are fluent in python (pygame).
Even if C++ is already implicitly chosen, what about C++0x? It has quite some features that speed up C++ development a LOT! (just think "auto", "decltype", tuples, smart pointers, builtin regex, ...) And is widely available by now.
We'll talk about having a second team if a strong python contingent shows up.
How cross-platform is C++0x? Is there anything in it that Boost doesn't already do?
IMHO whatever you use you should stick to what the most know and/or you know the best. Some lowest common. I doubt there will be time for unknown tools - however great they are supposed to be.
As for special C++ standards: Be aware that different compilers may have different partial support for newer standards - with mingw (gcc for windows basically) it isn't a very big concern but even mingw may lag a bit behind of linux gcc. Don't even mention different brands of C++ compilers. And I'd stick to simple make or build scripts..
I'd like to stress it even more: There isn't time for any failure in 48 hours - if 48 hours is your target. Usualy people who paricipate in such competitions seem to use their own beloved well known toolset they know in-and-out. You could imagine it as some kind of special operation. In my opinion the chances to achieve more are better with less. And avoid featuritis.
I think python is a good choice for portability, isn't it?
I agree with hc, to use the most familliar tools.
Regards
-A
Boost and C++0x have things in common (shared_ptr, unordered_map, tuples) but of course C++0x also adds language features boost can't: C++0x has auto, decltype, lambdas, initializer lists and explicit overrides.
These are just examples of things I feel speed up game dev. Those things are supported by gcc 4.6 onwards (probably even gcc 4.4 for most) and msvc++2010.
Just wanted to raise the question, as to why not use it if the compilers support it anyways. It's not that using it would rule out team members (unless they use gcc < 4.4 which is weird anyways :-P)
Someone should start setting up a location to work from, an svn repositiory for example, and start giving people rights.. We should have a fluid coorporation system by the time the challenge starts.
I'm not a moderator, but please discuss libraries etc. in the topic about libraries and genres.
Just an idea that came to my mind.
Manage an active Todo-List. Especially for small tasks like simple art or UI-Elements this can be very useful for people who want to contribute a little bit of their time, but are not actively involved in the development.
Yeah, such a TODO-list would be awesome as I think most of the people (including me) can only contribute a little time while the "core" which will be there most of the 48h will only be a few persons.