hello milesteg,
you've put some serious thought into this and there are some great ideas in there.
here's some feedback, some of which could also apply to openarena....
Things OAe has in common with OA:
- all content and code has to be licenced under GPL!
- there is no restriction in terms of settings (gothic, hightech, reallife - everything is accepted)
- keep the Q3-gameplay (in some way) intact (= there should be a setting "vanilla quake" or something like this)
i completely agree with the strict adherence to GPL when it comes to the game itself, but the question of how non-gpl mods are treated needs to be given some thought. it would be good if we could explain the situation without alienating them. if the gpl and non-gpl modders can share their knowledge then it would be a mutually beneficial relationship. if we can make the non-gpl modders feel part of the community then there is a better chance that they might consider putting some of their work under the gpl.
i really like the no restrictions in terms of settings. it fits with the idea of a free content repository for other games to grow from.
So what are the differences between OAe and OA ? Primarily OAe won't try to clone Q3A content. This means some of the old Q3A mods will possibly not work (although we should try to avoid this).
i'm not so sure that we should try and avoid that. maintaining compatibility with a bunch of mods written for quake3 will at best slow the development down and at worst cripple the game. i reckon quake3 compatibility should be thrown out the window and the focus should be on making the best game possible. if people really want to play the mods then they can either use openarena (which has the quake3 compatibility angle covered) or port the mods to the new technology.
- OAe will also welcome new (GPL'd) mods and tries to integrate them in the main game.
agreed.
As you can see the idea of OAe is to catch as many new projects as possible and bring them under one hood. This is basically the same concept used in Debian.
agreed. it's a useful comparison.
- The graphics and game engine should be featurerich but new effects etc. must be optional (=you should be able to turn them off).
agreed, to an extent. if there are options that can be easily turned off then it wouldn't hurt to provide a nice clickable option in the menu to do so, as long as it doesn't distract from working on the game. a lot of time could be wasted trying to get the game running on old computers that could be spent trying to make it work better on new ones.
- The gameplay has no special direction: If some people want to work on e.g. a CS-like gamemode they are free to go this way.
absolutely. i really feel this is important.
- default settings must be easy to understand and creating a user- and developerfriendly game is also an important aspect of the project.
-- Most of the settings should be adjustable in the new GUI. Keep the commandline away from the user if possible.
-- important advises (how to play a certain gamemode) should be readable ingame (even better: let someone talk to the user!)
agreed. make the game as noob friendly as possible. it might be worth looking at some usability guidelines to see what can be applied to the menus. the gnome desktop has something like this. (i've nothing against kde, i'm not trying to start a gnome/kde flamewar).
-- OAe should be developerfriendly (maybe integrate GtKradiant?) and both enjoyable for new and advanced players.
very true.
i think having a lot of tutorials on a wiki would really help here. ideally they would be so clear and comprehensive that a complete beginner could simply take the tutorial and make a map or model with very little further help. something that would be useful would be if every tutorial started with download links for all the software required for that tutorial. there could be a standard format for a tutorial page, to provide a uniform look. links to all the required software could also be provided on the download page.
on the subject of gtkradient, i'm under the impression that it needs extra stuff to do work on openarena. telling people to download gtkradient and then start putting extra bits in various folders is messy. it would be good to provide a package with an automated installer that does all the work or make a customize version.
if blender needs extra content it would be good to have an addon package that provides everything needed for it too.
it would help modelers if there was a range of generic character models available for download that had all the body parts, rigging and animation in place. so a developer could simply download it, tweak the mesh, skin it and resubmit it to the game.
something that could help mappers would be to have every tutorial provide a download link for a very simple .blend or vrml file with a generic humanoid character to help give a sense of scale. it could have a box around it to show how much space the model needs so that mappers could check that doors were big enough. there could also be a crouching model with a correspondingly shorter box. there could also be a link to the content repository where they could browse for items for their map.
-- the number of gamemodes need to be kept small. No new gamemode for just one changed setting. (maybe a gamemode for beginners with fixed settings and one for advanced players where settings can be adjusted in many ways)
the distinction needs to be made between the underlying gamemode and "mutators" that alter the game play. instagib, for example can be added to any of the gamemodes and while it changes the gameplay the underlying rules are still the same. an instagib deathmatch is still a deathmatch.
some thoughts on the namei'm not sure about the name openarena enhanced. while i think it's important that the new game should acknowledge it's ancestry i think using the same name might not be the best way of doing that. i can think of a few reasons....
google - if someone types openarena into google then the openarena homepage should be the first link there. if the new game had openarena in the title and really took off it could conceivably knock the original off the top spot, which would be really rude. if on the other hand the new game had a different name but provided prominent links to the openarena homepage then it would actually reinforce it's google ranking.
divergence - the new game will be moving off in different directions and eventually they will be completely different games, so it's inevitable that at some point the new game would need to be renamed to avoid confusion. it would be better to avoid the whole situation by having the new game start with it's own identity that didn't conflict with openarena's.
implications - there would also be the fact that having a project called openarena enhanced would imply that the original was an inferior product, whereas the truth is that the two projects would simply have different objectives, openarena being focused on perfecting quake3 compatibility and the new game on competing with proprietary games.
code of conductit might be worth having something like ubuntu's code of conduct on the forums.
http://www.ubuntu.com/community/conductwhite haired boy.