From The Programming Desk: Resource Clusters

Hey Everyone, Volvary here.

As some of you may remember from the past Dev Updates, I am one of the Developers, Magician, Black Knights (however you like to call us programmers) here on Gears of Eden. I’m here today to give you a view inside the mind of a programmer when developing a solution for a challenging game design component. As we work on GoE, we are constantly iterating through sprints—short cycles where we begin implementing a set of features or mechanics, and navigate through the challenges associated with them.

My most recent programming challenge has involved clusters of resources on our asteroid and the question, “How do you map multiple elements in a small cluster on an uneven terrain?” We have an oblong asteroid with tons of craters, divots, and hills, which creates less that ideal surface conditions to map objects to. While we have resources mapped uniformly over the terrain, the idea for the clustering system was to create random pockets where resources would be more highly concentrated.

In programming, there is, in my modest knowledge, two primary methods of problem solving. The first method involves breaking up the problem into smaller elements until you can see how to do each part clearly. If you can’t see it, it’s still too large. This is the general go-to method. The second method, generally less used due to its risks, is a method where you go step by step, working your way toward your end goal. The risk here is that if you go down the wrong path, you will either take a longer route or will have to backtrack. Tip: Only use this process if the steps required are unclear. This is the path I chose for this particular problem, which I will dissect below in more detail.

After some self-consultation, I quickly decided on a course of action. Was it the best? Maybe not. As I explained above, this method is risky. Is it the only course of action possible? Most definitely not. But here’s what I came up with.

First, I asked myself, “What do we have available already?” After all, why reinvent the wheel, right? We already have a system in place that maps the resources onto the celestial body randomly and uniformly. Okay, that’s very useful. “Can it be expanded to lay our clusters down? Most definitely!” Perfect. That’s part one done.

Once I had that expanded, I could start pushing it in the correct way. “What do I have now compared to what I need?” was my next thought. “I have objects, scattered onto the asteroid surface in a randomized pattern. I need resource nodes, bundled in a relatively tight cluster, scattered around the body.” Getting closer.

The next step was to find a way to map the nodes onto the asteroid’s surface in such a pattern. “I could assign them onto a sphere then snap them directly to the collision point of a ray headed from the chosen point straight to the asteroid core,” I thought. But this thought came with a problem (as things usually do in the first round of coding): the asteroid is not a flat surface. If I mapped my objects onto a sphere/circle on the surface of the asteroid, I ran the risk of making one of them appear under the ground, thus not colliding with anything. This would result in an incorrect node placement.

If you look at our scene, you can actually see the solution I arrived at. The cluster nodes are now pushed up into the sky when laid around the asteroid, in such a way as to make sure their assignment disks have no way to intersect with the ground. That way, I can freely map the objects to a random point inside the area, then send a ray from that point toward the core of the body and drop the node where the line is segmented by the ground.

So, in summary, the steps taken here, for a step by step approach, were as follows:

1. Identify your need. Having as clear of an understanding of the needed result is a must for success with this approach.
2. Identify where you stand before starting. Round up as much knowledge of what is available to you. You might need such knowledge to easily jump through certain hoops down the line.
3. Start with the first part. Start simple and test. One step at a time is better than 2 step forward, 3 step back.
4. Re-evaluate where you stand and correct the aim if necessary.
5. Work on the next part of the required element.
6. Loop through 4 and 5 until you reach the end. Do not be scared to take a step back from the situation or to ask a colleague for a quick code review if the picture becomes too blurry.