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!



Google PlayGames + Google Analytics

For the past few days, I’ve been facing a frustrating issue;
Google PlayGames and Google Analytics are working against each other in Unity3d. I can’t get both working at the same time.

The Issue

Google Analytics has the priority, in an effort to record more data on the player gameplay.
Google PlayGames would be a really neat addition to add in leaderboards and achievements for the test players, since they quickly add low-dev-effort gameplay value, even in smaller games.

Both work by themselves, without an issue. I got a Unity Package ready for both to implement and use directly. But if I use one, I cannot use the other.

The problem is quite simple. Google Analytics uses a library called google-play-services_lib. This library contains a .jar file, which contains a variety of plugin files that are required for Google services.

Google PlayGames figured implementing the whole jar file creates a too big footprint, which I really agree with. But to fix it, they simply delete the library and replace it with .aar files, which are the files contained within the .jar file (Maybe not exactly the same, but the same plugins, yes). But guess who needs that whole library to function… Right, Google Analytics.

Possible Solutions

One solution that came to mind is to have GooglePlayGames use the whole library instead. But this doesn’t seem to work. There is no real error, but GooglePlayGames refuses to authenticate.

The second solution that came to mind is to have GoogleAnalytics use the .aar files instead of the library. But to accomplish this, I need to know what .aar files GoogleAnalytics requires before I can add them. I don’t know this yet, but if I find out, I could theoretically solve the issue.

The third solution is to use both the library and the .aar files. However, if both are included in Unity, it throws a building error of failing to re-package resources. This means that there are conflicting files, and thát means that there are plugins within the library that are also included in the .aar files. You can’t have two of the same things, in different formats, trying to compile.

To solve this, the idea is to manually remove certain files from the .jar library that are already included in the .aar files. However, to do this, I need to know exactly what files to remove from the .jar library, and I don’t know this yet. If I find out, it could theoretically solve the issue as well.

What’s next?

So without really knowing in full what files I need to remove and throw around, I can’t solve this issue. I’ve decided to, for now, drop it and return to it later. In the meantime, I hope the following issue reports might help in my quest:

Until then; away with GooglePlayGames. I’ll continue working on other matters.

The first of which: analyze my large generic modular code base to figure out what the internal dependencies are, and figure out if I could possibly sell these modules on the Unity Asset Store to get a little income, feedback and help out other devs a bit.

PlayStore Preperations

The past couple of days, I’ve been experimenting with the more (to me) difficult matters of app development. Getting an app on the PlayStore and incorporating third party plugins.
I succesfully got a Test App running on the Google PlayStore, as well as three working plugins. PlayGames Services for leaderboards and achievements, Google Analytics for recording gameplay events andPollfish for including surveys into my apps.
By adding leaderboards andachievements to my prototypes, which in itself is not much effort, adds quite some gameplay value for testers to play the games.
By adding gameplay event tracking, I can see exactly at what stage players win or lose the game, or how many enemies they’ve blown apart, or how many times they’ve jumped up in a specific level. Really useful data for balancing.
By adding surveys into my apps, I can offer players to complete one and reward them with in-app content. As a developer, I get funds for each completed survey, and it’s not pushed into the players faces. My original goal with the survey plugin, however, was to gather feedback on the apps using surveys. This proved to be impossible, so Pollfish (and all other monetization) has to wait until I have an actual full-scale project in development.
I have an infuriating problem, however. Google Analytics requires a library to function, but Google PlayGames REMOVES this library automatically! This causes Google Analytics to no longer operate on Android. Difficult, but I’ll find some kind of work-around eventually.
All of this eventually leads to the features I need as a developer to properly let people test, and enjoy, the variety of prototypes I’ll publish on the PlayStore. Hopefully leading to more detailed feedback, and eventually a better playful experience for everyone.


Today marks a slight reboot of my company’s work. For the past weeks, well over 2 months time, I’ve spent almost all my time on external work, getting hired for an assignment to work together on creating a game for Manus VR. It was an experience I needed, but it was also an incredibly hefty reminder why I’m here, and why I’ve started this little company.
I won’t, and actually can’t just dive straight back into game development just yet. I need to figure out for myself what it is that I really want to accomplish with DuskLight Studios. I’ve been thinking about it for a long time now, and it will always be something that will evolve as time goes. The core of it I’m pretty sure of.
What I want to do, with my life, with this little business, is to create.
Creating playful experiences for others and myself to enjoy. Whether it be exploring something on your own or playing together, either with or against each other. Whether on mobile, PC or anything else. I’ve always loved creating something interactive and I’ve loved seeing people run through it, letting me know what they think, what they feel, what’s good and what can be better. I’ve done this since I was a kid, and it’s exactly that which I want to spend my time doing.
To start with, I’m still going to develop for mobile devices. I know the market is oversaturated, but I feel this type of touch based interaction is what I want to create for first.
To get the game to whoever wants to play it, I’m going to drop the manual emailing list and move over to the Google PlayStore. Kind of like a public pre-alpha for mobile games, and I hope a lot of them. To get feedback, I’m going to drop the google forms I used, and I’m including something directly into all prototype apps. With that process streamlined, it’s my hope I can provide everyone with something to try out and gather the data I need to improve the games and my way of thinking on the development of these games.
Create, show, improve both the games and me. I guess it’s exactly what I’ve always done, and what I’ll always love doing. Let’s use that to reach something great.


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!

DuskLight Blog

The DuskLight Blog has finally been opened up and is all set to go. With mostly everything I’ve been working on, it took awhile to get to this point. There’s a lot more to figure out in theme, tools and style than I initially expected.

But now it’s here, and I’m quite glad it is. Simply put, this blog will be dedicated to the game development of DuskLight Studios. I’ll look back on every prototype iteration, reusable technology development, game jams and more, and write a bit about each of them.

This also marks the start of the DuskLight Studios website, which is still a work in progress. More will be added as soon as I learn how to properly work with WordPress.

Hopefully I’ll manage to capture your interest, whether you’re a fellow game developer or just curious about the prototypes and games in development.