Tuesday, January 13, 2015

Medieval Engineers

Introduction


Today is one of the best days of my life. I believe that my colleagues feel it the same way.

The days when we release a major feature or announce a new game are the leading motivations of why we keep developing games. On days such as today, when we present something new and await feedback from our fans and community – that’s when we feel our bond with you increases :)

2014 was an exciting and challenging year, and that’s a combination we seek at Keen Software House. We were able to develop Space Engineers to a much more mature  level, while also prototyping Medieval Engineers to be ready for today’s announcement. 2015 will be even more challenging (...developing two games in parallel...). That is how we like it :)

In this blog post I will talk about Medieval Engineers, why we decided to develop it and a little insight into its development history.

About Medieval Engineers


Medieval Engineers is our second game about engineering and construction. The first one was Space Engineers and it is still doing very well.

Medieval Engineers is inspired by real medieval technology and the way people built architectural works and mechanical equipment using medieval technology. Medieval Engineers strives to follow the laws of physics and real history and doesn't use technologies that were not available in the 5th to 15th century. Players build cities, castles and fortifications; construct mechanical devices and engines; perform landscaping and underground mining.

Medieval Engineers brings three major upgrades to our VRAGE engine: structural integrity, natural landscape and Physically Based Rendering.

Web: www.MedievalEngineers.com

Why Medieval Engineers when Space Engineers is still not finished?


We were expecting that many people would ask “why are they developing a new game when Space Engineers is still in development and not finished”?

First let me assure you that the development of Medieval Engineers hasn't had a negative impact on the development rate of Space Engineers - you can see this from the frequency of our weekly updates – culminating in major updates at the end of 2014: super-large worlds, procedural asteroids, exploration, in-game programming, modding SDK and API.

We didn't want to keep creating space games only. Instead we wanted to have a game where you get to experience life and nature.

By creating a second engineering game, we are leveraging our existing technology and experience

The thought that we should postpone the development of Medieval Engineers for years was a no-go. We had to find a better solution.

We started to hire new people so that we would have the resources to develop both games in parallel without sacrificing any of them. The size of our team is nearing 40 people and we are still growing. There are separate teams for Space Engineers, Medieval Engineers and our secret AI project.

Very early we realized that even Space Engineers could actually benefit from the development of Medieval Engineers. A medieval setting has different requirements for volumetric environments and it forces us to look at the engineering genre from a different angle. To be more specific, these are the things that Space Engineers earned (or may receive in the future) thanks to Medieval Engineers:
  • Compound blocks – multiple blocks being positioned into one grid cell; this will allow better ship designs
  • Mechanical blocks
  • Auto-generated details for some blocks (e.g. roof endings in Medieval Engineers, armor edges in Space Engineers)
  • Voxel hand – a tool for modifying terrains (asteroids); you can alter shape and material
  • Structural integrity
  • Natural landscape
  • Procedural terrain generator (this is why we were able to easily add procedural asteroids to Space Engineers)
  • DirectX 11 (we decided to add PBR - Physically Based Rendering)

On the other hand, Medieval Engineers inherited (or will get) these features:
  • Multi-player
  • Physics, rendering and all 'core engine' stuff
  • Steam Workshop
  • Modding SDK and API

Developing two early access games with the same theme (Engineering) at the same time will be beneficial for both of them.  As happened with Space Engineers, many of the features that were released later on were inspired and suggested by our players. Now we are expecting that player’s suggestions for one game might give us new ideas for other games – ideas that we might have missed due to the limitations of the environment of each title. Now everyone will have more options and possibilities!

In a certain way, the development of the prototype of Medieval Engineers was more challenging than the development of Space Engineers. In Space Engineers we could invent new types of blocks. In Medieval Engineers we couldn't invent something that wasn't present in the Middle Ages or something that one person in single-player mode wouldn't be able to operate. On the other hand, the possibilities of survival/realistic mode in Medieval Engineers are fantastic - just imagine starting the game with Stone Age technology and slowly building your way up to the Iron Age.

Announcement video


Until now the medieval team focused only on preparing the announcement video. First we selected features that had to be finished prior to recording. Then we wrote a simple story script, crafting what we wanted to show in each individual section. Together with this we started composing a draft version of the music, which got re-recorded later by a live orchestra. We hope you will enjoy the video and get the feel of what's coming in Medieval Engineers.

The video was shot in creative mode (no survival) and shows a blue player building a castle, block by block (of course we skip through most of this), then a red player comes and builds a trebuchet and attacks the castle, after which the blue player escapes through a secret passage.



Our motivation: why we keep doing these things


We believe that one of the strongest forces in the universe is the “need to create”: every time you build something out of nothing, every time you give a shape and organization to something that has no structure – you are creating a miracle. 

Add a team of people who don’t want to settle for the easy but strive for the challenging and impossible – and you will understand why we do what we do.

We have a strong need to create and we take pride in completing unachievable goals.

This is Keen Software House in a nutshell :)

Development of Medieval Engineers


We wanted to bring Medieval Engineers to a presentable state as soon as possible (sacrificing the number of features that could be shown on day one – therefore only focusing on core and must-have mechanics). Getting real feedback from you was our topmost priority. Working on a game behind the veil isn’t fun and is altogether much less effective. Real people with real needs and real voices you can listen to are the heart of game development.

Early prototype screenshots:
http://mirror.keenswh.com/Pics/04_14.jpg
http://mirror.keenswh.com/Pics/08_14.jpg
http://mirror.keenswh.com/Pics/09_14.jpg
http://mirror.keenswh.com/Pics/12_14.jpg

Note: these images are old development screenshots and don’t represent the actual state of the game

You can download more development screenshots from here: http://mirror.keenswh.com/Pics/Development_screenshots.rar

Timeline:
  • 6/2013 – this was some  time around the day we started preparing the trailer for Space Engineers. We realized that the volumetric-block idea could be used for another game as well and that we did'n need to stick to space forever.
  • 1/2014 – new programmers were coming to the team and we started to consider working on Medieval Engineers. We bought tons of books about medieval and ancient technology and discussed the subject with various medieval fans and experts
  • 4/2014 – the first real work on block designs had started, but things were progressing slowly because there had been a lot of work on Space Engineers
  • 9/2014 – fulltime work on music composition had started
  • 9/2014 – real work on Medieval Engineers had started, new artists and programmers joined the team, and we started experimenting with structural integrity and destruction. We set our topmost milestone: prepare the game for an announcement trailer on Jan 13, 2015
  • 1/13/2015 – today: Medieval Engineers announcement
  • ?/2015 – release on Steam Early Access

Space Engineers and Medieval Engineers share the same code base.

Designing blocks that fit well together and occupy exactly the required area and provide the needed functionality was a very big task and we spent several months iterating through the options.

Two different approaches to destruction and structural integrity were tried before we agreed on using Havok  Destruction and writing our own structural integrity algorithm (that runs well in real-time and handles majority of situation properly and could support voxels/terrain in future). We are still trying to perfect this approach.

The music for Medieval Engineers is being composed by Karel Antonin - who already worked on music for Miner Wars (later used in Space Engineers). We analyzed various medieval musical instruments and styles from different countries and then applied this when composing songs to produce something that’s modern yet medieval, heroic and inspiring. I am very happy with the results and I hope you will like the music too.

What's next


In regards to Space Engineers, we are preparing a few major updates within the next months – just a hint: AI, real campaigns and goals, more optimizations and fixes. There is nothing to be afraid of that will affect or change our development plan.

We will keep Thursday releases for Space Engineers. Once we release Medieval Engineers on Steam Early Access and get our first real feedback, we will try to keep updating it as well – probably every Tuesday - but it’s hard to make a promise here, because having one update per week is challenging enough and two updates will be total overkill – on the other side, we don’t want to have easy life :)

We are still working on the Xbox One port of Space Engineers.

The first release of Medieval Engineers will “probably” feature:
  • Creative mode
  • Steam Workshop (SDK + API)
  • 'Heightmap to terrain' conversion tool
  • Special gift for all space engineers players :-)
  • Multi-player and survival will come later

We hope that the community of space engineers will welcome the medieval engineers’ community and that these two groups will join into one community of “engineers”. We are very much looking forward to the things you will create in Medieval Engineers and what you will surprise us with (just like you surprise us with what you keep accomplishing in Space Engineers).

The future looks bright and there’s a lot of work in front of us. This is good :)

Please let all your friends who may be interested in engineering games know about what are we creating. Thanks!

---
Thank you for reading this! For the latest news on our games, follow us on Facebook or on Twitter.
Medieval Engineers on Facebook: https://www.facebook.com/MedievalEngineers
Medieval Engineers on Twitter: https://twitter.com/MedievalEng
Space Engineers on Facebook: https://www.facebook.com/SpaceEngineers
Space Engineers on Twitter: https://twitter.com/SpaceEngineersG

Wednesday, December 17, 2014

Space Engineers: Super-large worlds, Procedural asteroids and Exploration

Today we released three large features and we want to tell you more about how they work and how we implemented them.

We are really happy to be able to deliver this to you as a Christmas gift :-) Hopefully there won’t be any major problems.

Super-large worlds


Even before we implemented “super-large worlds”, the size of a world in Space Engineers was not limited, but for practical reasons it was recommended to stay within a 10km radius of the origin. The reason for this was that floating-point calculations (vector and matrix multiplications) were gathering numerical imprecisions and after 10km you would experience shaky movements and rotations.

Super-large worlds are increasing this safe radius up to 1,000,000,000 km, which equals to 6.6 AU (AU stands for astronomical unit; 1 AU = 150,000,000 kilometers and it’s the distance from the Sun to Earth). For your illustration, 6.6 AU is slightly more than the distance from the Sun to Jupiter.

If you decide to use your ship to travel from one side of the game world to the opposite, and you will fly on maximum speed (115 m/s), it will take you 552 years (checking calculation: 2 x 6.6 AU / 115 m/s).

For all practical purposes, “super-large worlds” could be considered “infinite worlds”, but the limit is still there and we don’t want to lie to you.

How did we increase the precision of numerical computations? 
  • Until now, Space Engineers and its physics engine (Havok) were using single-precision 32-bit floating point numbers. This data format has a certain precision, leading to visible imperfections on objects located further than 10km from the origin
  • We have modified all game objects to support double-precision 64-bit floating point numbers -- this was the easy part
  • The harder one was to change the integration between Space Engineers and Havok (so Havok can keep using 32-bit floating point numbers). We solved it by clustering the game world into independent clusters of objects (minimal cluster size is 20km). Depending on dynamic objects density, cluster size can increase its size without limits. Common cluster size should be 50-100km. A clustering algorithm guarantees that no dynamic object can be closer than 2km to the cluster border. Clustering is totally transparent to users, it runs in the background and you won’t see it.
  • In other words, the world in Space Engineers is split into independent clusters, wherein each object has its own coordinates relative to the cluster center. As a result Havok doesn’t need to use double-precision math (physics calculations are faster in single-precision mode).

 

Procedural asteroids


The “procedural asteroids” feature adds a practically infinite number of asteroids to the game world. On top of that, all these asteroids are fully destructible and don’t consume RAM/memory.

Until now, Space Engineers supported only asteroids that were fully loaded during the loading phase and then kept as voxels and triangles in memory. There were only a few basic asteroid shapes.

From now on, there are two types of asteroids:
  • old version - that can be used for handcrafted asteroids in future scenarios/missions
  • new version – asteroids that are procedurally generated at the moment they are required (player enters an area near the asteroid, random floating object gets in a collision with the asteroid, etc.). This type of asteroid doesn’t occupy memory (except some small data for noise seed, position, etc.). Even after it’s generated and inserted to the game world for physics simulation, the voxels are not kept in memory. Only if something alters the shape or material on the asteroid then these changes are made permanent. Unaltered asteroids are removed from the memory, but when a player returns they are re-inserted with the exact same shape. Players won’t see a difference, for them all asteroids appear persistent
This new asteroid type should also reduce saving and loading times (because these asteroids are represented by a noise function, instead of an array of voxels).

We also implemented a new voxel LOD system (LOD = level of detail). The old one had only two levels of detail and required voxel data in memory. The new one has many levels of detail and helps with optimizing polygon meshes and voxel data as well (e.g. when generating geometry for procedural asteroids at a distance, the game requests only coarse low-detail procedural generation which is faster than high-detail voxels). In other words, distant asteroids  use fewer polygons and fewer procedural generation calls.

There’s also an “asteroid field generator” – which is used to allocate and deallocate asteroids as you travel through space. We can configure it to generate dense or sparse asteroid fields, or areas with no generated asteroids (this will become useful once level designers start creating scenarios).

We had changed the background skybox to not contain those “fake” asteroids anymore. We still keep quite bright fog, but you are free to alter it through modding.



Exploration


An exploration feature adds a practically infinite number of ships and stations to the game world, so there will always be something to discover, explore, acquire and conquer. You can imagine it this way: you are traveling in some direction and there is an asteroid, so you decide to check it and see if there’s something in its tunnels, in its proximity or on its surface. Or you just fly around in empty space and boom, a lost wreck shows up near you.

Almost all ships used in this first phase of the exploration release are player created content downloaded from Workshop. Everyone can find his name in game credits.

More info in my previous blog post: http://blog.marekrosa.org/2014/12/space-engineers-exploration-call-for_3.html

Conclusion


“Super-large worlds, procedural asteroids and exploration are among the largest and most complex features we have implanted in Space Engineers / VRAGE engine.

This is just a first phase; we plan to keep improving after your feedback.

--

Thanks for reading this! For the latest news, follow Space Engineers on Facebook or on Twitter.

Wednesday, December 3, 2014

Space Engineers: Exploration & Call for “player created content”

One of the bigger features that we are going to release very soon is exploration (together with “super-large worlds” and “procedural asteroids” – more details in a future blog post).

We need your feedback and that’s why I am declassifying it prematurely :-)

Exploration


The exploration feature will add a practically infinite number of ships and stations to the game world, so there will always be something new to discover, explore, acquire and conquer. You can imagine it like this: you are traveling in some direction and there is an asteroid, so you decide to check it and see if there’s something in its tunnels, in its proximity or on its surface. Or you just fly through empty space and boom, a lost wreck shows near you. Exploration is an upgrade to how cargo ships work.

Because the game world will now contain millions of ships (of course, you will be able to observe and visit only a fraction of them), exploration had to be implemented in a CPU/RAM friendly way, so these ships will be inserted and removed to/from the game world as you get closer/further. In other words, only a fraction of all these millions of ships will be subject to physics simulation at any given moment.

This way, ships are procedurally spawned and don’t consume RAM. Only altered ships are stored persistently (e.g. damaging a ship, entering a cockpit, changing values in the terminal). You can fly for a long period of time and your RAM usage shouldn't change. Of course, if you spot a ship but don’t touch it, then fly away (it gets removed from the RAM), then fly back, exactly the same ship will get added at that location. You won’t notice any difference. For you, all ships will appear persistent.

Ships won’t have AI for now, maybe later. Some will have disabled reactors; some will be active with turrets waiting for you. Only cargo ships will be moving.

Call for “player created content”


Where to get all these ships and stations? 
  1. We could develop a procedural ship/station generator – this would require a lot of additional work and the result will never be as good as what creative humans can create
  2. We could hire dozens of designers who could design these ships (while not working on new scenarios/missions)
  3. We could use what the SE community has already created – more than 50,000 creations on Steam Workshop. We would browse all ships/stations/blueprints and decide which ones get included into Space Engineers

We like the third option the most and I hope you will too :-)

The Steam Subscriber Agreement allows us to include all workshop creations into our game, but since this may be a big thing for some people, we decided to ask what our community thinks. Please use this survey and help us decide. LINK

Everyone whose creation will be used in Space Engineers will get his name into the game credits.

What workshop works are we going to put into Space Engineers?
  • Small and large ships, asteroid outposts, hidden stations, mining operations, semi-automated drones, etc. 
  • Only performance friendly works
  • Only ships that are not using mods
  • No third-party intellectual property (e.g. no Star Wars ships)

The exploration feature will be highly moddable and you will be able to add your own ships, even those using mods (e.g. new blocks). This will work in multi-player as well.

---
Thanks for helping us!

-- EDIT --

One week after the poll went live we have some results:

Thanks!