Orbit Mechanics

OrbitSketch.jpgMonths ago, around the start of DuskLight Studios, I wanted to create a game about flying around planets in orbit with each other. A game about exploration through space, adjusting your own orbit to move from planet to planet. I severely underestimated the difficulty of this.

Elliptic path


My first experiment in Unity included a single planet with a moon in orbit. The moon’s velocity was affected by the planet’s gravity, which varies in strength depending on distance to the planet. I couldn’t figure out the mathmatical formule to calculate the gravity’s pull, trying out faulty code I found online. It did result in an orbit, but it wasn’t right.

When a ship orbits a planet (and only that planet), it should be locked in an elliptic path. As long as it doesn’t accelerate in any direction, the ship will end up in the exact same position as it started at and eternally follow the exact same path. The first experiment did not achieve this, and I moved on to other projects to prevent wasting too much time.

Gravitational pull

A couple of weeks ago, I gave it another shot. I found a quite interesting link providing me with several different solutions to orbital mechanics in code.

A simple orbit

The Euler integration was easy to implement into a new Unity project. It started off in script; using the transform’s position, a velocity vector, and the gravitational pull to mimick the results. It worked, allowing me to iterate and improve upon the code.

Gravitational pull (g) equals to planet mass (m) multiplied by the square of distance between planet and ship (d^2): g = m * d^2

The function (present within the planet’s script) I currently use to calculate the gravitational acceleration:

public Vector3 GetGravity(Vector3 attract) {
        Vector2 delta = transform.position – attract;
        Return delta.normalized * ((mass * gravityConstant) / delta.sqrMagnitude);

Vector3 attract is the position at which the orbitting object is located.

Note that the calculations occur with Vector2 instead of Vector3, and that the square magnitude is used instead of the regular magnitude, both saving performance. Calculation of the square root of any number is much more CPU intensive than multiplications. Same goes for the Mathf.Pow(x) function.

Unity Physics

Achieving orbit is great and all, but I needed the code to work with the built-in Unity physics. That way I could include realistic collisions with planets and asteroids. I quickly ran into a couple of weird problems, though.

Note that all calculations should be run within the FixedUpdate, so it runs in sync with the Unity physics simulation.

I had to remove my own velocity vector and start using the Rigidbody2D’s velocity instead. Normally you’d use the function body.AddForce(gravity) to accelerate the ship, which I did at first. This resulted in a steady but weird orbit that didn’t follow the elliptic path as it should, leading me to believe that using forces for gravity is a bad idea. There was no way to really know how much velocity would be gained if I added a certain amount of force. Add to this that gravity pulls all objects equally, regardless of object mass, it proved I needed a different solution.

Instead of forces, I decided to affect the velocity directly. (body is the Rigidbody2D)

gravity = planet.GetGravity(transform.position);
velocity = body.velocity;
velocity += gravity * Time.fixedDeltaTime;
body.velocity = velocity;

Defying laws of physics

This resulted in an almost perfect elliptic orbit, but the ellipse was a little off. It kept decreasing or increasing in size in a pattern. The issue here was the centre of mass of the rigidbody.

The centre of mass is automatically calculated by Unity, using the size and locations of the 2D colliders attached to the rigidbody. Changing the centre of mass to Vector3.zero solved the problem, but I also changed the gravity position to the centre of mass. If I ever change the centre of mass again, it should still work.

gravity = planet.GetGravity(body.worldCentreOfMass);


Now I can look happily at my near perfect elliptic orbit, watching my ship bump into asteroids and settle in a new orbit, occasionally crash landing on the planet itself and coming to a halt.

HexFlow Prototype Released

The second prototype, a strategic puzzle game where you change the flow of power, has finally been released as open alpha on the Google PlayStore!

The past two months have been troubled by long periods of low energy. After coming back from a two week vacation, I lost my drive, my motivation in game development somehow. During this time I was stuck figuring out what I really wanted to do with all of this, and only few hours in the weeks were spent on the development of this prototype.

Eventually I realized a couple of things. My main motivation to create a game has always been that I want to play it myself. An idea is formed in my mind, and I get hyped up to play a game like that, but it doesn’t exist yet. So I create it. Ofcourse, I do take into account the playability of the game for other people, as well. Seeing other people experience my creations is one of the best moments of the whole game development process.

Last week, work was picked up again proper and I finally finished the HexFlow prototype for all to play.

HexFlow Prototype

Download Link

In HexFlow, you take turns in rotating a tile on the playing field. By rotating, the paths change, allowing power to flow into different directions. Power Cores act as sources of power, and are important to gain control over the match.

The game is a competitive strategic puzzle game. Logical thought, patience and preperation can lead you to victory. Play against either the computer player, or test your skills against other, real players.











Dash Development


Dash Development

Dash started out with a simple idea; Powerful, impactful smashing things across the screen, trying to become better and better in the game to improve your previous highscore.

Using this idea, the prototype was developed within 2.5 weeks time, using the Unity2D engine and utilizing our modular DuskLight Framework.

This is our first prototype to be succesfully released onto the PlayStore for testing, and as such, a lot of time was spent on research towards this goal. Equipped with the knowledge of this project, we hope the next prototype will see a shorter total development cycle.

If you want to give it a try, head on to the download page here!


The main mechanics required to complete the prototype were as follows:

  • Player physics and input
  • Shockwaves
  • Destructable Orbs
  • Orb spawning patterns
  • Randomized morphing environment
  • Scoring and combo multiplier
  • Infector spawning, flight, and orb infection
  • Player death and end-game.

For each mechanic, the core functionality, visuals, sounds and game flow were required to be completed. Prototyping is not only developing the basic mechanics, but also capturing the atmosphere and emotion we’re trying to convey.

All code has been developed from scratch, though using many modules from the DuskLight Framework to ease development of these features.


Using the Google PlayStore open alpha testing functionality, we published Dash and shared the link to as many people as we could. In preperation for this, we created an in-app feedback reporting tool that links to a Google Form, where we collect most of the feedback.

On certain social media pages, we received feedback directly instead of via the feedback form. Despite adding a bit of extra work in collecting it all, we’re happy to see so much responses. All feedback has been collected and compiled into a clear overview.

Responses showed that most people really enjoy our game, and some even absolutely loved it. Without a doubt, the core mechanic of this game has a future, but there is a lot of features to improve, add and polish.


This prototype is likely to become a full project, and released product on the PlayStore one day. There is much to be done before that is a possibility, however, since the following features are important to create diversity and replayability:

  • Different ‘Zones’, each zone containing a different vibe, challenges and rewards.
  • More settings for input, sound and visual preferences.
  • An immersive tutorial, displayed at the start of a session. (toggleable in settings)
  • Improved visuals and sound
  • Unlockables cosmetics, lore and gameplay variations.

It will be awhile before all of this becomes a reality, so stay in touch with our social media pages if you’re interested in the future of this project!

It’s unknown what form of monetization this game will eventually contain (Got to make a living, too), but it is leaning towards an in-app-purchases game. Pay to win is terrible, though, we’ll be careful with balancing every available purchase.

And ofcourse, we are driven by your feedback. So let us hear your thoughts!


First Prototype

Over the past five weeks, I’ve been extremely busy figuring out the process on how to develop a prototype android game from start to finish. From idea, to concept, to development, to launch preperations and actual launching.

Suffice to say, I’ve learned and created so much over the past few days. For every step that I take, I record it. Everything I develop for something that every project has to walk through, I create in such a way I can use it again in the next project. Because of this, I’ve put together quite a powerful framework within Unity with which to create 2D mobile games.

I now also know every step that I need to take, from start to finish, to create and release an Android game, including all the features that I need to make it work the way I need.

Looking back, in the past 5 weeks, I accomplished the following:

  • Created an animated splashscreen.
  • Added Pollfish API and registration.
  • Added Google Analytics API and registration.
  • Added Google PlayGames API and registration.
  • Improved all API’s into something matching my workflow.
  • Uploaded TestApp to Google PlayStore, testing all API’s and the uploading / Alpha Testing processes involved.
  • A ton of small changes to my framework, massively improving workflow.
  • Completely redesigned the Input Module for my games. Mouse and Touch input treated as the same, interactable objects gained input priority.
  • Created a reusable user interface, which contains easily modified parts:
    • How to Play.
    • Feedback reporting tool.
    • Achievements, Leaderboards, Analytics buttons.
    • Social Media and website links.
    • Start, pause and game over UI.
    • Feature: instantly implementable into my framework.
    • http://i.imgur.com/MfPlnGI.gif
  • Fixing up, adding leaderboards and achievements and uploading a Global Game Jam game, Space Cake Delivery. Good test run of the API implementations.
  • Started development on Dash Prototype project.
  • Implementing my framework, improving it more, adding in and setting up all the UI, API and Modules it needs to work.
  • Created player input, enemies, spawning enemies in patterns, morphing environments, dynamic hazards, scoring & combo, game restart.
  • Created Google Forms for collecting feedback.
  • Added IAP functionality to framework, and donations button to UI
  • Added 29 Achievements, 1 leaderboard and a lot of Analytics Logs to Dash Prototype.
  • Created icons and store graphics.
  • Visited the Dutch Game Garden Networklunch.
  • Updating my ‘communications’ documents.
  • Listing all the steps I’ve taken into one big checklist document.

And with all of that, the Dash Prototype is finally ready for Open Alpha Testing.

The prototype is complete, the preparations are done, all dashboards are set. All I have to do now is testrun it one more time, to see if the testing process works.

Dash is an energetic, high powered highscore game where you play within a microscopic, alien world, trying to survive with an increasingly difficult number of dangers. See further down below for some animated .gifs of the gameplay.

What would be next, then, is to spread the news on the alpha testing. To bring the game to as many people as possible, to let everyone in the whole world play it, for free, so I know what’s good and bad about it. With that information, I can hopefully create something that this prototype wouldn’t even compare to.

Keep your eyes open, once the test is done, I’ll put out a release date for the open alpha testing!




At DuskLight Studios, mobile game prototypes are being developed before an actual project is started proper. There are so many ideas and so many mechanics to play and create with, it’s impossible to know what works, and what fails, without trying them out.

Prototyping stands at the core of the company’s plan. Experimentation with different mechanics and sensations, brought to and tried out on the mobile platform. Even when a full project is in development, prototyping will remain a important part.


Idea List.png

At the time of writing, there are a total of 24 gameplay ideas. Not all are great, some are already abandoned. Each idea is ranked by two estimations. An estimation on their ‘value’ (how much impact it delivers, or how fun it is to play) and an estimation on their ‘scale’ (how long does it take to develop with current available resources).

The ideas with the highest estimated (value : scale) ratio are generally the first to be prototyped. Smaller scale games take priority, though, since in my opinion taking on gigantic projects would be unwise for a one-developer team.

Prototype Art

NodeGuardian Small.png

I’m a game developer mainly in the form of programming. Luckily, I can draw and put together somewhat of a matching style, but I’m no artist.

Because of my limited ability to create art assets, and the generally long time it takes to create art, I aim for an ‘abstract’ style for the prototypes. Something easy to change and adjust to proper art when it’s turned into a proper project. I feared the abstract style would be a problem, but it’s been working great for every concept so far.


Every prototype is the same in the most basic sense. There is a lot of functionality that all prototypes end up using. For ease of development, improved performance, persistence, sound, time, etc. Little bits of tech I’ve developed to more easily use the Unity engine.

It’s not rare for prototypes to have matching gameplay mechanics as well, such as the spawning of enemies or world segments of a scrolling view. For that, modules such as a parallax background, wave spawning or even a complete 2D weapons system are very useful to save precious development time.


Development of prototypes is great, as well as the development of tech modules to support the prototypes. But it’s useless if I don’t get some proper results on which prototype works, and which does not. To get to know that, I need people to test them.

In the first week, I collected a list of volunteers that wanted to help me test my games. From this list (~35 people), about 4 to 8 actually test and respond. The feedback is useful, but far from conclusive.

Far more useful testing results come from face-to-face playthroughs. Directly observing the actions of the player and his or her responses deliver far better results. With family, friends and strangers at networking events, I test my games to see what they think of them, often with concrete information on what can be improved or added.

My next step in testing is to open up the Google Developer Console, and use it’s Alpha test functionality to send the games directly to everyone involved. I will combine this with an in-app feedback report functionality for each prototype, so people can easily tell me what they think.

And that’s what I do with DuskLight Studios. Develop mobile game prototypes and test them!