Revival of JKA's modding community

[gerbilOFdoom]

Scripting would make contribution much easier. I have a hard time getting into C/C++ but I can handle Javascript or LUA (mostly Javascript). Scripting options for: Bots/NPCs, Entities, and Objectives/Scores/Server Console Commands. 

 

From there, a larger "gateway" server would be nice. Something to show how many players are online, excluding bots, that you can use to walk through a portal to another server for gameplay and also as a hub for chat and simple dueling.

 

Someone find Robophred and drag him out of retirement. Lugormod has some features that made gameplay fun when I was still active.

 

Also, here's a terribad idea: crowdsource donations to modders as bounties for developing a content for our great gaming clickbait?

[Raz0r]

Money is not what JA's modding community needs, and I won't be doing any work for money. It doesn't cost money to produce content.

[NAB622]

Money is not what JA's modding community needs, and I won't be doing any work for money. It doesn't cost money to produce content.

 

I would say it can cost money, depending on the content. But true art is born from passion, when money (Or the lack thereof) is no object.

 

And no, I don't intend to do any modding for money either, it just.....seems silly.

[DT.]

Tbh with the new battlefront out, we need to get JKA as modern as possible if we want it to survive. The only thing JKA has going for it is the ability to mod. So modern graphics, physics and perhaps a new map format could bring in a new crop of modders. New game types and content using a more modern JKA would bring in players.

[DT.]

I was thinking. Why not implement the doom 3/quake 4 map format as an upgrade?

[MagSul]

I was thinking. Why not implement the doom 3/quake 4 map format as an upgrade?

Could you explain what this means to the uneducated? ^.^

 

Also, I'm genuinely curious as to what sort of additional gametypes people would want to implement. o.O

[DT.]

I read somewhere on the forums about bullet physics and BSP crap so I figured Doom 3 might have physics stuff for its BSP but I dunno tbh, just tossing ideas.

[UniqueOne]

To select a good map format, I believe the best way would be to look around at what editors are available for the various formats. Support the most common format with a good (and most importantly, easy to use) editor. An opensource editor would be best, but this is not required (specially if there are multiple editors available).
 
For gametypes. I say remove them all. If we have a new editor and map format, then gametypes should be combined into various map areas.
want to duel? go to the arena
want to pve? go to the wilderness or dungeons
want to pvp? go to the pvp areas - fight over structures (possible guild integration and ownerships?), etc...
 
This is what I hope to do with the warzone mod, but it will take time with so little help... but honestly, replacing map format is beyond my levels of experience. Unless someone here that understands this stuff can do it, I am going to have to make do with bsp and its horrible limitations *sigh*.
 
This is the biggest map I am able to do in JKA with BSP format. It is 32768 x 32768 x 18000 (i'm guessing about 1/4 of the size of the skyrim map). q3map2 can not vis or light it, however, because bsp sucks so badly. Fortunately rend2 can do sun lighting and shadows.

 

I really, really, really, wish we could replace this crappy format and let the engine be once again modern.

[Ramikad]

This is the biggest map I am able to do in JKA with BSP format. It is 32768 x 32768 x 18000 (i'm guessing about 1/4 of the size of the skyrim map). q3map2 can not vis or light it, however, because bsp sucks so badly. Fortunately rend2 can do sun lighting and shadows.

 

Huh? You mean that's the max limit you managed to achieve all things considered? Because I made a test map as large as 128000x128000 units, not sure the height, BSP only.

[UniqueOne]

Huh? You mean that's the max limit you managed to achieve all things considered? Because I made a test map as large as 128000x128000 units, not sure the height, BSP only.

 

Was the map a flat surface or a terrain? I guess making a flat single large surface would work, but wouldn't be much use

 

This map is a bumpy terrain, although I had to use pretty large triangles to make it compile. Without any vis or light. There is currently also no structures on the map, and the foliage is added by the client, not q3map2 (so no effect on limits there).

 

Q3 is really showing it's age with bsp. If this game did not have a star wars license I would not even bother to mod it and move on to a new engine. We are all wasting this license with the restrictions of bsp.

[Ramikad]

A bit "hilly", though with little height difference - I think it's more or less 3000 or 4000 units at best. I used the GtkGenSurf plugin for Radiant 1.3.12, if memory serves me well. It has a very low brush count, though, 512 brushes for the terrain, with a very generous size of 8032 units per brush. But aside from that, Radiant 1.5 can compile maps up to 64000x64000, I think.

[UniqueOne]

A bit "hilly", though with little height difference - I think it's more or less 3000 or 4000 units at best. I used the GtkGenSurf plugin for Radiant 1.3.12, if memory serves me well. It has a very low brush count, though, 512 brushes for the terrain, with a very generous size of 8032 units per brush. But aside from that, Radiant 1.5 can compile maps up to 64000x64000, I think.

 

Ah yeah. Figured it would be something like that. The problem is getting reasonable detail as well as size. Just so many limits that can be easily broken.

 

I think the brush size I used was 1024 (still rather crappy - although fortunately the foliage system does hide it somewhat), but i'm not sure. I had to screw around so much with it to get it within the limits... I also had to remove all the caulk and skip surfaces in notepad *sigh*.

[minilogoguy18]

When it comes to better map formats as well as maybe a better map editing program maybe we should look at some of the more modern engines that were based on Q3 originally like what @@DT85 said, Doom 3/Quake 4 and even the source engine which is just a modernized Q3.

[UniqueOne]

When it comes to better map formats as well as maybe a better map editing program maybe we should look at some of the more modern engines that were based on Q3 originally like what @@DT85 said, Doom 3/Quake 4 and even the source engine which is just a modernized Q3.

 

Only thing that worries me about selecting D3/Q4 formats is they are very heavily biased to the old corridor running maps. They would overcome a lot of limits I imagine, but are not really suited to anything like a large star wars universe. When JKA was created there really wasn't anything better, but now I think we could find something more generic and yet common.

[minilogoguy18]

Yeah but I was just giving examples of 2 engines that are pretty much more modern versions of this engine (don't forget valve source was based on Q3) that would probably require the least effort to implement and have superior editors.

[eezstreet]

I think @@UniqueOne has the right idea here. The mapping format you have should be based on the content you intend to design with it in mind. I've done a little bit of research on the subject, and there's a few different systems:

- Voxels (Minecraft). Grid based system with uniformly sized units, although players, creatures etc can be oriented on fractional units. Can also be said of tile systems like the ones in the original Fallout and Diablo.

- Cell Structure (Skyrim). Maps within maps within maps...

- BSP structure (Quake). Basic geometry which is rendered to the client with potentially visible sets (PVS) as opposed to distance based

- Megatexture (Rage, parts of Quake 4). Geometry is mapped from a (freakishly giant) texture which is compressed.

- Hybrid (Most UE engine games)

- Procedural (No Man's Sky). Content which is generated on-the-fly and may or may not conform to any of these.

 

Now of course you can use these with dynamic loading or generation procedures or you can keep it static. It doesn't really matter. I have probably left out a few things anyway. The problem is that you can't develop a catch-all system that encompasses all of these systems and have it work well. I think it should honestly be up to the modmaker to implement whatever mapping format they want to do. But certain improvements like the mapping system in Doom 3 seem feasible. I would honestly like to see the BSP code be cleaned up a bit and externalized in such a way that it can be replaced rather easily. But everything is organized in such a way that it's all interconnected.

[Archangel35757]

http://www.gamasutra.com/view/feature/131625/octree_partitioning_techniques.php

[UniqueOne]

I tend to think of the choices the cells system (map within map within map) is most suited to star wars universe. 

 

Cell based, not only for planetary environments, but also the options there for large scale space based maps - think eve online style system when you have a universe map, with a cell inside that for solar system map, etc down to whatever scale is needed. Semi-inifinite possibility there on scale. Imagine if old bsp's could be even loaded as the lowest level cells - allowing all the older maps to still be used as part of a huge universe. Not saying this would be easy, but it is possible, and would be fracking amazing and blow any previous (and most likely future) star wars games out of the water.

 

Sure some of the other methods could do similar in theory, but I am guessing this would be the easiest to implement.

 

Agreed on cleaning up bsp into some sort of module system. Would be a good move long term - maybe even make it api compatible with something like ogre? That would outsource format updates. 

 

I would love to also see this done for model formats (much less important then map format - glm is ok), but there are other issues there like bone compatibility between formats. In theory bones between humanoids in most games should be fairly compatible and in some cases, convertable - eg: my looking into skyrim humanoid nif skeletons look to be almost 1 to 1 complatible bone structures with glm, but with different names - there are many body mods made by the skyrim community that are free to use in other games as well - not to mention all the non-body community stuff like clothes, foliages, trees, textures, sounds we could be using. The permissions to use them all are listed on the download pages of mods on nexusmods. Could be a massive boost of resources to modders in JKA if we could support this stuff. Why reinvent the wheel when its already freely available to us

 

On a side note, was chatting with xycaleth earlier about the possibility of enhancing detail on close range objects/terrains by subdividing and smoothing, and he found this library created by pixar and microsoft http://graphics.pixar.com/opensubdiv/docs/intro.html . Could be interresting?

 

 

When I think about how amazing JKA could be with the underlying limitations removed it blows my mind. With the right tools, the community could do what no game company will ever do right - a true star wars universe. We have a license and no deadlines. All we need is one person (who has better knowledge of this low level geometry code then I) to step up and create the building blocks.

[DT.]

I wouldn't choose source engine, hammer is so shit to use. I dunno whether it's the map or the game, but I really hate that little loading thing that happens in HL2 SP.  I'd rather Doom 3/Quake 4 because I know the Quake 4 editor is built into Quake 4 itself and we could do the same thing.

 

Would we need to match licenses or can we just implement any format @@ensiform @@Raz0r @@Xycaleth?

[Xycaleth]

As long as the person implementing the D3 map loading hasn't read how the D3/Q4 code does it then there's no licensing issue. The problem comes when you're basing your code on the D3 code as you're creating a derivative work which must be licensed under the same license as the original (and this license is incompatible with OJK's).

[Raz0r]

In short, we're saying that in order to really revive JA's modding community, we need to work with something that isn't JA :^D

[ensiform]

Only thing that worries me about selecting D3/Q4 formats is they are very heavily biased to the old corridor running maps. They would overcome a lot of limits I imagine, but are not really suited to anything like a large star wars universe. When JKA was created there really wasn't anything better, but now I think we could find something more generic and yet common.

These constraints are not going to mysteriously vanish from the engine though even if the map editor and potential compiler can do more.

I wouldn't choose source engine, hammer is so shit to use. I dunno whether it's the map or the game, but I really hate that little loading thing that happens in HL2 SP.  I'd rather Doom 3/Quake 4 because I know the Quake 4 editor is built into Quake 4 itself and we could do the same thing.

 

Would we need to match licenses or can we just implement any format @@ensiform @@Raz0r @@Xycaleth?

Realistically implementing the renderer and or editor together shouldn't be very difficult to do in the long run if starting from scratch. 

[Archangel35757]

In short, we're saying that in order to really revive JA's modding community, we need to work with something that isn't JA :^D

Interesting... maybe we need a combination of different data structures that work in harmony with one another?

 

http://gamedev.stackexchange.com/questions/5493/whats-the-state-of-the-art-in-space-partitioning-for-games

 

http://www.gamedev.net/page/resources/_/technical/game-programming/introduction-to-octrees-r3529

[Raz0r]

01:18 @<Raz0r> let's brainstorm an ingame editor!

01:19 @<Raz0r> we should determine the major difference between radiant's rendering and JA's rendering (e.g. space partitioning, sorting, culling) to see how feasible it is to render an interactive map

01:20 @<Raz0r> store only bare minimum of brush data in interactive mode, occasionally 'baking' it / producing bsp. we don't require expensive baked lighting - even better if we can do dynamic/deferred lighting in rend2

01:21 @<Raz0r> it wouldn't be too hard to allow multiplayer map editing either

01:21 @<Raz0r> entity editing should not use actual entities that are spawned, it should not have any state

01:23 @<Raz0r> should probably have a gamestate akin to /map blah, with /editmap blah, rather than engaging in map editing during a regular game?

01:23 @<Raz0r> should only implement it once in MP. will be able to edit SP maps just fine, with the added benefit of cooperative editing

01:26 @<Raz0r> synchronising map state shouldn't be too hard of a problem if we're essentially working with .map files in memory, the low frequency of state changes means a common ancestor will be easy to find

03:46 @<Xycaleth> Raz0r: radiant draws everything with glBegin/glEnd :>

03:47 @<Raz0r> okay, well we can probably do better than that

03:48 @<Raz0r> background baking of "committed" geometry

03:48 @<Raz0r> even just on the server, then send that blob out

[DT.]

An in-game editor would also allow preview of any model (misc_model_static's & misc_model_ghoul amongst others).