revolutionary-games / thrive Goto Github PK
View Code? Open in Web Editor NEWThe main repository for the development of the evolution game Thrive.
Home Page: https://revolutionarygamesstudio.com/
License: Other
The main repository for the development of the evolution game Thrive.
Home Page: https://revolutionarygamesstudio.com/
License: Other
For troubleshooting, it would be very helpful to log the output of the setup script to a file that users can upload for diagnostics.
The start-transcript
and stop-transcript
cmdlets may be useful for this, but they have problems as detailed in this bug report. One of the workarounds listed there might be interesting.
Vacuoles should not be specialized storage as it is now, but be able to hold a mixture of compounds.
The discussion can be found in this thread from halfway down:
http://thrivegame.forum-free.ca/t997p150-microbial-compounds-and-organelles
With some configuration files, CPack can easily generate various distribution formats. Most interesting for us would probably be zip and NSIS installer.
Profiling is essential for identifying bottlenecks and optimization opportunities. We could use an instrumenting profiler like callgrind, but they tend to slow things to a crawl, possibly distorting the results and deterring developers from profiling routinely.
The alternative is manual instrumentation, which requires adding profiling instructions to the source code, telling the profiler what we are interested in. There is the Shiny profiler, but it is only suited for single threaded applications.
Then there is the High Performance C++ Profiler, described in detail in this blogpost. It's a little old, but probably still works.
Finally, we could roll our own profiling library, tailored to our needs. Getting this right will require some research to keep the profiling overhead to a minimum, so it's no small feat. But it would allow us to, e.g. render the profiling data in an overlay directly in the game.
There seems to be a bunch of issues that seem actually done but not marked as closed. Clearing them up would allow for easier finding of things to do. At first glance, they seem to be the following ones:
I'm personally waiting on #49 to see if it can be considered done, the other ones seem finished but i'm not sure.
Please notice NickTheNicks comment below
The textures can be found here: http://s1016.photobucket.com/user/sciocont/library/CellstageSprites
We are currently just using pure models for compounds so changing to a texture approach isn't completely trivial. I don't currently have enough knowledge about ogre to make this easily, so perhaps someone else will be able do it.
I'm also personallly having issues with SVN, not sure if this is a problem on my side or the server, but the textures will need to be added to SVN aswell.
As noted in this forum post, agents are a special case of compounds. To avoid confusion and miscommunication between programmers and designers, all current occurences of "agent" should be replaced by "compound".
This includes:
src/microbe_stage/agent.*
src/microbe_stage/agent.*
to src/microbe_stage/compound.*`res/scripts/microbe_stage
for occurences of "agent" and replacing it with "compound"It has been suggested that microbes attempt to achieve a sort of state where they eject extra compounds to try to achieve an appropriate ratio of wanted compounds.
As part of this, I think the processing organelle code should be cleaned up to follow this new structure.
In particular, the code for processing organelles should be migrated to processOrganelle:update()
instead of being hardcoded into the microbe, and should make use of the microbe's programmed methods to request compounds.
The spawn system will occasionally try to index what i suspect to be a no longer existing entity after having loaded. The reasoning i think is due to that entity being created in a now invalid timeline of the game and therefore no longer exists.
Eventually, the game will need to switch between different states. Examples for game states are "main menu", "microbe gameplay" or "microbe editor".
Each game state is associated with a set of active systems and active entities. Transitioning from state A to state B should follow this rough procedure:
Implementing the entity switch could be achieved in multiple ways.
The steps required to bring a model, texture or sound into the game must be documented. They should include:
For textures and sounds (see #35), this should be relatively straight-forward. For models, not so much, as Ogre uses its own custom file format for them.
I recommend using the OgreAssimpConverter which seems to work with many input file formats.
For the time being, we could tell modellers to use the frontend and move the exported meshes to the right location manually. Eventually, a more automated tool might be nice that converts the files and moves them to the right folder in one go, without much user interaction.
Artists should be able to easily test their work in the game. For that purpose, a few tweaks in the resource management might be in order, like adding a "test" directory in resources.cfg
. Also, a way to reload assets in the game would be great to avoid having to restart the whole application.
This is closely related to #32. We shouldn't use git for binary files. It might work for the short term, but eventually, the repository will get prohibitively large, making cloning slow and bandwidth intensive.
For the Christmas Prototype, we could really use some models for compound particles. The planned compounds are:
The models should be easy to distinguish from each other, ideally even for color-blind players.
Use the SharedLock template for exception safe locking
Integrate openAL into the engine. The graphics thread seems like a good place, as sound should not take too much resources.
The script to install OpenAL and link it is done alredy (in the physics branch, wich should be merged soon)
Create an OgreLightComponent
with the following properties (shared as RenderData
):
Ogre::Light::LightTypes type; // Point, directional or spotlight
// Colors
Ogre::ColourValue diffuseColor;
Ogre::ColorValue specularColor;
// Attenuation
Ogre::Real attenuationRange;
Ogre::Real attenuationConstant;
Ogre::Real attenuationLinear;
Ogre::Real attenuationQuadratic;
// Spotlight
Ogre::Radian spotlightInnerAngle;
Ogre::Radian spotlightOuterAngle;
Ogre::Real spotlightFalloff;
Ogre::Real spotlightNearClipDistance;
A complementary OgreLightSystem
should apply those settings to the respective Ogre::Light
, creating one if necessary.
I have finished making some textures for rocks.
Rock Textures:
RT 1: http://i.imgur.com/YjMvIFS.png
RT 2: http://i.imgur.com/nqolsaH.png
RT 3: http://i.imgur.com/KceCjOl.png
RT 4: http://i.imgur.com/DD46bCg.png
Download Link:
https://dl.dropboxusercontent.com/u/137682043/Rock%20Textures%20Set%201.zip
Add a system for continually updating a TextOverlayComponent to display all agents that are stored in the player's microbe.
Add a named entity "hud.playerAgents" and attach a TextOverlayComponent to it. Give it a size and position somewhere in a corner.
To find out which agents are even stored by the player, you can iterate over the vacuoles
table inside the player entity's MicrobeComponent
. Use the AgentRegistry described in #42 to find a suitable display name for the agent and the Microbe:getAgentAmount
function for finding the current amount, then construct a string that displays the information in a suitable format.
To simulate a simple metabolism inside a microbe, organelles for transforming agents (materials) into other agents (products) are required. These ProcessOrganelles should take a set (but configurable) amount of materials from their microbe with Microbe:takeAgent
and, if enough materials are available, store the products with Microbe:storeAgent
.
To make the process configurable, the following API functions are suggested:
ProcessOrganelle:setMaterialAmount(agentId, amount)
ProcessOrganelle:setProductAmount(agentId, amount)
The material and product amounts are stored in a table. The ProcessOrganelle:update()
function iterates over the material table, checking if a sufficient amount is available. If yes, it takes those amounts from the microbe's storage organelles and stores the product amounts in turn.
Currently, the camera is hard-coded in OgreEngine::Implementation::setupCamera
. To make the camera properties scriptable, a CameraComponent
should be created to enable entities to become cameras. The CameraComponent
should have at least the following properties:
Ogre::Real nearClipDistance;
Ogre::Real farClipDistance;
Ogre::ProjectionType projectionType;
Ogre::Radian fovY;
Ogre::Real focalLength;
Ogre::Real aspectRatio;
The accompanying CameraSystem
should create an Ogre::Camera
if necessary and apply the above settings, together with position and orientation from a TransformComponent
.
Hell, it's about time!
The ability to run arbitrary Lua snippets during runtime would be a great tool for debugging and tweaking.
There's an example implementation of an Ogre console here that could possibly be adapted for our purposes.
The control flow would go something like this:
After gamestates were merged into the branch it seems that any lua errors will just give a generic error message instead of being moderately informative as before.
Generic error message looks like this:
terminate called after throwing an instance of 'luabind::error'
what(): lua runtime error
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
The oxygen emitter will instantly, when the game starts, emit 2 oxygen units somewhere on top of / below the player microbe (even tho the emitter is far away from the player) which the microbe will then instantly absorb.
You'll see the microbes process organelle be non-grey due to this. If you disable distribution of oxygen to processorganelles you will notice that 2 oxygen are stored from the start. You can verify that it actually is the emitter by removing the code that generates the emitter in setup.lua, and the two oxygen wont appear.
Bullet offers a feature to hook into a graphics engine and draw stuff that's helpful for debugging, such as collision hulls and contact points.
Unfortunately, we can't use the btIDebugDraw interface to directly draw into the scene, because Bullet and Ogre run in separate threads. So we need an adapter that "records" the draw calls in the Bullet thread, transfers them through the script thread to Ogre that eventually consumes them.
A good starting point for consuming the draw calls is the BulletDebugDrawer.
Add the two lines
SET(BOOST_ROOT ${MINGW_ENV}/install)
SET(BULLET_ROOT ${MINGW_ENV}/install)
to the file mingw_setup/toolchain_win.cmake.in
, then rerun the setup script and test project generation with CMake.
That documentation should list all dependencies (with versions) and common caveats when compiling them.
Additionally, an automated bash script (similar to the mingw_setup) would be nice. The documentation is still essential, though, because the script might not work as expected on all distributions.
I'm not sure whether there is a solution too this, but compilation for me is really slow. I don't know whether it is just that g++ links slowly or that something is wrong with the program. Whatever the reason, if there is a way to fix it that doesn't break anything, it would be nice.
Example: As a test, In Game::Implementation, changing unsigned short m_targetFrameRate from 60 to 61 compiled in 1 minute and 14 seconds on my computer. Changing it back (as a second test run) took the exact same amount of time.
If I make no changes at all, compiling took around 6 seconds. That also seems rather long considering that the program should only be checking the modification dates of files, but if there are a lot of files and the files are scattered across the hard drive, I can see it taking this long.
But for the 1 minute and 14 second compiling, I hope there is a way to fix that. If there is not, feel free to close the issue, but I feel like as the project gets bigger and bigger (more than just the cell stage), compiling is only going to take longer and longer.
Suggestion: Perhaps there is some optimization going on during the linking phase that takes a while. Is there a flag to disable that?
Providing script authors with instructions and examples on how to achieve certain tasks will help in bringing more people onboard for development.
Basic tutorials should include:
Whenever a major component is added, like physics, GUI or similar, the tutorials should be updated to provide a short introduction to it.
GUI elements like buttons, text input or simple labels will be needed throughout the game for menus and HUD elements. They should be completely scriptable in both creation, modification and event handling.
Steps to implement:
After fleshing out the basic microbe structure (see #9), the interaction between microbes and their environment must be defined.
The environment consists of at least other microbes and inert nutrients.
The guidelines should include:
m_
prefix for members)I don't seem to have permission myself with the anonymous user.
Files:
http://www.mediafire.com/download/8h4r8j45krln93o/ATP.zip
Right now, microbes are entirely made up by their organelles. What is actually needed is:
The cell's shape (Which hexes are part of the cell)
The organelles + their orientation (organelles themselves already exist)
Any sort of texturing data (may be handled later)
For now, this is for the microbe stage, but it might be applicable for other stages as well. If possible, the design should take that into consideration. However, if in doubt, simplify in favor of a specialized version for the microbe stage.
The microbe stage is an open world in which the player can move around freely. This obviously requires dynamically creating "stuff" in the world so the player doesn't float around in empty space. That stuff includes
The spawning system should be easily augmentable with new things to spawn. To save resources, it (or a complementary system) should also handle despawning entites that are too far away from the player to matter anymore.
Git doesn't handle binary files like zips, meshes and textures very well. They tend to bloat the repository, because git has to maintain a complete copy for each change that has been committed to the file. Besides, GitHub would like to keep each repository below 1 GB. If we continue putting binary files into the repository, we will quickly reach that.
There are a variety of options to keep binary files in one place and share them amongst developers and artists:
Both the FTP and Perforce server could be set up on the build server, once we have such a thing.
Racing around with the player microbe is fun. For about 5 seconds. Let's add a little more variety and populate the world with more microbes.
To make them do something, we need some AI. For the moment, I think it would be enough to let the AI microbes chase after energy floating in the environment. If their energy storages are full, they should swim around idly until the storage is down to, say, 80%. Or they could chase and harass the player by bumping into him.
Currently, players have very few reference points to gauge their movement speed and direction. Even if there are other objects on the screen, they might be moving, too, distorting the perception player movement.
To remedy this, design and implement a system for displaying "floaters". Floaters are small, mostly transparent particles that are overlayed onto the game world as if looking through dirty water. Those particles are dense enough to be easily visible without occluding the game world.
Floaters will not interact with other objects, but only react to player movement. They will always move in the direction opposite of the players'. When the player stands still, the floaters stand still also.
Before implementing actual gameplay, we require a basic model of how microbes in the game should behave. To get that moving along, I propose the following structural model. Most of this is gleaned from the Microbe Stage Final Draf.
A microbe has a basic shape, either
A microbe has these "attributes":
A microbe has "traits". These traits may modify the microbe's appearance and / or grant additional abilities or bonuses. Examples are:
Traits should be implemented as extensibly as possible. The above linked thread has many more examples of traits and knowing designers, they will come up with even more.
Traits may exclude or prerequire each other.
Traits take up space in the cell. A cell's size must be greater than the sum of its traits' sizes.
As an addition to #14, add a script interface for adding, manipulating and removing viewports in the render window. This could be useful for showing the player events from another place in the world through a picture-in-picture.
The easiest approach would be to add an OgreViewPortSystem
to the ogre engine and an OgreViewport
class for the script bindings. The system should provide an interface for creating and removing viewports in a thread-safe way (e.g. with a SharedQueue). It should also apply any changes that were made to an OgreViewport
since the last frame.
An OgreViewport
should have the following properties, shared as RenderData
:
EntityId cameraEntity;
Ogre::Real left;
Ogre::Real top;
Ogre::Real width;
Ogre::Real height;
Ogre::ColourValue backgroundColor;
Ogre::Viewports
that belong to the same render target are uniquely identified by their z order, which is also fixed at construction of the viewport. To avoid scripting mistakes with duplicate z orders, the script side of OgreViewport
should not offer a constructor. Instead, the OgreViewPortSystem
should offer a function
std::shared_ptr<OgreViewport>
getViewport(
int zOrder
);
This function should either return an existing OgreViewport
or create a new one, queueing it for addition on the next frame.
Conversely, there should be a removeViewport
method in OgreViewportSystem
that takes an existing OgreViewport
and removes it from the render target in the next frame.
It's time to get it out there!
It should include the master branch, the AI branch and possibly the sound branch!
I'll look into it, but if anyone else have comments let me know!
Instead of returning the remaining amount of agent and leaving it up to the caller of Microbe:storeAgent to do something with the residue. Leaving it up to the caller is certainly more flexible, but there is already code where nothing is done with the residue and it would be bothersome to have to manually "drop" it every time you call the function, as this is what i see having to happen almost every time.
I just reached a point while working on #41 where i don't know what to do with agents produced by a ProcessOrganelle that the microbe can't absorb.
I'm not sure how this would be implemented exactly, perhaps a call to a SpawnSystem somehow to queue a drop.
There currently seem to be no way to add custom functionality on collisions, such as actions when microbes attack eachother, so i'll attempt to include it. I already have some very simple working code.
I'm thinking of making a CollisionSystem that relevant collision events are added to and then handled with the update method.
The way to add functionality in bullet seems to be to define a global callback function and assign the global variable gContactAddedCallback to it. That global variable will then queue the events to the CollisionSystem.
Aspects to figure out:
The mingw setup script for Linux is missing a command to install 7za if it's not there. For Ubuntu, the proper package to install is p7zip-full.
They need to be added to the assets SVN and implemented in the scripts.
Currently, our systems all create their own Ogre::SceneNodes
when necessary. See for example MeshSystem::update
, where for each entity that has a MeshComponent
, an Ogre::SceneNode
is created.
This could prove inefficient if an entity has multiple components that all require an Ogre::SceneNode
to function. Those components should share a scene node. To that end, we should introduce a new Component, aptly named OgreSceneNodeComponent
. This component would not need any properties (at least not yet), but would only hold a pointer to the Ogre::SceneNode
. All systems that require such a scene node, like MeshSystem
and the proposed CameraSystem
(see #14) could add OgreSceneNodeComponent
to their entity filter to gain access to the underlying Ogre::SceneNode
pointer.
There's a potential problem with adding and removing OgreSceneNodeComponents
. When such a component is added to an entity, the accompanying Ogre::SceneNode
should be created before any other systems are run in the OgreEngine
, so that they all have access to a valid pointer. On the other hand, when an OgreSceneNodeComponent
is removed, the accompanying Ogre::SceneNode
should be removed after the other systems have been updated, because those other systems may access the pointer to do cleanup work.
A possible solution would be to create two systems, one for creating Ogre::SceneNodes
that is run early, and one that removes them and is run late.
To facilitate the management of agent types in the microbe stage, we need a central registry for storing information about agents. The information required (or useful) per agent is currently limited to
id
: A unique integer id, generated with generateAgentId
and possibly different per game instancename
: A unique string for identifying the agent across game instances. Should be in English and expressive, but short.displayName
: A string that can be displayed to the user, may be localized some time in the future.The list of properties might grow in the future, so the AgentRegistry should account for that. Users, i.e. script authors, must be able to easily register new agents as well as query information about already registered ones.
The simplest implementation can just be a table like this:
AgentRegistry = {
energy = {
agentId = generateAgentId(),
name = "energy",
displayName = "Energy",
}
oxygen = {
agentId = generateAgentId(),
name = "oxygen",
displayName = "Oxygen",
}
}
Plus a simple API function registerAgentType(name, displayName)
that generates an agentId and inserts the necessary information into the above table.
Add components and systems for simulating physics. The Bullet physics engine (http://bulletphysics.org/wordpress/) seems like a good choice.
For starters, a RigidBodyComponent
would be sufficient. In the script API, properties like mass, friction and the collision shape should be configurable. There should also be a way to apply a force or impulse (possibly through a function, not a property). In the physics thread, a RigidBodySystem
would apply the properties from a RigidBodyComponent
to Bullet's own data structures.
Another system should handle the propagation of the physics position back to the script thread and into the TransformComponent
.
Possible caveats: The propagation of the physics position from the physics thread over the script thread to the graphics thread could introduce annoying stuttering.
Perhaps a better name for the class.
It appears we will need random generating capabilities several places in the codebase, so gathering the functionality at one place would be advantageous. Keeping track of seeds can become very useful and using the right methods important.
I recommend an interface something like this:
RandomManager(seed)
constructor/init method
getRandomBetween(a, b)
getRandom(vector)``getSeed()
A singleton or static class pattern could be used, but several different instances could potentially be useful in the future (mostly happens for multiplayer games, however)
I strongly recommend watching http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful to get up to speed with the new C++11 random generating features, and using those!
Currently it seems impossible to allign text properly on the HUD even with formatting functions (see the ingame hud component for agents).
I'm fairly confident that the underlying problem here is that the "Thrive" font isn't monospaced. My verification of this is that i tried printing the same formatted text to the console and it looks fine there.
I see three solutions:
I forgot to do this when i first added process organelles.
What needs to be done is to add a "removeProcessOrganelle" to the microbe class and add a "onRemovedFromMicrobe" handler to the process organelle that calls the removeProcessOrganelle function.
Look to the corresponding functions for storage organelles for how to do this.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.