next »

[io3 creations]

Yes, your answers answered my questions.

Actually, I've been also thinking about making a voxel based game but so far am only at considering various technical issues.

I haven't played Critical Annihilation yet and only saw a few scenes related to the floating island issue.  The most obvious choice would be to destroy the object that is "above" the destroyed area.  In one scene, I saw partial destruction of a Jeep where part of the windshield and frame remained intact and looked fine.  In another scene, I saw a rocket hit a pine tree.  Instead of keeping the remaining top of the pine tree as one piece, it was blown apart as voxel unit cubes.  That could work for explosions with great impact but what if the trunk is destroyed slowly by bullets? Then destroying the full tree may not seem right.  Or if a hole is created in the middle of a wall and then the hole is extended to one side, the resulting rotated "L" shape shouldn't be able to hold all the weight.  But, depending on how the game world is set up, it may work fine if the parts that are no longer supported by pieces below them are destroyed.  That would take a few extra checks and considerations but could work.  For example, there another scene (about 30sec in the official game trailer) where the wall of a container is destroyed.  There the part above the destroyed ares is also destroyed.  However, while two walls should still be able to hold the top of the container, if three are destroyed then the top would have to fall to the ground.  Similarly, for certain objects, e.g. column, I was thinking that it may be possible to check if the floating island part is no longer attached to the ground and create a separate mesh collider for it.  That might look more "realistic" but may introduce more issues. 

In terms of optimizations, I saw the line based mesh images a few pages back, and wonder how do you generate and update the collision meshes.  Mainly for the background: do you start with one single mesh and change it as needed?  I was thinking of trying a few optimizations: e.g. start with smaller meshes and update those as needed.  I wonder if you "manually" turn off certain collision meshes that aren't needed (e.g. no character or ammo is around) would have a noticeable effect on performance.

I like to posters near the top of this page.  The only thing is that the "Insert Coin!" text pretty much blends into the similarly light colored background.  Either a dark(er) outline or background could easily fix it though.

[djr]

Yes, your answers answered my questions.

Actually, I've been also thinking about making a voxel based game but so far am only at considering various technical issues.

I haven't played Critical Annihilation yet and only saw a few scenes related to the floating island issue.  The most obvious choice would be to destroy the object that is "above" the destroyed area.  In one scene, I saw partial destruction of a Jeep where part of the windshield and frame remained intact and looked fine.  In another scene, I saw a rocket hit a pine tree.  Instead of keeping the remaining top of the pine tree as one piece, it was blown apart as voxel unit cubes.  That could work for explosions with great impact but what if the trunk is destroyed slowly by bullets? Then destroying the full tree may not seem right.  Or if a hole is created in the middle of a wall and then the hole is extended to one side, the resulting rotated "L" shape shouldn't be able to hold all the weight.  But, depending on how the game world is set up, it may work fine if the parts that are no longer supported by pieces below them are destroyed.  That would take a few extra checks and considerations but could work.  For example, there another scene (about 30sec in the official game trailer) where the wall of a container is destroyed.  There the part above the destroyed ares is also destroyed.  However, while two walls should still be able to hold the top of the container, if three are destroyed then the top would have to fall to the ground.  Similarly, for certain objects, e.g. column,

If you don't already, I encourage you to read some of the posts on Reddit VoxelGameDev. There are a lot of cool posts and I think the Critical Annihilation guy posted there about how he did the sharding using Voronoi diagrams I can't find the post but I'm pretty sure it's in there.

In terms of optimizations, I saw the line based mesh images a few pages back, and wonder how do you generate and update the collision meshes.  Mainly for the background: do you start with one single mesh and change it as needed?  I was thinking of trying a few optimizations: e.g. start with smaller meshes and update those as needed.  I wonder if you "manually" turn off certain collision meshes that aren't needed (e.g. no character or ammo is around) would have a noticeable effect on performance.

We use Bullet physics in our engine and adding/removing meshes at run time is expensive. It does a good job of sleeping static objects so we change the meshes as in frequently as possible. When a voxel chunk is changed we generate the visible mesh and a different collision mesh. The collision mesh is easier to optimize (as there is no colors so co-located vertices can be merged). This is expensive though and currently causes large unpredictable spikes in CPU usage. We plan to smooth over this at a later date by generating meshes in separate threads.

If there is one thing we've learned about making a voxel game it's that there is always optimization work to do 

[io3 creations]

Thanks for the links.  I haven't gotten too far with voxels but those'll be definitely useful when I start looking into it more.

Yeah, I know that adding/removing meshes is expensive.  I've done some slicing and noticed the slow down as I kept slicing every object at mid section when a lot of objects were sliced and new meshes were generated.  I've read that when a mesh is created, Unity also optimizes it for performance, hence more overhead than just simply creating a mesh.  So, I wasn't really thinking about adding/removing but enabling/disabling collision meshes.  Much like a chess board, if nothing is moving on a certain part or region, then that part could be disabled.  In Flash box2d, there were options to enable/disable collision check for certain objects and I haven't gotten that far but wondered if there's something similar in Unity's box2d.

[djr]

Thanks for the links.  I haven't gotten too far with voxels but those'll be definitely useful when I start looking into it more.

Yeah, I know that adding/removing meshes is expensive.  I've done some slicing and noticed the slow down as I kept slicing every object at mid section when a lot of objects were sliced and new meshes were generated.  I've read that when a mesh is created, Unity also optimizes it for performance, hence more overhead than just simply creating a mesh.  So, I wasn't really thinking about adding/removing but enabling/disabling collision meshes.  Much like a chess board, if nothing is moving on a certain part or region, then that part could be disabled.  In Flash box2d, there were options to enable/disable collision check for certain objects and I haven't gotten that far but wondered if there's something similar in Unity's box2d.

Alas, other than the prototype for Smith and Winston, I don't have a lot of experience with Unity. However, my gut instinct would be that enabling/disabling meshes could cause the internal spacial tree (for example a quad tree) to be updated/relalanced and this could be more expensive than just leaving the meshes there active. It would be an easy thing to test though. Certainly Bullet Physics (which I suspect Unity use internally) does a good job of excluding meshes from calculations very efficiently so there is little to be gained most of the time.

[djr]

One of the complaints we got from our early testers was the the AI was a bit dumb. Fair enough it is a bit dumb so we added navigation grids, A-star, some steering code and now the little robot crab/spider things chase you around:



You can see the full video here on youtube:



Pretty good for a weeks work I think. I've got to apply the same logic to all the other enemy types as well now but it's been very rewarding.

[io3 creations]

Alas, other than the prototype for Smith and Winston, I don't have a lot of experience with Unity. However, my gut instinct would be that enabling/disabling meshes could cause the internal spacial tree (for example a quad tree) to be updated/relalanced and this could be more expensive than just leaving the meshes there active. It would be an easy thing to test though. Certainly Bullet Physics (which I suspect Unity use internally) does a good job of excluding meshes from calculations very efficiently so there is little to be gained most of the time.

Not sure if the Bullet Physics is the same thing that you are referring to but in the box2d that I used, you could set an isBullet property for objects but that added more calculations than not having it.  Anyways, ultimately, I agree that testing can tell whether a certain approach is worth it or not.

One of the complaints we got from our early testers was the the AI was a bit dumb. Fair enough it is a bit dumb so we added navigation grids, A-star, some steering code and now the little robot crab/spider things chase you around:

In case you  adding some lateral movement/jump/hop and/or vertical jumping could also add some additional challenge.   

I'm assuming that bullet that took out all enemies was a powerful one and there would be situations where tension would be maintained by at least some of the enemies getting closer.  Of course, skilled players could become a "shepherd" and go for the instant multi-chain-kill.

[Seaport]

I'm assuming that bullet that took out all enemies was a powerful one and there would be situations where tension would be maintained by at least some of the enemies getting closer.  Of course, skilled players could become a "shepherd" and go for the instant multi-chain-kill. Wink

It was a basic shot rather than a powered up one but as those crabs explode when hit they set off a chain reaction, I'm not sure whether to change their explosion properties to stop them doing this? On one hand it does make them quite easy to get rid of but they are the first enemy the player meets so they should be pretty easy to deal with.
 One other idea I was thinking about was to use the navigation grid to set up paths so they don't clump up so much, maybe i can even get them to do a little flanking round the player

Also added in a new texture for the skybox this week



Its quite hard to disguise the fact we use a cube as our skybox (especially the corners) but on the other hand with a fixed camera I don't have to worry about a couple of the views, such as above and behind the camera. Still needs a little more work but I think it does help to disguise the skybox's geometry




 

[io3 creations]

It was a basic shot rather than a powered up one but as those crabs explode when hit they set off a chain reaction, I'm not sure whether to change their explosion properties to stop them doing this? On one hand it does make them quite easy to get rid of but they are the first enemy the player meets so they should be pretty easy to deal with.
 One other idea I was thinking about was to use the navigation grid to set up paths so they don't clump up so much, maybe i can even get them to do a little flanking round the player

I agree that early enemies should be easy to deal with and depending on the overall game style and difficulty increase it might work.  It might be also different if I actually play the game but based on experience my first impression is that I would feel very powerful and the game would seem easy.  As you mentioned, spreading the enemies out more (and adding  other AI movement and even attack strategies) will also require players to use strategies to defeat them and will increase the "fun" aspect of the game.

[io3 creations]

Its quite hard to disguise the fact we use a cube as our skybox (especially the corners) but on the other hand with a fixed camera I don't have to worry about a couple of the views, such as above and behind the camera. Still needs a little more work but I think it does help to disguise the skybox's geometry

If your camera is fixed and looking down at the level, have you considered using a single plane (where the bottom of the skybox is) instead of the skybox?

[djr]

If your camera is fixed and looking down at the level, have you considered using a single plane (where the bottom of the skybox is) instead of the skybox?

Well we can attach any shape to the camera tbh, for cut scenes, you'll be able to see the other sides of the cube so we will have to do all sides except the top (maybe).

[io3 creations]

Well we can attach any shape to the camera tbh, for cut scenes, you'll be able to see the other sides of the cube so we will have to do all sides except the top (maybe).

Oh, I see.  Yeah, if the skybox doesn't look good, then you can always use a skydome (i.e. something closer to a sphere).  Though, since you are using voxels, a "box-shaped sky" might fit the overall game theme rather well.

[Seaport]

Well we can attach any shape to the camera tbh, for cut scenes, you'll be able to see the other sides of the cube so we will have to do all sides except the top (maybe).

Now he tells me 

[io3 creations]

Well we can attach any shape to the camera tbh, for cut scenes, you'll be able to see the other sides of the cube so we will have to do all sides except the top (maybe).

Now he tells me 

It's better later than never! 

[Frogs_Milk]

Love the feel of this. Dig the destructibility element to the game play.

[zircon]

I'll echo that sentiment... seems like the player feedback here is going to be really good (as in, feedback within the game world). Love the graphical style too.

From a musical perspective, any thoughts on using more of a 16-bit style? I liked some of the FM/Genesis type tunes you had in one of the earlier videos. I think pure NES/GB era chip music is maybe not as interesting as FM (not used as often) OR a blend... but that's just me!

[Seaport]

It's better later than never!  Grin

Lol, now that is true

Love the feel of this. Dig the destructibility element to the game play.

Thanks for the comment, the full destructibility was always something we wanted in a game, I think it offers up so many possibilities (and a few headaches)
I loved the destruction in such games as Battlefield:Bad Company 2, shame that series as dialed the destruction back in the later versions

From a musical perspective, any thoughts on using more of a 16-bit style? I liked some of the FM/Genesis type tunes you had in one of the earlier videos. I think pure NES/GB era chip music is maybe not as interesting as FM (not used as often) OR a blend... but that's just me!

I'm not an expert on these things I leave that to djr (I'm pretty sure hes a fan of both 8 and 16 bit chip tunes), but yeah perhaps 16-bit style music might be the way to go, its very evocative of those old arcade games and sounds great too, though I guess a lot come down trying different music styles out and seeing what fits best

 

[Seaport]

mock up of Smith and Winston as an arcade machine, just got to wait for Dazza to finish his cabinet off

[Seaport]

We've decided to double down on one of our strength and that's terrain deformation/destruction and to that end we're changing the players default starting weapon to something a bit more capable



Pew, pew, goodbye hill

[Seaport]

Working on new assets for new levels, the image below shows what will be our space level assets, beam me up

[Xonatron]

Coming along great. An attractive game.