Why I (Probably) Won’t Play No Man’s Sky Anymore

September 2nd, 2016

I don’t like writing a bad review. In fact, I don’t like writing reviews. But I just can’t let this go. No Man’s Sky is just broke. It’s a fine idea for a game and it looks pretty good on my PC. It’s even quite fun. But it’s also just wrong. I get the impression that the developers are not people with a high level of attention to detail. Or more accurately, they don’t seem to feel a need to be accurate. I will only list a few things that I find wrong with the game – things like the lack of multi-player interactions has been beat to death as a topic. These are in order of most serious to least:

Space Physics

In space where there is no drag on your ship, or insignificant drag, using the engine continuously will result in continuous acceleration. But not in this game. There is a speed limit in space for the standard thrusters and it makes absolutely no sense. It’s like physics for 3-year-olds. In fact, the whole flying style of the game lacks depth and precision and feels like a 90’s arcade flying game. This is the one problem with the game that pisses me off every single time I play it. If I hold down the thrust button, the damn ship should just keep accelerating.

I can ignore orbital physics, uniform gravity everywhere, and stuff like that. But dang, that speed limit sucks.

Weird Goods Pricing

Ok, this is one I just noticed because I tried to do some trading. If you look at the purchase price of something like a plasma coil, it might says that it is 22,000 units and is 5% above average. But if you then look at the sell price, it might show 1,000 units and is 2% below average. WTF is that average? There is no such thing as an average sell price that is different from an average buy price; there is just the price! I bought something at 4% above average and sold it at 100% above average and I took an enormous loss. WTF? I had to actually look at the prices and write them ON A PIEC E OF PAPER. A [modern] game should not make you write on a piece of paper – it should assume that you would do that and do it for you. Maybe if this were a Nancy Drew game with puzzles, paper would be important. But really, the average should be the average and not some nonsense number that is anything but helpful. This is now the main reason that I hate the game.

On a side note, I turned 200,000 into 1,000,000 in an hour by just waiting for ships selling some sort of night crystals for 35,000 each that I could sell back to the galactic store for 55,000. I wanted to buy and sell other stuff but I got tired of looking at my sheet of paper to find out if a price was good or not. Galactic average my ass!

Can’t Stop!

And another space physics complaint I have? It’s that in space, I cannot stop my ship. The game seems to think that I want to move forward at 40U, or whatever number it was, or move backwards (-40U). But there is no f-ing way to go zero. So we are back to this being a dumb kids game that does not attempt to have any realism at all. The speed limit might be necessary because time is needed to load new data for rendered objects as they get closer to you. But not letting me get to zero is just dumb. How do the developers decide on something like that…

“Hey Sean, should we let the players use the thrusters to stop their ship in space?”

”No, why would they do that? And it would make it far too easy to sit and mine those big ‘roids anyhow.”

”But Sean, if they can’t stop, isn’t that weird? There’s no reason for it. It seems arbitrary and certainly doesn’t work like a real spaceship would work.”

”Yep. But then none of this is supposed to be a space simulation. Why even try to get closer to that kind of game when we have that multiplayer thing to worry about.”

”Uh, were we supposed to be working on a multi-player version of this game. Uh oh.”

Space Distances

The developers decided that it would be best to make all of the planets clearly visible from any point in space near them. But it’s weird. It’s also kind of cool because it gives the game a Sci-Fi look, but it’s weird. I would have pushed the planets further apart to give a better sense of how much emptiness is out there is space.

Galaxy Map

The galaxy map is useless to do anything but pick a star system closer to the center of the galaxy. I would love to have been able to revisit a previous system with my bigger better ship, but the game seems to not want that. In fact, the galaxy map works in the most strange way possible for a PC with a mouse. I suspect that making a better map is hard to do on a console with a controller in hand.

Clouds and Rocks

I dislike that space is filled with rocks and clouds. I would have preferred emptiness and blackness. Again, it’s just not a good space simulation at all. I can see why they did the whole colored space and rocks thing, but it’s just a tiny bit weird. I would have liked a black dark lonely game where landing was a refreshing change to the blackness of space.

Boring Planets

I don’t mind that I may find a desert planet or that I might find a planet of caves and spires. But it is a little weird that an entire planet will have the exact same features across its entire surface. Having flat desert regions for large areas and then mountains and lakes, or anything that varies from one region to another, would have been great. It would have made it cool to explore a planet. The only reason to not stay in one spot is to seek out various alien installations. There doesn’t really need to be scenery because having it all the same is like having no scenery at all.


So I get that the game has some very difficult-to-build features. But the game systems outside of the large galaxy of systems, is pretty pedestrian feeling. It feels far too much like a kids game with all of the functions dumbed down. Here’s a list of things I would do if I were developing such a game (something that I probably can’t do):

Move the planets further apart. Heck, make them tiny dots and require a short burst of FTL to get from one to the other. The HUD can mark the system planets to keep them from being confused with distant starts. Did you know that at the speed of light, it would take about 35 minutes to get from Earth to Jupiter!
Fix the engines so if I keep the thrust on, I keep accelerating. I suspect that the speed limit of the thrusters is to give the terrain time to be generated. But still, there’s got to be a way to make this a bit more realistic.
Let the damn ship stop in space. Make the thrust control more like real thrust control (with computer aided stabilization of course).
Make space black and empty.
Show the actual average PRICE of goods so that I can see that someone will buy my item at 100% above average and actually make a profit, not a loss.
Let me the user pick what shows on the HUD. Turn asteroid marking on or off (including showing asteroid belts if the belt is too far off to see individual asteroids). Show details about stuff if I want it, not just details about things that are pointed to. Get rid of the lines to the space station. Let me mark places on a planet so I can go back to them after selling off some expensive minerals that I found in just that one spot.
Make ships with more storage actually look bigger than ships with less storage. I think that the current inventory system is fine since I have nothing to compare it to. but I’d like to see a ship with 2x the space for goods be 2x the size.

That’s just a bit of what I would change. I really just want to have the game fixed so I can stop in space and to have trading values that make any sense on any Earthly accounting system. Again, how can the average selling price not be the same as the average buying price?

New Linkage Beta

August 31st, 2016

I have a new Beta test version of the Linkage program. This version has an okay link triangle handling feature as well as a few connector alignment tweaks. it also has a way of selecting links and connectors by name or identifier. It’s still all being tested by me, but if anyone want to try it, you are welcome to do so.

Get It here!

A few other recent posts describe these new features so I won’t elaborate on them in this post.

“Roundabout” Game Design

August 11th, 2016

I don’t think that I posted anything about designing a board game. My daughter and I have been playing lots of board games recently, maybe to be able to play together and not with a screen in front of us, and then one day I started creating a board for a game.


Our game doesn’t really have a name. I just picked “Roundabout” for this post because the game is travel themed and, believe it or not, it’s round!

This game is loosely based on Tokaido. I took some ideas that I thought were really great and threw out some even better ideas (because Tokaido is a great game and stealing is bad) and came up with this.

Design Process

I started out wanting a round board. There is something cool in having a circle with little circles around it. At least for me, I find it aesthetically pleasing. So I figured out about how many spaces I needed around the board, 36 being a good starting number since each is 10 degrees from the next. Then  draw a bunch  of circles. I didn’t keep a good pictures of that first game board, just this piece of a screen shot:


The first version of the game just used some initials and geometric shapes for the spaces on the board. I used old business cards to write symbols on them. We played it for a few turns before thinking it would work and that it also sucked without proper cards.

We recently made the new graphics (the first picture in this post) and printed cards on card-stock with front and back images to match the spaces. Here’s some samples of our graphics taken from the instructions:


We are now trying to refine the rules. There are two things that are giving us trouble:

  1. How does the game end?
  2. How does the player move onto and off of a side path?

We have been using the Start space as the End space on the board. As soon as a player reaches that space, the game is over.

For the side paths, we tried moving out on a side path and then back in, stopping on each space going in both directions. We also tried to go from the end space on the side path right back to the next space along the other side path or along the main path. That was hard to follow while playing. Even going out and back was hard to follow. The latest idea is to jump from the end space back to the space on the main path, which will always be empty. Then no active space gets repeated while taking a side path.

We’ll have a few other players give us some feedback this weekend. I look forward to reporting what they think and also posting about how the game design progresses.

Link Triangles Working, Sort Of…

July 29th, 2016

I have a first draft working for the link triangle simulation. Like I said recently, I am opting to support the most common type of link triangle configuration and ignoring all others. Here are videos of the two variations of supported link triangles:

What I did on this first try is to simulate the triangles, which are identical in configuration and only different is where the fixed connector is versus the moving connector, is to determine the length from the fixed connector to the other end of the link triangle.

Where things go wrong is after that. After that length is determined, the code just moves the moveable end of the link triangle by rotating that link that it attaches to. Then the simulation continues from there and on another pass, the links within the triangle can be simulated normally. Well, except that the end of the link triangle often oscillates and the information about the link triangle is gone at that point. this causes some weird artifacts in the movement as you can see in at least one of the videos.

The way to fix this is to somehow remember the angle of link connections at one of the connectors within the link triangle and use this for simulating the triangle once its length is determined. Or maybe I just need to figure out which of the two links, one being an actuator, needs to be processed first is the next step of simulation. I’m not sure yet.

But it’s close to working! Yeeha!

Just going to kludge the link triangle thing for now…

July 27th, 2016

I decided that I’m going to make an alternate link-to-link simulation function that accepts a link triangle as one of the links. It won’t work for both to start with because, well, no one makes mechanisms like that.

The fact is, there’s only really one type of link triangle situation that people might use. They are probably not going to stick an actuator on a link in a way that the end of the actuator slides on that same link as the other end is mounted. They are probably also not going to connect two link triangles with actuators together at the end of two actuators.

Here’s what I want to make work:


And here are some things that still won’t work after this change:


imageimageAlthough I do want to come up with a more flexible simulation algorithm that handles all of these, right now I will add some code to handle the one special case of a single link triangle connected to something that is not a link triangle. We’ll see how it goes.

New Linkage 3.3.5 Available

July 14th, 2016

I got my new code singing certificate and I fixed a few minor bugs. Super short dimension lines were becoming infinite due to the space calculated for the arrow heads. There was also a problem with gear and link rotation angles that went wrong after about two rotations of a gear fastened to a link.

So go get a new version if you need it. The Linkage page, available form the right column of any of my blog pages, has the links to the XP and newer Direct2D variations of the software.

Working with Link Triangles

July 14th, 2016

I have a plan. It’s not a very good plan, but it is a plan.

imageThe mechanism above presents a problem that I have written about a few times in the past. The EGJ triangle is what I call a “link triangle.” It is a set of links that when simulated, act like one larger link. Although I added some code to do some simple link triangle simulation, it is not at all what I need. That code was more of an experiment to see if I could detect a link triangle and then use it in a simulation. But it could not handle the actuator seen here.

The reason that the existing link triangle simulation code can’t handle the actuator, and is far too simple anyhow, is because I used a modified function to replace a regular link with some triangle link info while looking for links to rotate to meet each other. There was no way to actually simulate the actuator when creating the link triangle and no way to handle sliding connections. Damn those sliding connections – they made all of the simulation code 10x more complicated that it was before adding the sliding connector feature.


Above is another mechanism that has the same link triangle sort of problem. This one is a little more interesting because it only has two links in the “triangle” and one of them is an actuator. The simulation is easy to do on paper but is a very special case in the software.


Now it’s just getting weird. Again, this is easy to simulate on paper but is yet another weird special case. The link triangle is formed by connectors CGE but the shape of the link triangle is defined by the actuator that is not a leg of the triangle.

So first things first. The only way to simulate this sort of thing is to figure out the relative positions of the various connectors based on the actuator length. Remember, what the mechanism looks like before it starts is not what it looks like at any step in the simulation. I will need find link triangles, and that non-triangle variation with the actuator and slider, and simulate the parts as if most of the connectors are at a fixed location. then I can create a temporary link of the new shape and use that in the normal simulation code to see how it interacts with the rest of the mechanism. I would need to save the temporary link and find other link triangles before doing any full mechanism simulation because two link triangles might be connected to each other.


But first, I need to change the entire data structure of links and connectors. Look at the simple mechanism above and then at the XML in the data file:

    <program zoom="1.000000" xoffset="-10" yoffset="0" scalefactor="1.000000" units="Millimeters"/>
     <connector id="0" selected="true" layer="16" x="-156.734694" y="54.666667" anchor="true" color="16711680"/>
    <connector id="1" selected="true" layer="16" x="-117.551020" y="166.000000" color="12632064"/>
    <connector id="2" selected="true" layer="16" x="-78.367347" y="54.666667" anchor="true" color="32768"/>
    <Link id="0" selected="true" layer="16" linesize="1" color="16711680">
        <connector id="0"/>
         <connector id="1"/>
    <Link id="1" selected="true" layer="16" linesize="1" color="12632064">
        <connector id="2"/>
        <connector id="1"/>
        <connector id="2"/>
        <connector id="1"/>
        <connector id="0"/>
        <link id="1"/>
         <link id="0"/>

Notice that in the data file above, and in the internal data structures for the mechanism, there is a single connector for the place where the two links are connected. This was a tough design decision to make and it turned out to be a bad one. What it does is it lets the user select and move a connector with very little code. But it also makes it impossible to treat links 1 and 2 completely separately. If the code needed to move connector B to make link 1 longer, like if it is an actuator, but not change the location of connector B for link 2, it is impossible; there is only one connector B. This makes it impossible to create a temporary link in place of a link and then simulate it using different connector locations.

The plan as of a few minutes ago was to change the entire data structure so that each link keeps track of the connectors as separate objects in the code. There would be two objects for connector B, one belonging to each link. They would then point to each other. I think that these per-link connectors will not be connectors like I use now, they will just be some intermediate data structures that keep track of where they connect and also keep track of the existing connector data object. Ugh, too many objects in the data structure for the mechanism gets a bit unwieldy (if that the right word). It makes it hard to maintain the code when there’s so much data to manage and use during any operation.

So to put it another way, the connection points of a link will have their own positions along with a reference (C++ pointer) to the regular connector object. The regular connector objects will no long have a position used during simulation, just during drawing of the mechanism. I can then create a temporary link from a link triangle and have it connect to other links without worrying about altering the shapes or sizes of those other links.

Now to actually change the code. That’s going to take more than a few hours I suspect.

Linkage in a Virtual Machine on Mac

July 6th, 2016

FYI, I was able to easily install Windows 10 running in a virtual machine on my MacBook Pro. I got a trial copy of Parallels and it handled the Windows 10 installation seamlessly. I already had a Windows 10 product key so it was free (so far). And the best part is that the Linkage program, after a little extra startup delay, works fine.

As a side note; I just sent my verification data to Symantec and they should get me my new code signing certificate any day now. I am anxious to publish an update to the Linkage program because of a few small bugs that I fixed recently.

No Linkage For a Short Time

June 26th, 2016

Somehow, I missed that my code signing certificate was about to expire. And Symantec needs me to do the whole notarized identification thing to renew it. This means that I can’t produce a new Linkage program with a bug fix that I wanted to distribute, at least not for a week.

The bug is not really a big problem. It turns out that if a dimension line is short enough, making room for the arrow heads causes the line length to get screwed up and the line draws itself right of the page and maybe to infinity. Just ignore it if you see it.

I also discovered that sometimes drawing elements that are not part of the mechanism should be drawn without dimensions. I got a mechanism file from a user and saw that a bunch of extra junk shows up when drawing layer elements are present and complicated. I don’t know why they needed all of the drawing elements, maybe to use for aligning the mechanism, but the auto-dimensions look crappy in this case.

So the list of ideas gets bigger:

Allow auto-dimensions to be disabled for specific elements.
Allow auto-dimensions to be enabled/disabled by layer.
Allow drawing layer elements to be including in the parts list.

Art of Time Video

June 11th, 2016

I captured a few stills from this video because the work is just amazing. Credit for the stills goes to the people who produced the video; Seiko. The comment on the video says “The meticulous attention to detail and artistic beauty of the time.”