"Need to create" - Builder, accelerationist, and Founder/CEO at KeenSWH.com and GoodAI.com - Working on AI People and LTM, Space Engineers 2, VRAGE3 engine and Resilient Civilization
Starting today Nov 23, 2017 and ending on Jan 31, 2018
6 categories:
Engineering Ingenuity
Physics Bending
“Crash Test” Recreation
“Community Creations” Recreation
Vanilla Epicness!
Modding Epicness!
Win Skin Sets & Space Engineers T-Shirts and Hoodies
Hello, Engineers!
Now that the release of our Major Physics Overhaul is in the hands of the community, we’ve decided that it’s time to kick off a new contest with physics and engineering as the focus. It’s been great seeing what people have been able to achieve since this update released so now is your chance to really show everyone what you are capable of! You can read more about last week’s update on my previous blog post.
For those of you who couldn't watch the Major Physics Overhaul developer livestream,
here's the recording:
We are launching the Physics & Engineering Contest today with a number of different categories. The prizes include in-game Skin Sets, Space Engineers T-Shirts, and Space Engineers Hoodies! On top of that, some screenshots may be added to the official loading screens or even printed on canvas and displayed in the KeenSWH offices!
This contest will run until the end of January 2018. There will be five categories and each will have three winners.
Entries can be submitted in a number of different formats. Preferably, we want to see mind-blowing videos of your creations but you can also submit workshop worlds and high resolution screenshots.
Across all categories, we want you to capture the original visual styling and feeling of Space Engineers. Please see my blog post for more details and advice on how to achieve this original look that we are looking for. We are working internally to get back to this visual style, both in-game and in marketing/public presentation.
Because we are already in the process of switching to a new sky-box, you can use it as well before it is officially released
General Info
Each player can submit 1 entry per category
Deadline for submissions is January 31, 2018
Tasteful manipulation and enhancement of videos and screenshots through editing software like Premiere, Photoshop and gimp are allowed, as long as the source was in-game.
Across all categories, we will be looking at the composition, colors, story and uniqueness of the shot.
Screenshots and videos must have a minimum resolution of 1080p but the higher the better! Use the guide below to capture screenshots in a higher resolution than your monitor. 4K and above would be great!
Some winners may have their images added as official loading screen or printed onto canvas and used in the KeenSWH offices!
By entering the contest, you agree to follow all rules of the contest. If you don't submit according to the rules, you can be disqualified.
All entries of the contest become the property of Keen Software House. This means we have the right to use and modify your entries in our game, on social media, on our websites, etc.
We reserve the right to modify, cancel, or postpone the contest for any reason.
Prizes
Winners of each category will get to choose complete skin sets of their choice.
1st Place: 3 Skin Sets & Space Engineers T-Shirt & Space Engineers Hoodie
2nd Place: 3 Skin Sets & Space Engineers T-Shirt
3rd Place: 3 Skin Set
What to show?
Even though each category will have different requirements, there a certain aspects that we are looking for across all entries. These include physics, engineering, destruction, deformation, pistons, rotors etc. While an entry does not need to cover all of these aspects, it should have at least one of them being showcased by your design. Space Engineers has some of the most advanced game physics in the industry. You are able to create and engineer things not possible in any other game, and this is what we want to see!
(Ordered by preference) - It’s up to you to decide which format to use!
Video
World (Steam Workshop )
Screenshots
We encourage users to use our F4 screenshot functionality as it gives much higher resolution screenshots.We have added a screenshot resolution multiplier settings in the in-game options to allow users to take 4K and higher screenshots on lower end systems.
How to submit your creation
Send the link with your creation to our email at press@keenswh.com with the subject line “Physics & Engineering Contest”.
Please also clearly state which category your submission belongs in and include a link to your Steam profile.
Deadline for submissions is January 31, 2018
Evaluation
By myself and the Space Engineers team
The Categories
Engineering Ingenuity
Show off your engineering prowess with this category! Solve unsolvable problems… physical puzzles, unbelievable constructions ...most wild physical construction…
Physics Bending
For the second category, we are interested in creations that are not possible under normal physical laws and/or under Space Engineers’ physical laws. Just how crazy can you push the limits of realism?
“Crash Test” Recreation
Recreate scenes of your choice from the “Crash Test” trailer from 9/2013. This category is for people who think they can recreate the legendary scenes from the initial release. The good ol’ days! They don’t necessarily have to look exactly the same as the originals but they must follow the same visual style rules or tell a similar story.
“Community Creations” Recreation
Recreate creations of your choice from the “Community Creations” trailer from 10/2014. This category is for people who think they can recreate the legendary creations from the initial release. The good ol’ days! They don’t necessarily have to look or function exactly the same as the originals but they must follow the same visual style rules or be capable of similar tasks.
Vanilla Epicness!
This category is about creativity! The only rule is to follow the guidelines of our art style guide. You could design a fleet, a planet base, or even just show some epic destruction! We’re always blown away by the creativity of our players, so show us what you can do with our vision!
Modding Epicness!
The 6th and final category is almost identical to one above with the difference being that you can use as many mods as you like! We want to see what you can do when harnessing the full potential of the Steam Workshop and the thousands of mods that exist on the platform.
Space Engineers is still in development. Everything in the game is subject to change.
If you have any questions or requests, please do not hesitate to contact us, we will do our best to solve your problems.
We would be also very happy if you can submit your feedback at our Space Engineers Steam store page and encourage us to do better. We welcome both positive or negative comments, it helps us to create better game for you.
Thank you for reading and we look forward to seeing what you can engineer and come up with!
Marek
Rosa is the CEO and CTO of GoodAI, a general artificial intelligence
R&D company, and the CEO and founder of Keen Software House, an
independent game development studio best known for their best-seller
Space Engineers (2.4mil+ copies sold). Both companies are based in
Prague, Czech Republic. Marek has been interested in
artificial intelligence since childhood. Marek started his career as a
programmer but later transitioned to a leadership role. After the
success of the Keen Software House titles, Marek was able to personally
fund GoodAI, his new general AI research company building human-level
artificial intelligence, with $10mil. GoodAI started in January 2014 and has grown to an international team of 20 researchers. At this time, Marek is developing both Space Engineers and Medieval Engineers as well as daily research and development on recursive self-improvement based general AI architecture.
New planet with unique biomes and additional resources!
Research quests
Improvements for animations and performance!
Hello, Engineers!
I have been working with the Medieval Engineers team over the last couple of months to make sure the game fulfills our original vision. This major update is one step towards this goal. It’s full of features like a new planet with new biomes to explore, new resources to mine, new tools to build faster, and mechanical blocks to enhance crafting! You get all of that along with research quests so you can discover more advanced blocks while building and improved character animations so your engineer looks good exploring the world.
If you already own the game, all of this content is free! If you haven’t bought your copy yet, get it today because Medieval Engineers has never been a better value. Other improvements include faster multiplayer code, faster voxel loading, and faster particle effects! See all of this and more in this latest trailer for Medieval Engineers!
Now With Mechanical Block!
As the name alludes, Medieval Engineers now has Mechanical Blocks! You no longer need to mill your wheat and saw your timbers by hand. It’s possible to build machines that will do the work for you with greater speed and efficiency. You can get started with a windmill to provide power and various joints and shafts to connect things together. There is a small selection of crafting blocks available right now. Don’t worry, we are planning to continue adding new crafting blocks to expand the mechanical systems with your feedback and suggestions in mind.
Now With Biomes!
There is a new planet for you to explore in this update of Medieval Engineers. It comes with new terrain and seven distinct biomes! Each one has a unique mix of flora and terrain to create vistas unlike anything you’ve seen before in Medieval Engineers. You can mine precious metals alongside desert mesas, build a stone lodge in the frozen arctic, and farm amongst the hazel trees in the cratered karst landscape. Take a trip across the steppe grasslands and go lumberjacking in the coniferous forests. There’s something new to discover over every mountain!
Now With New Resources!
The planetary changes don’t stop with just the scenery. There are additional resources carefully woven into the biomes by our elite team of designers. These include new ores such as tin, copper, silver, and gold that you can discover and mine. You can smelt new types of metal ingots to use or process into alloys. Tools and weapons varying in efficiency and durability based on the metals used to craft them. There is also a new clay material that you can use to craft items like pottery, roof tiles, furnaces, and ovens. With these resources the game finally has the depth and complexity you’ve been asking for, and I think you’ll love it.
Now With Research Quests!
The quest system has been whipped into shape by including starting conditions, failure conditions, multiple prerequisite conditions, location finding, and control over what is unlocked for you to build with. All of these have been put to use in the new research system that allows you to unlock knowledge by completing quests in the game. It is a more immersive approach that allows for a natural progression during gameplay and adds a little adventure into your engineer’s progression.
Now With Improved Animations!
I recently spent some time working with the team on aesthetic improvements and quality-of-life improvements for characters. These changes should improve the general game experience, especially during early gameplay when you are running around with only the engineer trying to survive. Some of these changes include more complex and polished animations, using tools as weapons (back by popular demand), and first-person camera movement improvements. Other things, like character behavior when trying to climb a hill that is too steep and better particle effects for walking and running, have been polished.
Now with better performance!
Many of the changes in this update perform better than in the past. New player character code, changes to how voxels are updated, and an updated renderer are just a few of the optimizations you will find in 0.6.
Player Characters (PC’s): The programmers recently spent a lot of time writing more efficient PC code and along the way they were able to streamline the multiplayer aspect of PC’s as well. The results in trials were, instead of 10-15 characters causing slowdown on a server, it’s now possible to have 30-40 characters running and jumping around at the same time! This opens up a lot of possibilities for the future of Medieval Engineers as well as the immediate benefits to servers that support larger numbers of players and bots.
Voxels: We made some changes to voxels that resulted in impressive performance. You'll get into the game faster with reduced loading times and optimized rendering. Changes from mining and voxel hands are immediate.
Renderer improvements in VRAGE have much more optimized GPU performance than in the past. All of the particle effects are calculated on the GPU to reduce CPU bottlenecking. Additional render options have given us greater flexibility in the graphics options. There are new extreme settings for high-end graphics cards. Low-end graphics cards will benefit from the new low settings. In testing we’ve seen between 30% and 50% increases on low settings!
Modding changes
There are some great changes for modders including definition merging and definition inclusion. Definition merging makes it possible to modify or append part of a definition without changing the whole definition. This means smaller mods with less conflicts. Definition inclusion allows you to copy one definition into another. This works much like inheritance in programming and it’s not only useful on its own for modders but it’s a giant leap toward supporting mod libraries. There is a guide on how these work on the Medieval Engineers Wiki.
Character data is now saved on the character itself. Entity components that save on the character now persist between sessions, even in multiplayer. Finally, now that the old MyCharacter class is gone, characters are created by combining entity components. This makes characters much more flexible to work with for both modders and Keen programmers.
Notes
As always; we are leaving the previous version, 0.5.23, as a historical branch that will be available forever. This will be your fail-safe way to play older saves that aren’t compatible with 0.6 or to update those that are.
Marek
Rosa is the CEO and CTO of GoodAI, a general artificial intelligence
R&D company, and the CEO and founder of Keen Software House, an
independent game development studio best known for their best-seller
Space Engineers (2.4mil+ copies sold). Both companies are based in
Prague, Czech Republic. Marek has been interested in
artificial intelligence since childhood. Marek started his career as a
programmer but later transitioned to a leadership role. After the
success of the Keen Software House titles, Marek was able to personally
fund GoodAI, his new general AI research company building human-level
artificial intelligence, with $10mil. GoodAI started in January 2014 and has grown to an international team of 20 researchers.
Grid deformations - Improved, optimized, tweaked and balanced
Optimizations - Less lag, more fun
Improved subgrid behavior and fragility
Stronger constraints for mechanical blocks so they don’t break so easily
Less Clang, more engineering
With today’s major update, 1.185.0, we are releasing a large overhaul to the physics in Space Engineers. The update is primarily focusing on pistons, rotors, landing gears, and grid deformations.
The original vision of Space Engineers was to build a game where physics behave exactly as in the real world. We wanted players to be able to transfer their intuition from the real world to the game world. Things in Space Engineers should behave exactly as one would expect them to behave in real world. There shouldn’t be things that look like they can do something but actually cannot and are there just for visual effect. We wanted to create a game where there are no limits in what players can create.
Just as an illustration: in Space Engineers we have practically infinite worlds, players can seamlessly travel from planets to moons to asteroids, they can build and destroy everything that’s in the world, they can dig through the entire planet which are huge -- up to 120 km, players can build kilometer-long ships while being completely destructible. Ships and stations have their own mechanics - pistons, rotors, thrusters, gravity generator, conveyors, programmable computers and many more.
On top of that, everything is destructible, deformable, recalculated in real time, different blocks have different strength, gravity and other forces push on objects, ships crashes and collisions feel like in real world. We consider these to be the core elements of Space Engineers.
This has been a top priority for me and the SE team during the last year - to have these things be as robust, stable, and intuitive as possible.
The game’s physics are now more stable and creations shouldn't break, explode or do uncontrollable things under normal conditions with default settings. But if players override safe parameters (via mods or in-game sliders) and really push our engine, things may get uncontrollable. However in general, the physics will now remain stable even under much more stressful conditions than before.
In other words, Space Engineers physics are now very stable and robust.
What is the worst case scenario that can still happen in game?
Setting max piston forces to very high values can cause clanging, as well as connecting grids with multiple constraints like a square array of connectors or a long chain of pistons.
I am very proud of what my team has achieved in this major update!
Honestly, I don’t think any other group has done more in the realm of real time large scale interactive physics volumetric simulations. No other game or software project is facing these kind of challenges on this scale.
We are pushing the frontier and defining the limits. It's a hard and painful process, but occasionally there are days like today, where we are happy to present our latest iteration!
Because Space Engineers is still under development, there may be bugs (our testers spent hundreds of hours testing, but this is nothing compared to tens of thousands of hours played by our community immediately after every update). Nevertheless, we will do everything to fix any issue as fast as possible. Disclaimer: This major update focuses on physics, not multiplayer. Although, the latter has received huge improvements as well. There are still situations in multiplayer where players can push physics to the limit and break the game. Our next focus will be these edge cases.
Teaser of future physics/multiplayer improvements:This video shows the Sacrificial Offering for Almighty Lord Clang in multi-player, with 500ms simulated ping, proper predictions, no cheating.
However, the game should be stable under default conditions, both in single-player and multiplayer.
This is a big day for all space engineers!
Space Engineers is still in development. Everything in the game is subject to change.
Thank you for reading and we look forward to hearing your feedback on this update.
Marek Rosa is the CEO and CTO of GoodAI, a general artificial intelligence R&D company, and the CEO and founder of Keen Software House, an independent game development studio best known for their best-seller Space Engineers (2.4mil+ copies sold). Both companies are based in Prague, Czech Republic. Marek has been interested in artificial intelligence since childhood. Marek started his career as a programmer but later transitioned to a leadership role. After the success of the Keen Software House titles, Marek was able to personally fund GoodAI, his new general AI research company building human-level artificial intelligence, with $10mil. GoodAI started in January 2014 and has grown to an international team of 20 researchers.
----------
The following technical post goes into great depth about the changes that were made to Space Engineers for this update. It was written up with diagrams and videos by Martin Pavlicek, one of our programmers here at Keen Software House who worked heavily on this physics iteration.
Physics Improvements
by: Martin Pavlicek
Motivation
More stable simulation and better user experience, while keeping the overall simulation as realistic as possible, have always been major goals of programmers in the Space Engineers team. We wanted to reduce (or rather remove) any chance of random explosions, glitching subgrids (which impact their parent grid and cause massive damage), or anything else that could upset players. During the multi-year development, Keen programmers have worked on many iterations to find a solution.
Welding (aka safety locking)
One solution that we tried using to resolve physics issues in general simulation was welding, also known as safety locking but it turned out to be not a sufficient solution. In theory, making one single rigid body out of multiple connected bodies may sound like a good idea, but in practice, it brings more problems than it really solves.
Let's take a look on one of the main cases that welding should solve.
In a following video, we can see interesting ship made out of multiple connected sub-grids. Welding should protect it from breaking up and make sure that sub grids don't disconnect at high speeds. What we get though is not really what we expected
(Note: Continue reading to see “After” version)
At its core, welding is a nasty trick achieved by dynamic swapping of rigid bodies at the core physics simulation level. Unfortunately, this doesn't come for free and introduces many side effects, like performance issues (Keen eye might notice simulation lag in previous video at 22s), simulation flaws like rigid bodies warping through each other when safety lock is enabled/disabled each frame...
... and risk of random disconnections of landing gears, wheels, rotors or pistons every time the grid is welded/unwelded and rigid bodies are hot-swapped ...
… and last but not least, ugly simulation where every rotor, piston or wheel freezes at high speeds.
This led us to conclusion that welding is not the way we should or want to go and decided to remove it entirely.
Max speed limitations
One of the main issues we had to deal with in past was the bullet-through-paper-problem (this is a well-known problem with real time physics simulation).
Limiting the max speed of in-game objects works pretty well for that case but problems come when sub-grids get limited more than base grid due to high angular velocity. See sketch below.
This usually causes sub-grids to disconnect and clang out at high speeds, particularly in space. We solved this issue by strengthening physical constraints and unlocking the subgrids max speed. This allows them to move as fast as needed to keep up with the still limited main/base/central grid.
By further strengthening and stabilizing the physical constraints that keep the sub-grids together, we achieved pretty stable simulation. To demonstrate our solution, lets take a look at the following case study. Combination of rotors, pistons, landing gears and on top of that, each attached fighter is further stressing the connections with enabled inertia dampeners.
Before state
and after
Stronger constraints
By further strengthening the constraints, we can push them to the limits now, without risk of piston parts flying all over the place like they usually ended up before.
Before state
and after
Or, when player wants, constraints can now be configured in a way so they break in predictable manner when stressed too much:
Shared inertia tensor
Another issue we had to solve in this iteration were so called “Jiggling grids”. These are creations with very large inertia tensor and/or mass ratios.
Unfortunately, we hit a wall here. This problem is particularly tricky for computers to correctly detect and resolve. After our experience with auto-safety locking, we decided not to opt for an auto-detection system, but rather give you, the players, full control over it. This will allow you to fine-tune your creations exactly to your needs.
That’s why we introduced so called Shared inertia tensor.
If we take a look at the following sketch: G1, G2, and G3 represent grids connected by physics constraints (blue and red lines), those might be for example rotors.
(User can enable shared inertia tensor option on rotor
connecting G1 and G2. Then, these two physical bodies will start to
share certain physical properties. Purple boxes illustrate that
grouping.)
Now, when G3 gets some external impulse, it will start to move and/or rotate. Red constraint will need to compensate G2 for G3’s displacement to keep their intended relative positions. The question is, how much will the G2 succumb and how much will be the G3’s movement slowed down by G2’s resistance.
The problem becomes more and more obvious the bigger the G1 and G3 are compared to the much smaller G2. Since the Havok constraints are solved one by one, not as an entire system as a whole, G2 will succumb to either G1 or G3 each frame, start to oscillate/jiggle between these two as the G1 and G3 will fight over G2. They’ll never move itself to actually find some common compromise and system will never converge to stable simulation/result.
That’s where the shared inertia tensor comes into the play; to either equalize physical properties across all bodies when enabled on every constraint-- as shown in the example below-- or say which grid will be the master and which one should succumb.
Here is in-game video with before and after.
(Central body is too “light” compared to satellite wings and they’ll start to fight over it’s position.)
It also helps to stabilize piston chains with “heavy endpoints”, as you can see on this example. Before, the scene didn’t even load without being immediately possessed by Clang:
Now, the scene loads just fine and pistons are even able to move at low speeds without any help of shared tensor. Unfortunately, as the speed goes higher, the pistons will start to behave as a bead chain and problems described above will start to show in a big way. After enabling the shared tensor, everything just works.
(Note that second piston chain is not using the shared tensor, yet still behaves naturally. No Clang present here.)
And finally in gravity.
(Note that they’ll bend as expected with disabled tensor sharing. It’s all about setting it up the way you want it.)
Just to not render it as some kind of silver bullet solution to every problem, there are some downsides to this, like simulation inaccuracy compared physical laws, and of course, sometimes we want sub-grids to be submissive as much as possible, for example on tank tracks so they don’t “fight” the main body. That’s why it’s not enabled by default and users should use it wisely and only when need, to achieve more stable creations.
Pistons
In previous iterations, pistons were pretty cheesy (when it came to any physical realism). They were also sometimes a pain to use because of their infinite strength and power to penetrate other solid obstacles.
Simulating some kind of suspension or pneumatic piston is not an easy task in real time physics simulation in general. It’s even worse in a world as dynamic as those Space Engineers can offer.
After some tests we decided to not dive into any kind of complicated piston implementation with strength settings and availability to be pushed back when too much pressure is applied on them. Partially because it would be too complicated and time consuming to make it work “right”, partially because it would ruin some creations that rely on pistons with “infinite force” and no pushback.
Thus we decided for compromise that will solve the worst issues players currently face but it will provide the “backwards compatibility” for those who need it at the same time. That is, keyframed piston with limited impulse.
Piston is natively backed by Havok fixed constraint. This is the stiffest constraint we can use now, as opposed to prismatic constraint which is intended for this scenario by Havok and may provide more accurate simulation, but its hold is quite vague under certain scenarios, especially when CoM is far from constraint pivot location.
When a piston is ordered to extend/retract, the constraint is manually positioned each frame and impulse, needed to get the rigid bodies to new desired position is measured. Whenever the impulse starts to grow over certain threshold, specified by player in GUI, the piston advancement is stopped until the constraint catches up again. This usually happens when piston head starts to collide with some other obstacle. It is either light enough so it can be moved away, or it starts to stress the constraint and stops the piston.
Before state
And after
Phantom forces
One of the big topics in the community are the so called phantom forces. The kind of strange behaviour when pasting a grid in space and then it starts to spin or fly away in an uncontrollable manner.
After investigating the issue, and doing some internal tests, we realized that this particular behavior is hard to control in real-time.
Imagine a simple case where there are two pistons connected to the same rigid platforms.
As long as the length of each of these two pistons stays the same as the other one, everything will be fine. The problem comes the moment when one of them changes its length compared to others connected to same rigid body. The inner stresses/tension that will raise inside the system at that moment will result in a fairly complex simulation problem that real-time physics is not able to correctly resolve in any reasonable manner and usually results in a simulation with systems that end up with more energy than they started with in each frame. Usually spinning, flying in different directions and sometimes clanging grids.
In any case, we are not able to differentiate these simulation flaws from normal simulation.
So, when designing your creation, try to avoid “double-connections” like shown on the example above and whenever you encounter the so called phantom forces, double check every connection on your grid and make sure that it doesn’t “fight” with another one. That way, you should never experience these problems.
Rigid body early deactivation and fixing
In order to save the precious CPU time, we decided to early detect and deactivate stationary grids more aggressively and give Havok stronger leads to not simulate these.
As you can see on following profiler dump, just by not simulating stationary rigid bodies that are fixed to either voxel or another station, we can gain massive performance improvements.
(click to zoom the image)
Yellow: Active
Red: Detected stationary
Blue: Force-fixed static
CoM based thrust
I believe that one of the things regular players will really appreciate is CoM-corrected thrust. Before, the attached subgrids would create so called “subgrid drag” which was annoying in space…
... and things-breaking in gravity.
After:
Sub-grid damage
Damage handling caused by subgrids, for example impact damage, was adjusted in a way that it will be ignored between subgrids of the same physical group.
We will trade a little bit of realism for user experience. Nice creations will no longer get destroyed by accident subgrid impact and it will allow users to make even more immersive creations.
This does not apply on damage caused by ship to ship impacts. Only physically connected grids get this resistance.
Displaced sub-grids
Under high angular velocities, subgrids were displacing or entirely disconnecting due to high forces acting upon the construction. This was also fixed in this iteration.
Before state
After
Always have safety fuse
When everything fails and the worst is about to happen from some unexpected reasons, it's always good to have safety fuse. That's why we implemented safety detach on all "mechanical connection blocks" (That means Rotors, Pistons, Wheels for now). This will protect users from experiencing all those unexpected situations, when subgrid gets insane speed when corrected after being displaced from its intended position and killing everything alive in its way and/or damaging it's own sub-grids, once and for all.
Satellite in following video is example of so called "Jiggling structure". When safety detach is correctly configured, it will end up "only" with some broken blocks and some subgrids flying away, instead of possessed grid, flying out of control.
Grid deformations
Crashing ship to the planet were causing split parts of the grid falling through the terrain to the center of the planet. This was happening also in collisions with other types of physical objects, although in smaller scale. The root cause was that creating or changing shape in physics also discards all the contact points, which means that for the next simulation frame grid can phase through other entities, until it regains the contact points again. Given the deformations were performed each frame, the grid was for most of the time without contact points, thus phasing through other grids. We have added reintegration step after each change of physics shape.
We have also tweaked all the deformations carefully according to the original release of Space Engineers.
No more ship-eating planets!
Miscellaneous
Here comes some examples of long occurring bugs that were solved along during the process.
Piston and Merge block combo was reported by users over and over again.
It was fixed and behaves correctly now.
"Sacrificial Offering for Almighty Lord CLANG" is one of those creations made just to stress-test Space Engineers. Some players may be angry that we fixed it (Well, mostly, phantom forces are still there)
Before state
After
There was interesting bug in pistons.
Center/extending part was just broken from physics perspective. It was usually just missing or would fly away after first contact. Astronauts or even ships were able to fly through.
And that’s it, for this iteration. For all those who made it this far, this is how that beautiful creature from first case study looks and behaves now, after all the improvements made in this iteration.
Updated: please note that Round 2 of the General AI Challenge, AI Race Avoidance, will now be launched in February 2018. We have pushed the launch date back as we recently started working with some exciting new partners and will need more time to finish the specifications of the round. Find out more here: https://www.general-ai-challenge.org/ai-race
The race for general artificial intelligence is rapidly evolving and at GoodAI we believe it is vital that the issue of safety is brought to the top of the agenda.
I am very excited to announce the work of the AI Roadmap Institute, partner organization of GoodAI, which has begun interdisciplinary workshops to help visualize different scenarios of the future with general artificial intelligence.
How can we avoid general AI research becoming a race between researchers, developers and companies, where safety gets neglected in favor of faster deployment of powerful, but unsafe general AI?
How can we safeguard against bad use of general AI?
AI safety research needs to be promoted beyond the boundaries of the small AI safety community and tackled interdisciplinarily.
Roadmaps can be used to compare possible futures and outline mitigation strategies for negative futures.
There needs to be active cooperation between safety experts and industry leaders to avoid negative scenarios.
General AI Challenge
This post is the beginning of something much bigger! In November 2017 we will launch Round 2 of the General AI Challenge, where participants will search for solutions to ensure that competition among stakeholders does not lead to negligence when it comes to safety.
We will also be running another workshop in October after the AI and Society Symposium in Tokyo.
We hope that the workshop and the next round of the Challenge will open up wider discussions to lots of different questions including:
How to incentivise AGI race winner to obey original agreements and/or share AGI with others?
We understand that cooperation is important in moving forward safely. However, what if other actors do not understand its importance, or refuse to cooperate? How can we guarantee a safe future if there are unknown non-cooperators?
All these points are relevant to internal team dynamics as well. We need to invent robust mechanisms for cooperation between: individual team members, teams, companies, corporations and governments. Looking at the problems across different scales, the pain points are similar.
What levels of transparency is optimal and how do we demonstrate transparency?
How do we stop the first developers of AGI becoming a target?
With regards to the AI weapons race, is a ban on autonomous weapons a good idea? What if our enemies don’t follow the ban?
And more
The Challenge will attempt to solve these problems via citizen science and help to promote the issue of safety in AI to a wider audience.
So stay tuned and prepare to get involved in the new round of the General AI Challenge!
Personal bio: Marek Rosa is the CEO and CTO of GoodAI, a general artificial intelligence R&D company, and the CEO and founder of Keen Software House, an independent game development studio best known for their best-seller Space Engineers
(2mil+ copies sold). Both companies are based in Prague, Czech
Republic. Marek has been interested in artificial intelligence since
childhood. Marek started his career as a programmer but later
transitioned to a leadership role. After the success of the Keen
Software House titles, Marek was able to personally fund GoodAI, his new
general AI research company building human-level artificial
intelligence, with $10mil. GoodAI started in January 2014 and has grown
to an international team of 20 researchers.
