Friday, November 17, 2017

Space Engineers: Major Physics Overhaul


SUMMARY:
  • Massive physics overhaul
  • Pistons, rotors, landing gears and more
  • 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
CEO, Founder Keen Software House
CEO, CTO, Founder GoodAI


For more news:

Space Engineers: www.SpaceEngineersGame.com
Medieval Engineers: www.MedievalEngineers.com
General AI Challenge: www.General-AI-Challenge.org
AI Roadmap Institute: www.RoadmapInstitute.org
GoodAI: www.GoodAI.com
Keen Software House: www.keenswh.com


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 (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.

 
Graceful at all speeds, don’t you think?

---
Best regards,
Martin Pavlicek

Thursday, November 2, 2017

AI Race Avoidance

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.

We have recently held a workshop on AI race avoidance.You can find the outcomes of it in our new blog post here: Avoiding The Precipice: Race Avoidance in the Development of Artificial General Intelligence. I have also summarised the main points below.

Article Summary
  • 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!

Thank you for reading!

Marek Rosa
CEO and Founder of Keen Software House
CEO, CTO of GoodAI
:-)


For more news:
General AI Challenge: www.general-ai-challenge.org
AI Roadmap Institute: www.roadmapinstitute.org
GoodAI: www.goodai.com
Space Engineers: www.spaceengineersgame.com
Medieval Engineers: www.medievalengineers.com


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.

Sunday, October 1, 2017

Parasitic computing

I just stumbled upon a new concept: Parasitic computing

It grabbed my attention because some days ago we were discussing similar issue in our team – the fact that the gradual meta-learning architecture may invent experts that act like parasites on other experts, etc.

Parasitic computing is programming technique where a program in normal authorized interactions with another program manages to get the other program to perform computations of a complex nature. It is, in a sense, a security exploit in that the program implementing the parasitic computing has no authority to consume resources made available to the other program.
It was first proposed by Albert-Laszlo Barabasi, Vincent W. Freeh, Hawoong Jeong & Jay B. Brockman from University of Notre Dame, Indiana, USA, in 2001.
The example given by the original paper was two computers communicating over the Internet, under disguise of a standard communications session. The first computer is attempting to solve a large and extremely difficult 3-SAT problem; it has decomposed the original 3-SAT problem in a considerable number of smaller problems. Each of these smaller problems is then encoded as a relation between a checksum and a packet such that whether the checksum is accurate or not is also the answer to that smaller problem. The packet/checksum is then sent to another computer. This computer will, as part of receiving the packet and deciding whether it is valid and well-formed, create a checksum of the packet and see whether it is identical to the provided checksum. If the checksum is invalid, it will then request a new packet from the original computer. The original computer now knows the answer to that smaller problem based on the second computer's response, and can transmit a fresh packet embodying a different sub-problem. Eventually, all the sub-problems will be answered and the final answer easily calculated.
And then there's parasitic computing implemented as a virtual machine :-)
This Diploma Thesis of the University of Applied Sciences in Bern (Switzerland) does extend that concept into a fully programmable virtual machine that is capable of solving any known problem in classic computer science.
http://www.szene.ch/parasit/index.html
Why am I writing about this? Because I think that these are good examples of behavior that may/will emerge in every recursively self-improving AI architecture.
It's important to anticipate these issues and prepare for them - e.g. by implementing immune system experts, or creating learning tasks (curriculum) that teach some kind of immune system reactions, etc.

What is an expert? A very loose definition would be: expert is a program (policy, skill, heuristic, etc) that solves some general or specialized problem in external or internal environment. General AI architecture would be a network of these experts.

Thank you for reading!


Marek Rosa

CEO, Founder, Keen Software House
CEO, Founder, GoodAI

For more news:


General AI Challenge: www.general-ai-challenge.org

AI Roadmap Institute: www.roadmapinstitute.org
GoodAI: www.goodai.com
Space Engineers: www.spaceengineersgame.com
Medieval Engineers: www.medievalengineers.com

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.

Saturday, September 30, 2017

Results and Evaluation for Gradual Learning Round of the General AI Challenge


SUMMARY:
  • We have finished the first round of the General AI Challenge focusing on gradual learning
  • There were no winners but we awarded $7000 of prizes to reward the top four efforts
  • We will continue the gradual learning round in 2018 and are launching Round 2: Race Avoidance in November 2017


We have reached a big milestone having completed the first Gradual Learning round of the General AI Challenge. Firstly, I would like to say a huge thank you to everyone involved in the round: all participants, our jury and advisors, our 15 main partners (see below) and everyone who helped.

GoodAI launched the General AI Challenge in February 2017, with the aim of using citizen science to tackle crucial research problems in human-level AI development.

The first round of the Challenge asked participants to create AI agents capable of gradual learning (building new knowledge on top of previously learned skills and reapplying existing skills to learn how to solve new problems more efficiently), one of the keys to solving general AI.

We had over 500 people from 56 countries registered for the 1st round of the General AI Challenge from February till August 2017, and we received 13 submissions competing for the main, quantitative prize (“best gradually learning AI agent”) and for the qualitative (“best idea”) prize.

To compete for quantitative prize, AI agents had to pass an evaluation curriculum of tasks, that we designed specifically to test the gradual learning capability. Since none of the submitted AI agents were able to solve the entire evaluation curriculum, and the jury concluded that more work is required to demonstrate future potential of submitted designs, the jury chose no winner.

However, to encourage further work on gradual learning and to reward the participants for their considerable efforts, we decided to split the 2nd prize in “best idea” category ($7000) among the four finalists. Four shortlisted solutions were closely comparable, but the finalist who received most points from the judges was also awarded a GEFORCE GTX 1080 GPU - the special prize from our Challenge partner NVIDIA.


I was particularly impressed at the diversity on display and the determination of our participants. The top four awarded finalists, as chosen by our jury, are:


Dan Barry: A former NASA astronaut and a veteran of three space flights, four spacewalks and two trips to the International Space Station. He retired from NASA in 2005 and started his own company, Denbar Robotics, that focuses on smart robots and artificial intelligence interfaces, concentrating on assistive devices for people with disabilities. In 2011 he co-founded Fellow Robots, a company that provides robots for retail settings. He has ten patents, over 50 articles in scientific journals and has served on two scientific journal editorial boards.


Andrés del Campo Novales: AI hobbyist passionate about the idea of a general AI. He is a Software Engineer with 15 years of professional experience. He has been working for Microsoft in Denmark for the last 11 years in business applications. Andrés studied computer science & engineering at Córdoba and Málaga. He created a chatbot that could learn conversation patterns, context and numerical systems.
Andreas Ipp: Andreas Ipp works as a research fellow at the TU Wien where he obtained his habilitation in the field of theoretical physics. His current research is focused on simulating the production of the quark-gluon plasma in heavy ion colliders like the LHC in CERN. After obtaining his PhD, he had postdoctoral fellow positions in Italy and at the Max Planck Institute in Germany. Since his return to TU Wien, he is involved in teaching activities, including lecturing on quantum electrodynamics. Apart from his scientific achievements, he founded the choir of the TU Wien a few years ago, which successfully participates at international choir competitions.

Susumu Katayama: Assistant professor at the University of Miyazaki in Japan, inventor of the MagicHaskeller inductive functional programming system. He has been working on inductive functional programming (IFP) for fifteen years. His research goal is to realize a human-level AI based on IFP.








It’s great to see our participants coming from such different walks of life and I wonder if Dan Barry has every played our Space Engineers! :-)

I was also inspired by the passion of our participants. Andrés del Campo Novales only learnt about the competition a couple of months ago. However, this didn’t stop him putting in over 150 hours during the weekend and in the evenings.

Next steps


We have listened to the feedback from participants, and eagerness of our finalists to continue their work and improve on the quantitative challenge. Therefore, we have decided we will continue the gradual learning round of the Challenge in 2018.

In the meantime you can get involved in the second round of the General AI Challenge which will launch in November 2017 and will focus on AI Race avoidance. With the increasing rate of progress made in the AI field, developers might race towards being the first to achieve general AI and might neglect either safety procedures or agreements with other stakeholders for the sake of first mover advantage. Participants will be asked to come up with a proposal of what practical steps can be taken to avoid the pitfalls of the AI race and advance the development of beneficial general AI.

Thank you for reading!

Marek Rosa
CEO, Founder, Keen Software House
CEO, CTO, GoodAI
:-)

For more news:
General AI Challenge: www.general-ai-challenge.org
AI Roadmap Institute: www.roadmapinstitute.org
Space Engineers: www.spaceengineersgame.com
Medieval Engineers: www.medievalengineers.com

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.









Monday, September 25, 2017

Space Engineers Skins Sale (Concluded)


SUMMARY:
  • 6 skin sets available for purchase
  • Sale starts September 25, only open for a few days
  • Store option has been requested by players
  • Rules of screenshot competition are not changing


This sale has now ended. Thank you for your feedback and we hope
you enjoy your newly acquired skins!

Hello Engineers!

Today we’re excited to announce a special limited-time sale for some select skins you’ve been asking for! Starting on Monday, September 25, you will be able to purchase six skin sets. This sale will only last for a few days, so make sure to check it out on Steam Item Store (this sale has now ended) before it’s too late!

The skins up for sale are:
  • Graffiti
  • Police
  • Prisoner
  • Skeleton
  • Digi Camo
  • Lava

We’ve had lots of requests from players asking for a way to simply purchase skins instead of spending time chasing down containers to find those elusive badger boots. In light of the ongoing screenshot competition we’ve decided to not sell all the skin sets, instead we’ve selected some of the more popular mid-tier sets for you to purchase.


If you’re only missing one or two pieces from a suit, you can buy those separately, but if you buy all eight pieces at once, you get a special bundle discount!

If you have questions about the skin system, see my blog post about skins for more info. We addressed some of the most common questions and concerns in this post when we released skins.

The rules for the screenshot competition haven’t changed, and users who have purchased skins won’t be judged any differently. We are judging the screenshots based on style, composition, and creativity, not which skin you bought. So keep sending in screenshots whether you bought your skin from the workshop or earned it the hard way. All of us at Keen love seeing the amazing creativity coming from our community, so keep it coming!


Space Engineers is still in development. Everything in the game is subject to change.

Thank you for reading!

Marek Rosa
CEO and Founder of Keen Software House
CEO, CTO of GoodAI

For more news:
Space Engineers: www.spaceengineersgame.com
Medieval Engineers: www.medievalengineers.com
General AI Challenge: www.general-ai-challenge.org
AI Roadmap Institute: www.roadmapinstitute.org
GoodAI: www.goodai.com
Keen Software House: www.keenswh.com

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.