search

thecheeseman / iocod

Open source implementation of id Tech 3 based on the Quake 3/RTCW GPL releases. Currently WIP
https://iocod.org
GNU General Public License v3.0
30 stars 1 forks source link

Progress on ioCoD #10

Open stoofphen opened 1 year ago

stoofphen commented 1 year ago

Hello there, I saw this and it really piqued my interest (as I am an avid mapper and modder for Call of Duty United Offensive). Thought I'd post a message to see how this project is going, and was wondering what the plans are regarding Singleplayer support?

I exclusively mod for Singleplayer. While I have spent basically over a decade exploiting the CoDUO engine and learning of its limitations (surprisingly can handle a lot of complexity compared to some of the later id Tech 3 games), I can see that expanding the capabilities of the engine to allow for even larger maps, more detail, and of course more scripting functions would further fulfil its potential, quite amazing to think the fact it is a id Tech 3 based engine, though it has also diverged so much.

Thought I'd share (or perhaps 'brain dump') some limitations and creative constraints that come to mind, from my experience, that could be addressed as part of ioCoD to take advantage of the 20 years of computer performance development since the engine was originally conceived:

  1. Xmodel Level of Detail Culling Considering that the CoDUO engine allows for 2,045 visible xmodels in view at any given time, this does not consider the xmodel 'Low LoD Distance' which practically culls the xmodel beyond this distance (thus going from High->Medium->Low->Invisible/Culled). I believe this is something addressed in Call of Duty 2. Would make sense to also higher the limit of visible models alongside this.
  2. Limited number of Weapon / Vehicle definition files (127) I believe there is a limitation on the number of Weapon definition files (and Vehicles), about 127, while this does sound like a large number, keep in mind the game already fills most of this with the various weapontypes (also the 'semi' / 'automatic' versions takes up an additional slot).
  3. Unique Xmodels allowed to be loaded in a level (255) There is a limitation on the number of unique xmodels that can be loaded / precached into a level (255). Again, this number can easily be reached when dealing with various model attachments to character models in particular.
  4. Level geometry While nothing specific here, I think it is obvious that being able to allow for higher limits on the key components of levels would be desired; such as entity limits, amount of brush geometry / terrain patches, increased size of level region (size), number of pathnodes, number of concurrent AI (I think it is limited to ~32 alive AI). Perhaps consideration of increasing the limits on lightmaps and shaders of geometry as well.
  5. Q3map compiler and Radiant/Graydiant CoD and CoDUO use a fairly dated version of q3map, the map compiler. The newer Q3map2 has been developed for most id Tech 3 games, however support for Call of Duty has not been included as of yet. Not sure if you have plans to upgrade the map editors in addition to the engine code? I think Radiant / Graydiant could do with some updates to make it more user-friendly and aligned with some of the latest level editor functionality also (such as NetRadiant).
  6. Number of Sound Channels Probably another obvious one is to consider expanding the number of concurrent sounds that can be played also, probably not as crucial though.
  7. Vertices / polygon limit of xmodels Another one in terms of expanding the limitation on vertices / polygon allowance for xmodels. I don't generally meet these limits, though I think I have had some issues with converting XMODEL_EXPORT to the xmodel format because my model had a single texture applied to more than ~4,095 vertices.
  8. Scripting While you can do so much with the level scripts, there could be so much more in terms of potential (and functions). One key thing is I feel like the minimum wait time on a while(1) loop is equivalent to 20fps or so (despite setting to wait 0.001), being able to have loops that respond on a frame-by-frame basis much more closely would make some results look far better and more smoother. It would also be great to have the ability to apply the left/right/top/bottom 'arc' restrictions to the player's view, as can be done in CoD4+ with the PlayerLinkTo functions (example: PlayerLinkToDelta( , , , , , , , )). Also integrating the script function to read if a particular key has been pressed would also be very useful (ButtonPressed( )).
PrawyCoD1 commented 1 year ago

https://github.com/thecheeseman/iocod/tree/new-dev