Your shopping cart is empty!
I decided to write a new blog to talk about the new V0-9-7 release and what this entails for future development. This blog is a couple of days out from the release but we have had to take a couple of days out for a famity member that went into hospital, but they are fine now :)
So We have already seen about the Visual modules and the SceneEntityCount(catch up here: <a href="https://blog.aurasoft-skyline.co.uk/visual-mechanics-engine-in-v0-9-7/" target="_blank">visual mechanics in v0.9.7</a>), but we have not talked about the new update system and the way we want to handle releases for the future. Up to this point we have been releasing large changelogs after multiple weeks with a new version of skyline which may at times feel like it takes a long time to get a release. It also makes people wunder whether the development of the engine has slowed down or not. What i can say is that we are always developing skyline and are probably pushing harder than ever when it comes to times like this where the release does not happen for multiple weeks.
Thinking on this though, we came up with a solution that makes more regular updates but few changes per update.
In the version we just released, we added a 4th version number that signifies the patch number of the main release. Incrementing this number means we can release more updates to you but keep in the same version number as some past updates were simple updates and did not warrant the version increase.
When a new patch is released, we will simply tag the changes onto the same version. So for example with our current V0-9-7, you now are on Release 1. When Release 2 happens we will add all the changes onto the V0-9-7 changelog webpage and separate changes by a header.
This is all for future-proofing the engine and will create many more updates for the future.
Enough about the update system, lets review some of the other features for this release:
The new 64 bit will allow you to hold all the assets for those large scenes your making. Before on the 32bit skyline, you were limited by Windows to only run 2gb-3gb of ram before the application would crash. This was easy to exceed when using the terrain and the static batched vegetation.
JSON: This feature is all about reading and writing human readable data from a json file format to lua tables. Once we have an encryption for this featureset, save files and other important in game information will be ideal for this systen. The files will not be editable or readable by your game users to stop any tampering or cheating on the game, or simply leave them open for hardware information or creating your own option settings. There is so much you can do with this.
One of our users requested the ability to bake multiple meshes that can be any asset at any scale, rotation or position into a singular asset that is easy to move around and place in the scene. One of the features we have not yet made for this is the batching as their is no performance benefit of using this feature.
Wow, that was a chunk to write lol :P But we are now going to explain the next set of development of skyline.
We are currrently working on a VR demo that might make it out for a press release event in the near future, but time is short and we are not sure how far we will get, but as always, we shall give it our all. For now, that is all the information we want to give about this.
With the 64bit nailed, we are trying to find a way of upgrading to DX11 or OpenGL 3+ to open the next set of shader features which for DX11 there are some very nice post processors that would seriously enhance skyline's visuals.
Our shaders are also going to be going through some changes as we try to upgrade and attempt for a full PBR shader material system that should finalise all the material demands through an easy set of properties. There are some extra shader parts we wish to build and these will be modular addons to the shader code to produce more unique effects but share the same base PBR system.
We have a plan on improving the terrain toolset and vegetation system that will meet the requirements of a modern looking game as well introducing lods, tree physics and new wind effects. New workflows will also aid you in your development and for terrains, having more textures is a necessity now.
This is not a shot from inside skyline, but it is intended to give the impression of what we are aiming for with vegetation quality. Taken from: http://www.dsogaming.com/screenshot-news/dices-vegetation-artist-experiments-with-unreal-engine-4
For performance, we will be adding occlusion culling to make your scenes and levels more efficient and coupled with the infinite scene entity count now will make some very populated scenes. There will be a need for an unloading and loading of assets as you move through your game world, but these zones can be quite large i believe if you have a good occlusion culling system. Unloading assets will also be added into the asset manager when taking pictures, upgrading presets etc...
This image is taken from this webpage as an example of what occlusion culling does; https://software.intel.com/en-us/node/542215
As you all develop with the visual module system, we would like to know what you all need in order to pull off your levels or games.
These future tasks that i am talking of are "not" for the next release but they are in our heads and are something we are working towards.
In the meantime, my new job is too fully integrate the OSVR headsets into the Skyline Game Engine ready for this next phase.
I think i have waffled on long enough now and shall leave you all to play with skyline developing your levels and games. As always, if you need anything at all; you will find us on the forums :D