Jump to content

  • Log In with Google      Sign In   
  • Create Account

CC Ricers

Member Since 04 Jul 2004
Offline Last Active Feb 27 2016 04:44 PM

#5221919 Lighting and what else for a good-looking voxel game?

Posted by on 07 April 2015 - 01:44 PM

I use some fake directional-based ambient lighting. This is what it looks like in my voxel engine. The idea came from this article on image-based ambient lighting but I kept it more simple and instead am just using the six sides of a cube to gather lighting.


It's a simplified version of what Swiftcoder posted. The sides facing the skydome have different tints of color which change during the day/night cycle, as well as the intensity of the light bounce (how much they contribute to the final color). The sides facing the bottom are less saturated versions of the top colors. I only did this because the voxel lighting will block most of the light from the bottom sides anyways.

#5216324 What are your opinions on DX12/Vulkan/Mantle?

Posted by on 13 March 2015 - 02:16 PM

I think I'm share the same sentiments as Seabolt, and need to bite the bullet and move on to newer APIs.

I don't really have anything useful to add to this thread but as of last week:




That started changing as I started converting some projects to MonoGame Win 8/SharpDX with Shader model 4.0.

#5215927 Getting out of the industry?

Posted by on 11 March 2015 - 04:06 PM

Aside from the well known big Silicon Valley companies, you can try to get hired at SpaceX. They appeared at previous GDC's and are really seeking game developers to work for their flight software, especially if they are good at low-level programming. They take their work seriously, but also pride themselves in standing out from the older, more bureaucratic aerospace companies which they argue are a lot slower in testing and validating software.

#5213399 Ray vs Sphere Issue

Posted by on 27 February 2015 - 04:04 PM

Sphere culling at least improves performance (even if sphere collision is already simple enough to test). What I am not clear about in your original post is that when you say the ray collides with spheres behind the player, does this mean it is ONLY colliding with those spheres, or is it also colliding with the spheres in front, and sometimes in the back, depending on the ray direction where the spheres are located? Are you sure the ray is always firing forward from the player?


I also think you can try this alternative method of culling, which I just remembered. For every sphere, make a ray connecting the sphere to the player. But Aressera just beat me to it, and has code to show for it. But the short of it is, get the dot product with the sphere ray and the firing ray. Acceptable spheres would have a positive dot product.

#5213386 Ray vs Sphere Issue

Posted by on 27 February 2015 - 03:31 PM

Maybe try to cull the spheres behind the character? Since the gun is firing in the facing direction of the player, you can take the ray as a normal for a plane crossing the player, and then don't check collision in spheres that are on one of the sides of the plane.

#5213213 Order of matrix multiplication

Posted by on 26 February 2015 - 04:45 PM

I always remember the acronym "ISROT":


* Identity - Default identity matrix

* Scale - changing of size of object

* Rotation - rotation of that object

* Orbit - rotation around some other object or point

* Translation - Movement to a new world position


That's interesting. I never considered Orbit to be a separate matrix from Rotation.

Typically I just remember "SRT" (starting with the Identity should be implied), and if I wanted the object to orbit around a fixed point, I switch the order of R and T so I rotate around the translated point.

#5213207 Component-based architecture - entity and component storage

Posted by on 26 February 2015 - 04:25 PM

Just reading your first post and from the diagram you provided in it, to be quite honest that structure wouldn't be too bad for using alongside ECS. Notice that I said alongside, and not as a direct part of ECS, because physics and rendering can be very involved and require complex logic that shouldn't exist in the context of entities and components anyhow. 


Other logic, like level loading can create entities for you, but doesn't necessarily be a system or part of one, especially if its purpose is only to load a level. It is not going to run on every frame, and that is how I have my level code setup. When I start the game, a LevelLoader class is created on initialization, after the ECS framework is initialized. It takes a EntityBuilder instance for a parameter. The LevelLoader instance resides in the scope of the game but outside the ECS.


The LevelLoader's logic is, using EntityBuilder, simply to add all the Entities necessary that make up a level at the start of a game. Add tiles, add players and enemies as well, and that's it.


After this point, EntityManager has all the Entities needed for the System processes to use in the game loop.

#5211775 Top-down collision

Posted by on 19 February 2015 - 05:24 PM

Aardvajk is right, finding the minimum separation distance is an important step, because usually the colliding box will be overlapping several boxes at a given frame in time, not just one. By moving the character away from an intersecting position as quickly as possible you won't get intersections when testing in further rectangles, thus avoiding bugs where the character's bounding box snaps to the corner of another box.

#5211579 Do everything through ECS? Or implement other systems?

Posted by on 18 February 2015 - 05:50 PM



Sometimes people tend to ask if they "RenderSystem" that manages and render a "RenderComponent" (what is a "RenderComponent"? Anything that can be rendered?) is well implemented, and when you check you see that he's mixing vertex buffers with a character that even know what type of shirt he is using (poor game entity that knows everything, he must be on god mode in this type of game); then you see that mixing high-level systems without having the low-level ones already done mess up everything, and in order to use a vertex buffer, the user includes the whole game module on its project by the fact that a "RenderSystem" is supposed to be a component system that is from the game-module/engine-module/highest-level module in the engine.


I think that systems dealing with graphics and physics should be more of a wrapper and the actual rendering and physics code is implemented in a black box manner. This means that these systems are just responsible for stripping the raw data from the components and passing it directly to the rendering and physics engines. The engines do the dirty lower-level work, and are objects inside of a system, but aren't aware that they are in a system.




 Unity3D also made things entirely impracticable by requiring simple scripts to be in the physical world. Try to make sense of that...


Admittedly, this is a side effect of Unity requiring a Transform component for everything, even scripts. So even things that shouldn't need a physical location get one anyways. It's the only thing that sticks out to me as a big overthought in their ECS.

#5211057 What are the recommended places to store save data?

Posted by on 16 February 2015 - 03:54 PM

When it comes to saving data, whether game progress or maps, or anything that is user-created, what are the recommended places in the file system to save the files to? I see it all over the place for different games. For Windows, some games use the /Users/AppData/Local folder, some use the My Documents folder and others use the same folder that the program resides in (with a separate folder within). And I'm not sure where to begin looking for Linux and Mac.

#5210106 Making assets unattainable

Posted by on 11 February 2015 - 03:02 PM


Could I put them in a password protected folder and still have my game access them?

I'm glad you are already headed in a different direction, but it's worth answering this question directly.


If you password protect the assets, then your program will need the password in order to access them. And the program is sitting on the user's machine... It's pretty trivial for another programmer to open up the program and retrieve the password.



This is really important to know. Anyone who can use a memory dump tool can just find the password with little effort.

For this reason you should also not try to do anything that requires a secure online connection have the credentials right on the player's machine. Then you have a legitimate reason for not letting the player access things he shouldn't normally have. Real life example 

#5208748 Cascaded Shadow Maps Look Bad

Posted by on 04 February 2015 - 05:27 PM

DementedCarrot's suggestions are one of the easiest to follow, if you are already familiar with PCF or any other form of shadow map filtering. I personally have used a combination of this with a fixed set of samples from a Poisson Disc to add more fuzziness to the edges. These samples are just an array of constants pre-loaded into the shader.


Here is a scene I rendered with my shadow mapping approach. It is technically PSSM and not CSM, but the filtering integration shouldn't matter, as you are applying it after the map images are made. I am using 3-4 splits in the shadow mapping here.

#5208725 Game Structure Advice

Posted by on 04 February 2015 - 03:55 PM

Your "Scene" class and its children start to look like different game states, especially with the usage of its methods. If you choose to use the State pattern, it is probably good to start from there. You should implement some kind of way to manage Scene objects. Instead of deriving from "Object", Scene should simply be an abstract class, and all the other Scene derivatives implement their own functionality within. Call these methods using Scene->YourDrawMethod for instance in the main game loop, instead of using a switch-case. A Scene then isn't limited to drawing a level, but also drawing menu screens and taking input specific to that

#5208718 Blocky art style?

Posted by on 04 February 2015 - 03:35 PM

As was stated before... You do have more options than you really think.


The "Blocky" art style needs just as much effort put into as any other art style. You can't just throw something together, and call it a finished product. That'd be insulting.


Take a look at Cubeworld (Whos developer I now despise for opening his game up in an early access stage, claimed as a full release.) It's utterly beautiful. But there is a lot more work being put into it than any other style that you may have seen. Not to mention trying to get things to work properly.

The next biggest problem, is trying to keep the style consistent. Difficult to do in just about anything.

I can attest to this, as Cube World is one of my big inspirations for my next game :D Rendering a large world made up of blocks with playable frame rates is not basic to do in technical terms. The blocky art style is just like a wolf in sheep's clothing, hiding the complexity of the game underneath.


By the way the developer's biggest shortcoming is he is not very good at consistently communicating with people interested in the game. He didn't claim that his released game was a full release, and it still says it's an alpha on the title screen. But seeing as he recently (a month ago) replied to one of his followers that development is still in progress, I would have to do a good job to differentiate my game from Cube World, like Vox did.

#5207563 How to pass content through the project's structure efficiently?

Posted by on 29 January 2015 - 05:40 PM

Keep in mind that textures loaded by the same ContentManager object stay cached, so all your game Units that use the same texture will point to the same data in memory, as phil_t has mentioned. Your custom Module class just keeps references to the data loaded by ContentManager.


I agree with ashaman except I wouldn't load on demand, rather preload all textures on construction into the map. This way there is no delay when first displaying that texture. On xbox 360 for example disk access can be dog slow, which can mean a stuttery game for the first few seconds if you load on demand.


Yes, and this was true also because calling the GC to re-allocate megabytes of data was more expensive, and creates more latency. It is ideal to do this in transitional parts of your game such as a loading screen.


On most PC's it's not as big of a deal but it's still a good practice to pool your resources. Sometimes creating new data on demand can't be avoided, as with procedurally generated content. But you can still pre-allocate some data and keep re-writing to it as new content is generated.