Hello, I am Ondrej Petrzilka, for those who don't know me I am the lead developer for Space and Medieval Engineers. I joined Keen Software House in 2011 as a game programmer for Miner Wars 2081 and since then I have worked on various projects in the studio mostly on the development of Space Engineers. In this blog post I would like to put some light on our current and future plans with Space Engineers. Currently we’re working on three big things: planets, scenarios and new multiplayer.
Planets have been discussed many times and players have wanted them for a long time. I would like to give you more information about our intentions and the background of the idea.
When Space Engineers was released to Early Access, we were very pessimistic about planets, but that changed by the end of 2014, when the procedural asteroid generator was created. We realized that it could be possible to create bigger asteroids – more than 8 km across. When we discussed planets in the team, we’ve realized we don’t just want just big asteroids, we want planets with ‘everything’.
Planet features:
How big should the planet be? Currently we’re able to create ‘planets’ with a size of around 20 – 50 km. It’s quite small compared to Earth and technically, it’s not a planet. Even Pluto has a radius 1184 km and it’s classified as a dwarf planet. When we tried first prototypes of big asteroids, 8 km in diameter, it looked pretty big. With bigger sizes, gameplay issues emerged.
Imagine a planet with a radius of 100 km. You’ll get close to the planet to fill your screen from top to bottom. When you have default field of view (FOV in video options), you’ll be still 73 km away from the planet surface! When traveling at the maximum speed of 104 m/s, it will take you almost 12 minutes to reach the surface. That seems like too long.
How long would it take to fly around a 100 km planet? The circumference of a 100 km planet is 628 km. When traveling at maximum speed, it would take more than 90 minutes to fly around.
Solution. First we were thinking about changing the maximum speed, but it’s too problematic. We’re limited by physics stability, bullet-through-paper issues and other problems. We’ve decided to make planet size configurable in world options (minimum and maximum planet size). This way we can release planets soon and satisfy players who want small planets and also players who want huge planets. It’s possible that we will reevaluate maximum speed in future.
Gravity. Planets will have gravity which is similar to earth gravity. With distance from a planet, gravity will gradually decrease; bigger planets will have more gravity. We plan to apply planet gravity to ships as well.
Atmosphere. We plan to add atmosphere to certain planets; when there’s atmosphere, there will be vegetation. Other planets will be barren, without atmosphere. Vegetation should be very similar to what you see in Medieval Engineers. To achieve nice atmosphere effects, we’re planning to use a special shader which takes into account sun direction, air density, the distance light travels through air and other parameters. It will be possible to breathe freely and refill the oxygen tanks on a planet with atmosphere.
Visibility distance. Space Engineers has a default view distance of 20 km. If you were to fly toward a 30 km asteroid or planet, you would see nothing…nothing…nothing…and then suddenly a big planet would appear in front of you. This feels very weird and it would break the experience, so we had to come up with a solution.
One option was increasing view distance, but there’s still a limit of 50-70 km, because of Z-buffer precision. We wanted players to see planets from 1000 km distance or more. We’ve decided to render distant planets‘separately’. This allows players to see planets 10.000 km away, while other objects like ships and small asteroids are visible only to 20 km.
In last 15 months, we’ve added a large amount of game features, but we haven’t added much of the gameplay. Space Engineers is now sandbox game where you can do many crazy things…without any goal. We’re planning to add goals soon; you’ve probably seen the first scenario a week ago, this was just a testing scenario. More scenarios will follow; both single-player and multi-player.
The primary purpose of scenarios is to entertain players who seek goals and achievements in the game. The secondary purpose is to teach new players how to play the game and introduce them slowly to most of the game mechanics. A game like this, with a lot of features available at once, can be confusing for new players.
Single-player scenarios will consist of a series of objectives with possible branches (sometimes the player will be able to choose how to progress). Scenarios will take advantage of features which are already in game. First scenarios will be very straight-forward, to teach players certain mechanics, like mining or repairing the station. Then there will be more advanced scenarios with multiple ways of reaching the goal. An example can be: ‘destroy military output’. It will be up to the player to decide whether to build a heavily armored ship with missile launchers or to build decoys for distraction, blow one turret with a warhead and hack the rest of outpost. We haven’t decided yet whether it will be possible to play single-player scenarios in cooperative mode.
Multiplayer scenarios will be designed to bring some competitive gaming to Space Engineers. We’re discussing the designs of these scenarios in the team. There are ideas for classic scenarios like "defend station", "capture the flag", "death-match" and less common scenarios, for example where players compete in mining to deliver the largest amount of gold ore from a big gold asteroid to a merchant. Some scenarios will be team-based while others will be free-for-all.
Modding. We want to make scenarios fully modable, it should be possible for modders to create and script both single-player and multi-player scenarios. There will also be a simple scenario editor directly in-game; modders will be able to prepare a world and select victory conditions in the UI. Modders will be able to use prepared infrastructure, like victory/game-over screens, scoring screens, team selection, define player inventory, possible respawn count and more.
Update 01.015, which added multiplayer was released on Jan 16th 2014, more than a year ago. Multiplayer itself was written in 5 weeks. We knew it’s far from being perfect, there were connection issues, lags, desync issues, jittering, hackers and many many other issues. We didn’t want to spend 2 months rewriting multiplayer from scratch, so we decided to fix the things we could fix and focus on ‘better’ multiplayer later. We also knew that if we add infinite worlds, we’ll have to change multiplayer again.
Now we’re ready to rewrite multiplayer from scratch. The game has many more features and we can take these into account when rewriting multiplayer, especially infinite and procedurally generated worlds. We also have a bigger team, so we can keep adding features and also work on multiplayer.
In the current version of multiplayer, every client knows everything. When somebody is drilling 100.000 km away, the client gets this information from the server. It’s not necessary for the client to know it; the client should only get this information when he gets close to the drilled asteroid. In new multiplayer, clients will only receive information which is necessary and related to an area close to their position (or camera position in case they are looking through camera). This will reduce required bandwidth a lot; it will also allow many more players in the game (depending only on the server’s internet connection).
Information sent to the client will be prioritized; important things like position updates will have high priority. Less important things like battery capacity update or inventory changes will be sent with lower priority. This should reduce lags and make multiplayer more smooth.
Every client is now sending position updates to all other clients (it’s not going through server). This can reduce lag a little, but it also requires a bigger upload, because it’s necessary to send messages to every other client (not only to the server). It also makes connection issues much worse, because it’s necessary for each client to be connected to every other client. With more players on server, this issue has a much bigger impact.
In new multiplayer, the client won’t be connected to every other client, but only to the server. The server will validate data sent from the client (e.g. position updates) and send it only to other clients who need this information (clients who see the original client). This will prevent connection issues and reduce network bandwidth. It’s also a necessary step for increasing the number of players on server.
The current multiplayer uses the Steam Networking layer which allows us very easily to send data between players and it’s very easy to use. On the other hand it’s missing some advanced features. To get advanced features, we’ve decided to switch to RakNet. RakNet is a popular networking layer; it’s robust and it supports many platforms including Xbox, PlayStation, Linux, Android and other.
New multiplayer will work technically in a similar way to Halo Reach or the Tribes series (way of synchronizing objects and its properties). We’ve been working on the new multiplayer for a month now. The work will continue for at least several weeks or a few months before it’s done.
Stay tuned for more information about ship AI, Xbox, game controller and Medieval Engineers.
Note: All images are public domain
Thanks!
Ondrej Petrzilka
---
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
Planets
Planets have been discussed many times and players have wanted them for a long time. I would like to give you more information about our intentions and the background of the idea.
When Space Engineers was released to Early Access, we were very pessimistic about planets, but that changed by the end of 2014, when the procedural asteroid generator was created. We realized that it could be possible to create bigger asteroids – more than 8 km across. When we discussed planets in the team, we’ve realized we don’t just want just big asteroids, we want planets with ‘everything’.
Planet features:
- Decent size
- Gravity (affecting ships too if possible)
- Atmosphere
- Terrain (mountains, canyons)
- Vegetation (trees, bushes, grass)
- Visible from big distance (1000+ km)
How big should the planet be? Currently we’re able to create ‘planets’ with a size of around 20 – 50 km. It’s quite small compared to Earth and technically, it’s not a planet. Even Pluto has a radius 1184 km and it’s classified as a dwarf planet. When we tried first prototypes of big asteroids, 8 km in diameter, it looked pretty big. With bigger sizes, gameplay issues emerged.
Imagine a planet with a radius of 100 km. You’ll get close to the planet to fill your screen from top to bottom. When you have default field of view (FOV in video options), you’ll be still 73 km away from the planet surface! When traveling at the maximum speed of 104 m/s, it will take you almost 12 minutes to reach the surface. That seems like too long.
How long would it take to fly around a 100 km planet? The circumference of a 100 km planet is 628 km. When traveling at maximum speed, it would take more than 90 minutes to fly around.
Solution. First we were thinking about changing the maximum speed, but it’s too problematic. We’re limited by physics stability, bullet-through-paper issues and other problems. We’ve decided to make planet size configurable in world options (minimum and maximum planet size). This way we can release planets soon and satisfy players who want small planets and also players who want huge planets. It’s possible that we will reevaluate maximum speed in future.
Gravity. Planets will have gravity which is similar to earth gravity. With distance from a planet, gravity will gradually decrease; bigger planets will have more gravity. We plan to apply planet gravity to ships as well.
Atmosphere. We plan to add atmosphere to certain planets; when there’s atmosphere, there will be vegetation. Other planets will be barren, without atmosphere. Vegetation should be very similar to what you see in Medieval Engineers. To achieve nice atmosphere effects, we’re planning to use a special shader which takes into account sun direction, air density, the distance light travels through air and other parameters. It will be possible to breathe freely and refill the oxygen tanks on a planet with atmosphere.
Visibility distance. Space Engineers has a default view distance of 20 km. If you were to fly toward a 30 km asteroid or planet, you would see nothing…nothing…nothing…and then suddenly a big planet would appear in front of you. This feels very weird and it would break the experience, so we had to come up with a solution.
One option was increasing view distance, but there’s still a limit of 50-70 km, because of Z-buffer precision. We wanted players to see planets from 1000 km distance or more. We’ve decided to render distant planets‘separately’. This allows players to see planets 10.000 km away, while other objects like ships and small asteroids are visible only to 20 km.
Scenarios
In last 15 months, we’ve added a large amount of game features, but we haven’t added much of the gameplay. Space Engineers is now sandbox game where you can do many crazy things…without any goal. We’re planning to add goals soon; you’ve probably seen the first scenario a week ago, this was just a testing scenario. More scenarios will follow; both single-player and multi-player.
The primary purpose of scenarios is to entertain players who seek goals and achievements in the game. The secondary purpose is to teach new players how to play the game and introduce them slowly to most of the game mechanics. A game like this, with a lot of features available at once, can be confusing for new players.
Single-player scenarios will consist of a series of objectives with possible branches (sometimes the player will be able to choose how to progress). Scenarios will take advantage of features which are already in game. First scenarios will be very straight-forward, to teach players certain mechanics, like mining or repairing the station. Then there will be more advanced scenarios with multiple ways of reaching the goal. An example can be: ‘destroy military output’. It will be up to the player to decide whether to build a heavily armored ship with missile launchers or to build decoys for distraction, blow one turret with a warhead and hack the rest of outpost. We haven’t decided yet whether it will be possible to play single-player scenarios in cooperative mode.
Multiplayer scenarios will be designed to bring some competitive gaming to Space Engineers. We’re discussing the designs of these scenarios in the team. There are ideas for classic scenarios like "defend station", "capture the flag", "death-match" and less common scenarios, for example where players compete in mining to deliver the largest amount of gold ore from a big gold asteroid to a merchant. Some scenarios will be team-based while others will be free-for-all.
Modding. We want to make scenarios fully modable, it should be possible for modders to create and script both single-player and multi-player scenarios. There will also be a simple scenario editor directly in-game; modders will be able to prepare a world and select victory conditions in the UI. Modders will be able to use prepared infrastructure, like victory/game-over screens, scoring screens, team selection, define player inventory, possible respawn count and more.
New Multiplayer
Update 01.015, which added multiplayer was released on Jan 16th 2014, more than a year ago. Multiplayer itself was written in 5 weeks. We knew it’s far from being perfect, there were connection issues, lags, desync issues, jittering, hackers and many many other issues. We didn’t want to spend 2 months rewriting multiplayer from scratch, so we decided to fix the things we could fix and focus on ‘better’ multiplayer later. We also knew that if we add infinite worlds, we’ll have to change multiplayer again.
Now we’re ready to rewrite multiplayer from scratch. The game has many more features and we can take these into account when rewriting multiplayer, especially infinite and procedurally generated worlds. We also have a bigger team, so we can keep adding features and also work on multiplayer.
In the current version of multiplayer, every client knows everything. When somebody is drilling 100.000 km away, the client gets this information from the server. It’s not necessary for the client to know it; the client should only get this information when he gets close to the drilled asteroid. In new multiplayer, clients will only receive information which is necessary and related to an area close to their position (or camera position in case they are looking through camera). This will reduce required bandwidth a lot; it will also allow many more players in the game (depending only on the server’s internet connection).
Information sent to the client will be prioritized; important things like position updates will have high priority. Less important things like battery capacity update or inventory changes will be sent with lower priority. This should reduce lags and make multiplayer more smooth.
Every client is now sending position updates to all other clients (it’s not going through server). This can reduce lag a little, but it also requires a bigger upload, because it’s necessary to send messages to every other client (not only to the server). It also makes connection issues much worse, because it’s necessary for each client to be connected to every other client. With more players on server, this issue has a much bigger impact.
In new multiplayer, the client won’t be connected to every other client, but only to the server. The server will validate data sent from the client (e.g. position updates) and send it only to other clients who need this information (clients who see the original client). This will prevent connection issues and reduce network bandwidth. It’s also a necessary step for increasing the number of players on server.
The current multiplayer uses the Steam Networking layer which allows us very easily to send data between players and it’s very easy to use. On the other hand it’s missing some advanced features. To get advanced features, we’ve decided to switch to RakNet. RakNet is a popular networking layer; it’s robust and it supports many platforms including Xbox, PlayStation, Linux, Android and other.
New multiplayer will work technically in a similar way to Halo Reach or the Tribes series (way of synchronizing objects and its properties). We’ve been working on the new multiplayer for a month now. The work will continue for at least several weeks or a few months before it’s done.
Stay tuned for more information about ship AI, Xbox, game controller and Medieval Engineers.
Note: All images are public domain
Thanks!
Ondrej Petrzilka
---
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
