OpenArena Message Boards

Hi
in this posting (http://openarena.ws/board/index.php?topic=309.msg1613#msg1613) I suggested to create another project wich is based on OpenArena but creates new features for the game, so the gaming expierience could be improved.

A good start would be a mod that collects ideas from the community and tries to integrate them.
Things I would like to see:
- New game modes (e.g. counterstrike, Onslaught)
- new weapons
- vehicles would be cool
- mutators(=more options to change the gameplay) like in ut
- making all features modular so they can be switches on or off

The idea is to make all this optional so in the end you can use the mod and still play like the vanilla q3a without the bells and whistles.

So what do you think about the idea?

I think what you're wanting is Unreal Tournament.....


Would be nice if the original UT, even if just the engine, were GPLed, but its not...

A similar idea had already been suggested (http://openarena.ws/board/index.php?topic=263.msg1384) some time ago.

Maybe a free open Mod with a remix of game modes cloned from all other quake3 mods, ut and so, could be a good thing, since almost all other quake3 mods (except for tremulous and some other, but they are total conversions) have closed source or their source is distributed under a non GPL compatible license.

Apart from the license, there's the problem that there is almost no server running any mod. If there was some sort of "official mod", I believe that it would be played a lot more.

Btw, I dont think the game needs "mutators". It is already moddable, and there are already switches that can be turned on and off, or with different values assigned when hosting a server, but they are hidden (give a try using UI enchanced pk3).
The only thing I miss is more game modes. Weapons are fine as they are.

Actually, mutators are nothing more than convenient menu options. UI enhanced has most of the options I am looking for and I think it would make a great addition to oa enhanced.

"I think what you're wanting is Unreal Tournament....."
No, what I want is a project that collects all ideas from the community about improving oa and tries to realize them.

i'll have to take a look at ui enhanced. i vaguely aware that there are a lot of options that affect the gameplay and it would be great if i could access them from a graphical menu. (yeah, i'm lazy. sorry)

is this what you are talking about?
http://www.vgpro.com/file/17251_uie12.zip.html?execute=vgpro#download_now

i've downloaded it and i'll have a look at it when i get home. i didn't see what the license was, but if it's not gpl then it will still be interesting to see what can be done to the ui.

white haired boy

I agree with this idea actually, and it might be better if it benefitted from Team Arena's features in addition. :)

yes, that's the mod. The sourcecode of it is in fact available for download, I suggested it before (http://openarena.ws/board/index.php?topic=222.0) to be added to OA but the bad part is that it is not GPL-compatible and I couldn't contact the author.

However its code might be used as a aid for developing the OA enchanced UI.

I contacted the author once and he said he wanted to licence the code under gpl soon... but that was about an year ago... :(

hello,

i didn't have any luck getting the uienhanced mod to work. i tried it in both the openarena folder and the baseoa folder and it made no differnence either time. am i missing something?

white haired boy

works good for me:
1. downloaded uie12.zip
2. unzip it
3. copy uie12.pk3 into the baseoa folder (I'm using OA without any other mods)
4. start the game with hundreds of new options

wierd. i wonder why it's not working.

white haired boy.

OpenArena enhanced (working title)

comments about the chart (see attachment)
This is the way I think OpenArena enhanced could fit in the environment of Q3A and OpenArena.
"Internet Developer-Community" and "Internet Modder-Community" are just seperated to keep the chart easier to understand, but of course they aren't that different from eachother.
The blue arrows show where free content/code is used. The black arrows are contributions with mostly non-free content/code.



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.

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).
- OAe will also welcome new (GPL'd) mods and tries to integrate them in the main game.
- The more free high quality content (textures, sounds, maps, models etc.) the better. The longterm goal is to get a big free content repository that can be used for much more projects later on.
- The graphics and game engine should be featurerich but new effects etc. must be optional (=you should be able to turn them off).
- 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.
- although there is no special direction for the game itself the primary goal for the project is to integrate GPL-published stuff.

- 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!)
-- OAe should be developerfriendly (maybe integrate GtKradiant?) and both enjoyable for new and advanced players.
-- 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)

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)

Will OAe (the enchanced mod) and OA+ (the missionpack Quake3:Team Arena replacement) be different projects?
If they were I think they would need better names to avoid misleading

However, it is needed to divide the comunity of players that much?

Since there aren't mods based on Q3TA I think there is no real need for a GPL replacement for it, isn't it?
Those 2 projects could then be merged to feature all of the Q3TA new weapons, gamemodes, items and runes, whitch are already really good and add whatever is wanted to make the greatest Q3-based game

short answer about the naming: OAe is still a working title, so every new ideas for naming are welcome.

I don't know exactly where the OA+ project is heading

seeing as the missionpack code is already integrated in the source, it wouldn't be hard to compile both a OAe and a OAe+.

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....



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.


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.


agreed.


agreed. it's a useful comparison.


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.


absolutely. i really feel this is important.


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).


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 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 name

i'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 conduct

it might be worth having something like ubuntu's code of conduct on the forums. http://www.ubuntu.com/community/conduct

white haired boy.

This isn't a good idea right now as GTKRadiant 1.5 is still in the dev. stage with many of the useful plugins (GTKGensurf comes to mind)  simply not building.  Copying the Q3 stuff over into a new folder and editing the default paths in the xml files isn't that difficult.  Besides, not everyone uses GTKRadiant.

[edit] also it would be slightly rude to distribute a tool that won't open the current .map files (unless someone can work out the q3 primitive problem on QuArK edited maps)


I thought the only addons for blender were the md3 export scripts from the xreal project

I thought there already was one (i.e. "don't be a dick").  :)

@white haired boy
I agree with you about no alienating the non-gpl modders. It would be a great benefit if some of them contribute to the project. One of the goals should be to get the attention of the non-gpl modders, explain them as good as possible what it is all about. Every old mod released under gpl would be great benefit not only for the game but also for the whole gaming community. But of course everyone is free to do with their creations what they want, and non-gpl mods are ok of course. I just want the modders think about the licencensing first  - in the end it's their decission.

you are probably right. On the other hand q3 compatibility also means that many tutorials also work for OAe. Before something is changed in OAe that breaks q3 compatibility it is important to discuss if and why this step is necessary.
exactly. Maybe we can even get some help from OpenUsability:
http://en.wikipedia.org/wiki/OpenUsability

yup, that's exactly what I meant.

the name
well, as I said this is not the final name. I just like the name OA :)
I also want to make clear that this project has it's origin in OA.
But I understand your arguments and I have no problem with a new name (ideas are welcome)

@dmn_clown


At least a detailed step-by-step tutorial would be useful. Maybe some kind of script that makes this even easier.
So QuArK designed maps are not readable with GtkRadiant?
it is always good to let everyone know that there are certain rules of behavior :)

I like the code of conduct of Ubuntu and I wished more projects would work with
such a guideline.

cheers
MilesTeg

this is very simmilar to what i suggested in another thread :D

its a good idea.... cloning quake 3 has been done to death imo.... i would love to see a game that is truly open and shaped by the community.... encompassing old school team fortress style of play to counter strike to maybe even out in the open battlefield style of play


that would be the dream :D:D:D

hmm, "don't be a dick" does kind of cover it really.   :-)

shrewd.user, on the subject of "open battlefield style of play", have you got any maps sketched out yet? i've been working out the techniques for modelling buildings and i'm ready to start mapping, i just need a plan to work to. doesn't have to be anything fancy, just some rough scribbles will be enough to get me started.

thanks.
white haired boy.

http://openarena.ws/board/index.php?topic=213.msg1082#msg1082

enki did a good job on that


QuArK designed maps will not open in GtkRadiant 1.5 (At least on my build which is pretty vanilla other than being 64-bit native) They will open in Q3Radiant stable, however, but the conversion process will mess with texture alignments.  Q3Radiant is under a different license, I believe.


But it hasn't been done under the GPLv2

battlefield is something i'm not as experienced in (i was always more of a counter strike person)

but if you ask me, battlefield maps are generally coastal, so firstly pick a nice little piece of coast (google maps?) and make that your battle area.

battlefields set up is generally one force invading via sea/air and another intrenched at the back of the battlefield (its not 100% realistic but the idea is more or less balance, so that each team hasn't got any advantages over the other (besides skill and planning))

then of coarse there are capture points and various buildings dotted through out the landscape to provide cover...


but battlefield style gameplay doesn't exist yet and battlefield style maps are a much harder undertaking than counter strike or team fortress (team fortress is generally a perfectly symmetrical map so it would be the easiest)

if counter strike style gameplay were to be made, then the first thing would be to port or re create the classic maps (which have been around for almost a decade :P )

here is a list (with pictures) of how CS maps generally look (floor plans incl)
http://hl2.gamona.de/content.php?id=66&tmpl=counterstrike

Maybe a Capture the Flag with stuff (http://www.cmukgb.org/activities/ctfws.php)?

How about a snatch style game as seen in Postal 2?  It would be terribly easy to do.

I was poking around in the GtkRadiant code earlier when I ran across this:


in a main portion of GtkGensurf's code.  We wouldn't be able to distribute the gtkgensurf plugin (Handles terrain) even if it would build as that is clearly incompatible with the GPL (I would assume iD has permission to distribute it).  The best we could do is provide the oa.game folder and oa.game file without getting hold of  Jonathan Richard Shewchuk  at an email address that is 10 years old.

Two sides with multiple classes. Players gain the "power" or "mana" of others by killing them - Highlander-esque. Each player has three skills that drain the power that they acquire. Without skills, a 1 on 1 duel takes 2-3 times longer than one in DM.

Multiple object schemes that are simple. CTF / theft variant. King of the hill variant. Etc.

It was the basis for a mod I had in Q2 that never left public beta status (Q3 came out and people lost interest). It had a decent following when it was around, though. It had a Futuristic Nordic Mythology theme that I thought was kind of neat. Each class represented a clan that followed a specific god. Odinists, Frigg / Freya worshipers, etc.

Just putting an idea out there...

Maybe we cannot distribute it under the GPL, but it is still legal to "provide a package with an automated installer that does all the work or make a customize version" as long as we "redistributed under the condition that the copyright notices are not removed, and  no compensation is received".

This "pack" does not have to be part of OpenArena itself.
If it really was wanted to use a "only GPL" editor, then that plugin shouldn't be used for editing in the first place.

If it is true that ID gained permision to distribute the whole plugin as GPL (does the download page explicitly say that the sourcecode is GPL without exception?) that would mean that any distributed and derived work is also under GPL. Something like a relicensing.


EDIT: According to (https://zerowing.idsoftware.com/svn/radiant/GtkRadiant/trunk/LICENSE)

Does it is LGPL?
I don't know. But inserting this "CC-sa-nc"-ish license in the middle of a GPL-BSD-LGPL work and dont warn it doesn't make much sense.

but mapping with blender is a PITA, its easier to have the terrain exported to .map then to .ase

The bulk of GtkGensurf was written by D. Hyde of Loki fame and is LGPL (It would have to be because of the extra restriction).
The file I pulled the license header from was part of triangle circa 1996 (The mesh generator used by gtkgensurf).

It would be far easier (And safer legally) to point to GtkRadiant (Or QuArK for that matter) from the wiki and just provide the needed oa.game directory and file in a zip file to be extracted within the gtkradiant config directory and explain QuArK's rather minimal setup requirements.

p.s. triangle is definitely _NOT_ LGPL

/agree

Also if gtkradiant 1.5 is different from 1.4 it might be good to provide config files for both(assuming both OA and raidant are installed in the default locations).

*reanimated*
ok, three months have passed and I couldn't find the time to continue the planing stage of OAE. But sometimes stepping away from an idea gives you a more objective view of what is necessary and what's not. And altough I don't have much freetime I'm still very interested in this project.

My first and most important thought after thinking about OAE again was: "We are trying to create a game that has everything - that are too many goals to achieve. We should work in little steps".

This basically means that the project can't focus on new gamemodes (king of the hill, counterstrike etc.). Yes, the longterm goal is to allow an easy flawless integration into the game, but nothing more (yet).

So the steps should be in the following order:
1. get some basic content (mostly done with openarena)
2. modify the game engine to make it more flexible (userfriendly, finding a good way to integrate mods) - THIS should be OAE now
3. create new gamemodes, other new content - this should be OAE mods or conversions of Q3 mods
4. (and maybe later integrated into the main game)

Step 3 and 4 is far fetched and relies heavily on step one and two!
Don't get me wrong, I really like the idea of new gamemodes, but OAE shouldn't actually build the new modes - it should build the fertile ground where new, GPLd gamemodes/stuff can (easily) be integrated.

Again, think of it as a linux distribution: You don't actually work on every little program, you just make sure the programs available are working good together and if not adjust them a bit.

Next, we should distinguish between Developers, Gamers and people who run servers. How can we make the game better for these groups?

The two big things that need attention first are game code (how the game manages options) and user interface(s) (let the user access the options in a comfortable way).
As you can see the work that needs to be done differs from the work for OA (content creation - coding).

Actually I'm not very familiar with programming Quake3 but I know the basics of C and as we have to work with the game and not the (highly complex) graphics engine coding should be a realistic goal.

cheers
MilesTeg

there are a lot of benefits to concentrating on the game code instead of the graphics engine code. since the game code goes into the platform independant qvms you can avoid all the hassle of compiling stuff for multiple architectures.

if you're not planning to alter the graphics engine then OAE can be run as an openarena mod to start with. the advantage of this is that there wouldn't be a hefty download for people who wanted to try it out. they'd just download the mod's pk3s into a folder next to baseoa and select it from the mod menu.

something i'd love to see added to the game is climbing. it's something that i've seen in a lot of quake3 mods and it would be great to have it in OAE. jumppads are fun, but ladders/drainpipes etc would be better if a mapper wanted to do a realistically styled map. i imagine it wouldn't be too complex to code.

Like the ladder in dm4ish?

damn, i missed that.   :-)

i've just played that map and the ladder is ok for going up, but there doesn't seem to be a way to go down it. pressing crouch doesn't do anything and pressing the move back key just make you step back off the ladder and fall to the ground. i guess that type of ladder is ok for quake3 style gameplay, where you charge around the whole time and slowly climbing down a ladder will get you killed.

at least ladders exist in the code and can be tweaked if need be. that'll be easier than starting from scratch.

That isn't coded into the game, that is just the clip step trick.

i briefly read the thread.
your plans seem to want OAe to be a stand-alone game, not a mod.
i'm sorry but i think this is a bad idea (if it is a stand-alone game)

i just have a hunch.

actually I'm not yet sure what the best way is, but it will definitely start as a mod project for OA.

edit: concerning ladders: I just got a look at the q3 and q2 code of pmove (player movement) and they are pretty similiar. I think I will try to adapt the q2-code. While I am at it I will try to add a conveyor belt functionality, but no promises as I'm still a noob when it comes to quake programming :P

You should also look at increasing the max number of vertexes that can be used in a given group.  The md3 format allows 4096 vertexes per group but the engine and q3map2 are limited to 1000.

It's a fairly easy hack of both the engine and q3map2 to allow more detail in any given model.

This mod should inspire a bit. A cgame.qvm that adds nifty particles and crap without touching the game.qvm/ui.qvm

http://crypt.planetquake.gamespy.com/effectsmod.htm

fileplanet though :x

I found an old tutorial about adding particles effect to QII. I don't know if QIII particles codes are compatible with QII one, but I hope it will be useful.^-^   
http://www.submarine.org.uk/tutorials/engine.php (http://www.submarine.org.uk/tutorials/engine.php)

Kills tried to add tremulous' particle systems to cgame and ran into annoying traps that prevent the cgame particles stay cgame only :/