Skip to content

2023 05 25 Dev Meeting

Jump to bottom Edit New page
Benjamen Meyer edited this page May 25, 2023 · 1 revision

Dev Team Meeting

  • No preset agenda. Will have to do better for next time.
  • Review where each person is
  • Discuss where we wouldlike to go

Attendees

Notes

Where we are

Ben

  • Working on header guards while learning the code base more; learning a lot from this
    • Found some 3rd party code (pk3.h, expat.h, posh.h) that is just dropped in
    • Less separation from the Python code than we realized
  • Wants to get more involved in code now
  • Going to try to integrate PR #754 in smaller chunks, using it as an outline.
  • Found some 3rd party code, and will attempt to migrate it into its own library in our code base to make it easier to distinguish and maintain now; and perhaps move to pulling in as a dependency (in the long run)

Roy

  • Outstanding PR, which was waiting on #754
  • Looking to migrate from SDL 1.x to SDL2, support future migration to imgui library for widgets
  • Migrate Input Code into its own library
  • Start getting familiar with the game assets and updating them so it's not stuck in once place

Stephen

  • GitHub Actions are running on Node 12 and need to be updated.
  • There are some changes that were on top of PR #754 that need to get integrated since those PR #754 was reverted.
  • We need to update platforms.

Where we want to go

We have a wide and varied discussion on a number of topics. The sub entries are not in any particular order (nor was our discussion) so this is an attempt to bring the topics together in a more organized fashion that our discussion was.

Continue the game engine? Or just the assets?

Stephen raised the question of should we continue the game engine side of the house or should we port the assets to an existing engine like GoDot. Roy and Ben brought up the points of how tied together the game assets and the engine are, and while we could possibly do that for VS:UtCS it would mean the end of PWCU which we do not want see happen. We estimate that it would be at least as much work to move off the game engine as it would be to continue resurrecting this engine, and at least in resurrecting this engine we would still have a playable game during that time period.

ADDENDUM NOTE: In the previous iterations of this discussion it was pointed out how different the VS Engine is in terms of its Space Sim capabilities from other engines out there. It occupies a unique space and calculates out to very exact physics capabilities which is why we use a lot of Double Floating Point data storage. We should not lose sight of this in these discussions.

Python and the Game Engine

The Python interface is highly integrated throughout the entire game engine right now. As part of our refactor we need to isolate this more to make it easier to all work with. This might mean making wrapper code that is exposed; but it would give us a clearer idea of what the API is.

Ideas: Aren't they wonderful?

There are a lot of ideas denoted in the game via comments and partially implemented code. Many of them are great ideas. However, at this time we just do not have the resources available to go after them all.

Our goal is going to be stabilizing the game engine as it is now, and simplifying it so it can be more easily worked on. This may mean undoing some things that were done as we untangle the knots. We do, however, want to document the ideas in our Issues and Project tracking so that we do not lose out in the long run and perhaps when we do have time we can revisit them in the future.

As part of simplifying we are going to recognize that computers today are not what they were when the original developers started the work. In that realization we are making the conscious decision that if there is some code that does things to save memory at the cost of readability we are going to move away from it since we are not limited to 128 MB of RAM and 256MB of swap memory any longer. Some of these may cost a little in performance; however by straightening out the code paths we will ultimately increase the performance and make it possible for more contributions as more people will be able to understand the code.

AI

Roy noted that there are some other tool kits out there that could help expand the game in meaningful ways - even ways to generate more realistic content.

  • Stable Diffusion
  • Skyrim/Modkit - integrates 3 AI driven tools to help build out content, including ChatGPT

These could make for some interesting abilities within the game engine.

Assets

Roy discussed paying for storage of the assets so we have them more readily available. Ben mentioned that we have a little money to do so in our OpenCollective account; though we are not presently paying for our existing infrastructure as JP (www2000) is currently paying for our Domain and server usage (mail, website) which is piggybacking off his own systems.

  1. We would like to have a better understanding of the assets that are there.
  2. We would like to be able to do CI testing with dedicated assets, and develop a Selenium style tool for Vega Strike for automated testing.
  3. We want to be able to regenerate the same universe over and over similar to how other games (f.e Minecraft) is doing it where the user provides a seed value. This will be especially important for re-introducing the network play functionality.

Modernize the game look?

Stephen raised the question of should we modernize the look and feel of the game? Ben noted that we should have a good separation of the game assets and the game engine so that Game Assets can make that choice, and we may already have some game assets in the game (R'laan vessels?) that may have more modern looks too.

Ben would like to see us provide an excellent game engine that game designers can build games upon. If we stabilize the game engine and build out clean interfaces that will allow it to happen.

OpenGL vs Vulcan

We discussed the potential of migrating to Vulcan; however, we just do not have the resources to do so as Vulcan is a lot more detailed framework to work with. At this time we do not feel that OpenGL will be going away in any meaningful manner so we are going to stick with using OpenGL for the foreseeable future.

Boost

We would like to upgrade our base Boost version so we can start taking advantage of more Boost functionality, like the Boost JSON parser.

Platforms

We agreed we need to limit the platform support more, and define what is needed for support. Some of this will still need to be defined but as an initial round we are going to add the following requirements:

  • Computer Hardware needs to be within 5 years of age
  • OpenGL 4 Support

Automated Testing

We want to be able to do more automated testing throughout the code base and doing so without running the entire engine. This means the following things:

  1. Having a set of assets for testing
  2. Being able to drive the game engine using the assets using a framebuffer and programmable interface - a Selenium of Vega Strike system.
  3. Being able to unit test any part of the code without having to run the entire engine.

0.8.2

We need to get a new release out for the community as the 0.8.1 is not building with Python 3.11. There are a few changes that need to be made on 0.8.x to support this:

The Long Road

We recognize that we have a long road ahead of us. We are taking our time and as volunteer contributors we know that everyone has to first put food on the table. However we all love the game and while it may take a while to make these changes it is still a doable process that is well worth it.

Future Meetings

Our last meeting was in 2019. We would like to start holding these meetings on a more regular cadence - every few months. Future meetings will hopefully have more specific agendas to go with them.

Add a custom footer
Clone this wiki locally