Jump to content
  • Advertisement

How far are we from component detailed games?

Recommended Posts

Imagine a game where the characters are not defined by body regions, but rather, each body region consists of thousands of components, which would kind of replicate the real world where we consist of molecules, atoms - that would open up many, many new possibilities for creative gameplay. Can this be done on any scale with today's technology, or would the games simply require too powerful of a computer to even be playable? Are there any theoretical limits to this? Thanks

Share this post

Link to post
Share on other sites

The nearest thing to what you're talking about is 'voxels', where larger things are built up out of (typically) cubic blocks. Occasionally some of these blocks might have some sort of mechanical capability so that it's possible to construct more complex machinery from them . For example, there's the Minecraft 'computer':

Minecraft is the most well-known game of this type but there are other voxel engines that work at lower granularity and are able to represent more complex objects effectively. VoxelFarm is one example: https://www.voxelfarm.com/index.html

As for more complex mechanics - that is a bit harder to do, but basic physics systems already exist and can be used to some degree in games like this. The Last Leviathan is one game where you build a boat and how it acts in the world depends on what exactly you built. An earlier game is Besiege (warning: shouty streamer) which lets you construct a variety of machines.


However, the general idea of being able to work on the molecular level is not applicable to games right now and probably will never be. There are something like 3 * 10^25 trillions of molecules in just 1 litre of water and only something like 16 * 10^12 bytes of storage in a typical desktop computer so we would need to be able to represent a trillion molecules in each byte of data - this would create serious boundaries to how accurately these molecules could be modelled.


Share this post

Link to post
Share on other sites

I'd look away from games and more at medical academia for an answer to this. Google things like bio-dynamics or kinematics. I don't know about these things but would speculate they would identify systems like rigid and soft parts and joints and how they interact then represent them with smaller components, not start with particles and work backwards.

I have my own voxel engine for terrain generation and work with 512 x 512 x 512 'chunks' that represent 500 billion total voxels for an 'area/instance' in the generation phase. The game ready mesh is non voxelated so it doesnt meet your end goal. If my chunks were bigger the render time would slow performance too much for practical use. Also terrain doesnt need to be represented with that level of detail, there needs to be a reason to expend resources on something. For perspective 5 years ago I worked with chunks of 256 x 256 x 256 for similar constraints of performance.

Share this post

Link to post
Share on other sites
21 hours ago, Marinka Brussel said:

Can this be done on any scale with today's technology, or would the games simply require too powerful of a computer to even be playable? Are there any theoretical limits to this?

Depends on what you are making and what level you're trying to simulate.

It also depends on what you are trying to make.

I mean, if you want to build a protein-folding simulator you can build at that level, but even those aren't interactive pace. There are supercomputers that slowly churn through those data.

As for theoretical limits, look at your processors.  In this current era you get about 4x 4GHz, more or less. If you want to keep a solid 60 frames you get about 200 million cycles per frame if you're careful about it, or 50 million cycles per frame if you're stuck in a single thread. Then look at time you'll realistically need to spend waiting for data to load, for cache misses, and that sort of thing.  In theory you can process a few hundred million data elements every graphics frame. Few programs ever hit those limits, but it can be done. 

I'd recommend those computed elements be the fun parts of the game, rather than the minutia of individual cells, but that's up to you.

Share this post

Link to post
Share on other sites
21 hours ago, Marinka Brussel said:

Can this be done on any scale with today's technology, or would the games simply require too powerful of a computer to even be playable?

If you scale it yes. Instead of thousands you only use hundreds, then you will be fine.

Game engines today can emulate 1 000 000 - 8 000 000 objects on screen at once if they are kept very-very simple. Unreal can for example emulate 4 000 000 bouncing balls with full physics and materials if they are instances of each other.

This should mean +/- 500 000 body parts to use. If it is all you focus your resources on.


To emulate a universe you need to use a universe.

Voxel systems and the like uses octrees and fake emulating particles, the problem is that the smallest piece of data we can use is a byte a 0 or a 1.

A byte is either a small piece of metal or a capacitor or some kind of physical object. Each of these small objects we use for bytes are actually made of trillions of atoms. To be clear, we are using a 1,000,000,000,000 : 1 scale when we try to represent atoms in games.

So instead we use much larger objects to fake simulations of smaller objects: 

The video shows how millions of balls are used to create a water like effect. This takes the same power as most games to do.

You can use bigger "atoms" so needing less per emulation and still get convincing results and games use this all the time. It's all about scale.

Share this post

Link to post
Share on other sites

An important question to ask yourself when you're considering doing something in a radically new way for a game (Or for anything in life really) is: What advantage am I gaining from this?

Back in university I had worked for a time on a compressible volume based character design and animation system. The technology was eventually abandoned due to not being able to mature it fast enough to be really usable for anything, but the concept was to essentially estimate all the bones and major muscles in a human body with a light approximate physics and volume system, and then apply a ray-tracing layer over top of it. If a character was to pick something up with its hand, then the arm muscles would contract and change shape while a force was applied to the hand. This in turn would automatically give a 'natural' shape and motion to the animation, without requiring complex animation work. 

Since that time traditional animation tools and the access to them had matured more, and that raised the bar of usefulness of my project beyond what I was willing to invest in it. My project was slow, computationally expensive on run-time, and needed far more investment into the 'shell layer' for it to be useful. In theory the project would have had the advantage of far more natural and less blocky looking animation for characters with a reduced animation design cost, but those issues were solved in a far more sensible and cost effective manner by other parts of the industry. 

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
  • Advertisement
  • Popular Tags

  • Popular Now

  • Advertisement
  • Similar Content

    • By LuigiLuigi
      I've been working on my own Metroidvania via GameMaker Studio for the past few years. You play as a bat named Ralph as he goes on an adventure to obtain 7 Crystal Medallions hidden in dungeons with the help of a cult known as the Crimson Fog. Along the way, there will be quests unlocked in Cedrus Village as you progress through the game. I've managed to complete a demo of the game up to the first dungeon and boss fight.
      I have only a PC build available, and the only gamepads I managed to install were Logitech Precision and Xbox PC gamepads. I had some trouble on gamepad detection though, so they may have connection issues. The desktop controls are similar to Terarria's control scheme if it's too much trouble. I don't have any music at this point, I'll need to get someone else to compose it later on. The music I make isn't bad, but it doesn't fit the aesthetic that well.
      I'm really hoping I can get feedback regarding the general content.
      Crimson Fog.0.2.zip
    • By Alexander Winter
      Jumpaï is a game about creating platformer levels and playing them online with everyone. Will you become the most popular level maker or will you be a speedrunner holding world records on everyone's levels? More into casual play? No problem! You can happily play through the giant level database or chill at people's hub. Meet new people, make new friends, learn to master the game by asking pros or ask for people's favorite tricks on level making. Download here: https://jumpai.itch.io/jumpai Discord: https://discord.gg/dwRTNCG   Trailer:      (The following screenshots are older but still a bit representative)  

      Unlike other games of its genre, Jumpaï is about playing levels with everyone in real time. You have the fun to see how other people are playing and get to realize you are not the only one failing that jump!

      The game is currently into development and still have lots to do. I am looking for people willing to help how they can. Developer? Graphist? Play tester? Sound designer? Game designer? I'm welcoming any talent. The project is so big I have a lot of work to do in all areas. Server backend, UI/UX, Game networking, Gameplay and even the website some day. As you can see from the default buttons, the game has been made with LibGDX. This project is a perfect opportunity for you to get better in various fields as well as showing off your skills.

      If you plan to take an important role into the development of the game, we will discuss how you will get paid once the game generates money. Note that I'm not working on the game full-time. I'm studying full-time and working on it is a hobby. The project has started in november 2016 and experiences heavy progress.

      So, are you interested? If so join me on my discord https://discord.gg/dwRTNCG and I'll answer all your questions.

      Additionnal screenshots:

    • By Shtabbbe
      I've had a game idea for a while, and I wanted to finally try to create it.
      Its a 2D open-world tile-based MMO. The concept is it is one world and multiplayer only, so everyone shares one world no matter region, platform, etc.
      I am having problems finding out what to use to start development, I tried Unity but saw some of the negatives and refrained and now im stuck, could anyone recommend some intermediate friendly 2D engines that can support what I am looking for? Preferably in languages that are or are somewhat like Java, C#, Python, JavaScript, Lua.
      Thanks for your help, im very new at this if you cant tell
    • By chiffre
      In general my questions pertain to the differences between floating- and fixed-point data. Additionally I would like to understand when it can be advantageous to prefer fixed-point representation over floating-point representation in the context of vertex data and how the hardware deals with the different data-types. I believe I should be able to reduce the amount of data (bytes) necessary per vertex by choosing the most opportune representations for my vertex attributes. Thanks ahead of time if you, the reader, are considering the effort of reading this and helping me.
      I found an old topic that shows this is possible in principal, but I am not sure I understand what the pitfalls are when using fixed-point representation and whether there are any hardware-based performance advantages/disadvantages.
      (TLDR at bottom)
      The Actual Post:
      To my understanding HLSL/D3D11 offers not just the traditional floating point model in half-,single-, and double-precision, but also the fixed-point model in form of signed/unsigned normalized integers in 8-,10-,16-,24-, and 32-bit variants. Both models offer a finite sequence of "grid-points". The obvious difference between the two models is that the fixed-point model offers a constant spacing between values in the normalized range of [0,1] or [-1,1], while the floating point model allows for smaller "deltas" as you get closer to 0, and larger "deltas" the further you are away from 0.
      To add some context, let me define a struct as an example:
      struct VertexData { float[3] position; //3x32-bits float[2] texCoord; //2x32-bits float[3] normals; //3x32-bits } //Total of 32 bytes Every vertex gets a position, a coordinate on my texture, and a normal to do some light calculations. In this case we have 8x32=256bits per vertex. Since the texture coordinates lie in the interval [0,1] and the normal vector components are in the interval [-1,1] it would seem useful to use normalized representation as suggested in the topic linked at the top of the post. The texture coordinates might as well be represented in a fixed-point model, because it seems most useful to be able to sample the texture in a uniform manner, as the pixels don't get any "denser" as we get closer to 0. In other words the "delta" does not need to become any smaller as the texture coordinates approach (0,0). A similar argument can be made for the normal-vector, as a normal vector should be normalized anyway, and we want as many points as possible on the sphere around (0,0,0) with a radius of 1, and we don't care about precision around the origin. Even if we have large textures such as 4k by 4k (or the maximum allowed by D3D11, 16k by 16k) we only need as many grid-points on one axis, as there are pixels on one axis. An unsigned normalized 14 bit integer would be ideal, but because it is both unsupported and impractical, we will stick to an unsigned normalized 16 bit integer. The same type should take care of the normal vector coordinates, and might even be a bit overkill.
      struct VertexData { float[3] position; //3x32-bits uint16_t[2] texCoord; //2x16bits uint16_t[3] normals; //3x16bits } //Total of 22 bytes Seems like a good start, and we might even be able to take it further, but before we pursue that path, here is my first question: can the GPU even work with the data in this format, or is all I have accomplished minimizing CPU-side RAM usage? Does the GPU have to convert the texture coordinates back to a floating-point model when I hand them over to the sampler in my pixel shader? I have looked up the data types for HLSL and I am not sure I even comprehend how to declare the vertex input type in HLSL. Would the following work?
      struct VertexInputType { float3 pos; //this one is obvious unorm half2 tex; //half corresponds to a 16-bit float, so I assume this is wrong, but this the only 16-bit type I found on the linked MSDN site snorm half3 normal; //same as above } I assume this is possible somehow, as I have found input element formats such as: DXGI_FORMAT_R16G16B16A16_SNORM and DXGI_FORMAT_R16G16B16A16_UNORM (also available with a different number of components, as well as different component lengths). I might have to avoid 3-component vectors because there is no 3-component 16-bit input element format, but that is the least of my worries. The next question would be: what happens with my normals if I try to do lighting calculations with them in such a normalized-fixed-point format? Is there no issue as long as I take care not to mix floating- and fixed-point data? Or would that work as well? In general this gives rise to the question: how does the GPU handle fixed-point arithmetic? Is it the same as integer-arithmetic, and/or is it faster/slower than floating-point arithmetic?
      Assuming that we still have a valid and useful VertexData format, how far could I take this while remaining on the sensible side of what could be called optimization? Theoretically I could use the an input element format such as DXGI_FORMAT_R10G10B10A2_UNORM to pack my normal coordinates into a 10-bit fixed-point format, and my verticies (in object space) might even be representable in a 16-bit unsigned normalized fixed-point format. That way I could end up with something like the following struct:
      struct VertexData { uint16_t[3] pos; //3x16bits uint16_t[2] texCoord; //2x16bits uint32_t packedNormals; //10+10+10+2bits } //Total of 14 bytes Could I use a vertex structure like this without too much performance-loss on the GPU-side? If the GPU has to execute some sort of unpacking algorithm in the background I might as well let it be. In the end I have a functioning deferred renderer, but I would like to reduce the memory footprint of the huge amount of vertecies involved in rendering my landscape. 
      TLDR: I have a lot of vertices that I need to render and I want to reduce the RAM-usage without introducing crazy compression/decompression algorithms to the CPU or GPU. I am hoping to find a solution by involving fixed-point data-types, but I am not exactly sure how how that would work.
    • By Paszq
      Group photo of some of the characters and creatures currently living in Arpago
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!