|
Post by fourfire on Jul 5, 2016 21:57:27 GMT
Hello, I am a technically inclined, biology interested futurist, who does not yet know programming. I would like to learn programming and eventually, coding in a language such as C++ and this game is quite relevant to my interests, thus I wish to contribute in some way which also helps me learn useful skills along the way. I need help setting up my developer environment as I have never done this before, if someone is available to help me, I would prefer to communicate in real-time through IRC, mumble, Skype, Hangouts, Slack or Discord if possible, otherwise I suppose the forum format, or email will do. I hope I can at some point push the development of the game further along and I am primarily interested in learning the mechanics of the engine and looking to optimize performance where possible. (The game seems to be way too slow compared to the amount of realtime computation that seems to be required, unless the metabolism calculations are a couple of orders of magnitude more complex than the game lets on).
|
|
|
Post by Moopli on Jul 5, 2016 23:11:17 GMT
> I suppose the forum format ... will do.
Splendid! What are you stuck on?
> I am primarily interested in learning the mechanics of the engine and looking to optimize performance where possible
I could give you a bit of a rundown if you like, though I'm not sure how easy it is to explain so it makes sense to someone who doesn't know how to program.
> The game seems to be way too slow compared to the amount of realtime computation that seems to be required
Oh definitely. We have a lot of code running every frame in Lua, which we've been working on fixing (by rewriting stuff in C++). Further, we're working on making the background simulations run less frequently than every frame. That's a big job though, so the only major speedups you'll see soon are going to be from script optimization.
If you don't know programming, though, then helping with any of that soon would probably be a tall order.
|
|
|
Post by fourfire on Jul 6, 2016 6:30:00 GMT
> Splendid! What are you stuck on? I get to step 8. Here "* On the next page, browse to C:\MinGW\cmake\toolchain.cmake (or wherever you installed the build environment) and click "Finish"" And These errors appear. If I try to set the source folder to "C:/Thrive/Thrive-master/src" it throws an error about CMakeLists.txt (which to me indicates that the directory is correct) Furthermore, attempting to open *.cpp files regardless with Code::Blocks permits me to view the code but the IDE throws an error about the compiler being missing or something similar, the instructions seem a little unclear on troubleshooting options. > I could give you a bit of a rundown if you like, though I'm not sure how easy it is to explain so it makes sense to someone who doesn't know how to program. I would appreciate it; though I don't know syntax or advanced data structures such as arrays, I do know some of the basic programming concepts so I don't feel your time would be entirely wasted. > If you don't know programming, though, then helping with any of that soon would probably be a tall order. I'd like to see first
|
|
|
Post by Moopli on Jul 6, 2016 15:40:40 GMT
> These errors appear. Hmm, so far it doesn't look like you actually have any errors. The panel in that picture with all the red lines is the place where CMake shows you all of the variables it has set -- CMake essentially works in two steps, you click "Configure" to tell it to run its scripts (which the developers write) to figure out all the specific values for various parameters that the compilation will need (for example, where it can find various libraries), and then you click "Generate" to generate the build files. It sounds convoluted, but the main idea behind CMake is that different operating systems and different compilers or build systems need different build files to control compilation; and CMake is designed to be able to read the same scripts and configure the same project to compile on a wide range of different systems. When you're developing you sometimes need to modify the CMake scripts to add new libraries, source files, etc, but when you just need to build all you should have to do is click Configure, skim through the message log (the bottom panel) for errors, and if it went ok, click generate to generate build files. And setting the source directory to src/ won't help, since the CMake scripts expect the source directory to be the main thrive directory (Thrive-master). When you run CMake, it runs the CMakeLists.txt CMake script in the source directory you point it to, and the one in src/ only lists source files and source subdirectories. The one in Thrive-master is the one that actually does all of the build configuration (which includes invoking the script in src/ to get a list of all source files). I think the Code::Blocks error might be because you haven't generated the build files yet, so Code::Blocks complains that it can't compile the code. I'm not sure though, I use Linux. > I would appreciate it Awesome, here goes: The engine uses the 'Entity-Component' design pattern, which basically means that we break down every object in our game (for example, a microbe) into a set of components, each of which has a particular functionality (for example, storing compounds, rendering the microbe on screen, storing physics information and computing motion every frame, or making AI decisions), and then we take the components that are needed for a new kind of object, and we put them together into one set of components, an Entity, mixing and matching whatever functionality we might need for new types of Entity. Added to the Entity-Component pattern, we have 'Systems' -- whereas entity-component is a way to abstract out the various kinds of data we need to work with, the System is a way we abstract out the computation that we run on each kind of component. For example, the physics engine has the RigidBodyInputSystem, UpdatePhysicsSystem, RigidBodyOutputSystem, BulletToOgreSystem, and CollisionSystem; each of which handles a step in the calculation of movement and collision resolution in the microbe stage. Each System acts on all Entities with a specific set of Components: for example, System P might act on all Entities with Component A, whereas System Q acts on all Entities with both Components A and B. To put all these disparate Systems together to make the game, we have GameStates -- each GameState represents a particular 'screen' in the game (Main Menu, Tutorial, Microbe Stage, and Microbe Editor), and has a list of all the Systems that need to run every frame (this is a thing that I referred to earlier, when I said that we're working on making Systems not run every frame unless they have to). We use Lua as our scripting language, and we do a lot in it -- some of our Components and Systems (for example, the code which defines how the GUI in each GameState acts, the code for how microbes work, the code for how each organelle type works, the code for the debug console) are written in it, as well as the scripts which define each GameState (each is defined in a setup.lua file. We just define them in setup.lua files by convention, there isn't any requirement in the code that we only define them in files named setup.lua), as well as some ancillary scripts which are used by other scripts (for example, a file which defines keybindings, and a file which defines the structure of the non-player microbes). As for the other parts of the engine.. we also have some code which interfaces with Ogre3D, the library we use for our graphics rendering; some more for CEGUI, the library we use for our GUI, and for cAudio, the library we use for sound. We also use a unit test toolkit to unit-test a lot of the C++ stuff, which is what all the test/ directories are for. Whatever questions you might have, just let me know. > I'd like to see first I like the way you think
|
|