In this week’s devlog: learn how your new ships will take damage along their flight trajectory, and try to decipher Martin’s development rantings.
The work on the ship building feature continued this week. I finished the implementation of the blueprint design form. It now supports all shield types and has a small performance section showing some of the most interesting ship parameters. I recorded a short video of me clicking through the new options:
A ship’s hull will take damage over time depending on where and how much you use the ship. There are four types of damage sources:
- Micrometeoroids: On STL flights between planets the ship will get hit by micrometeoroids. Not all systems will have the same density of micrometeorites. Specialized Whipple shields will reduce damage that result from such impacts.
- Heat: Entering a planet’s atmosphere puts enormous stresses on a ship’s hull in the form of heat. Heat shields can reduce the resulting damage.
- Gravity: Gravitational forces weaken the internal structure of a ship, a stability support system will help mitigate this.
- Radiation: The harsh radiation of a sun, especially when close by, weakens the ship’s hull. Radiation plating will shield the internal systems from effects of the radiation.
It is not necessary for a ship to have all types of shields, it really depends on where the ship is being put to use. Depending on the use case it might make sense to use more advanced hull plates, as these provide a general damage reduction.
Right now I’m splitting my time between two modes, the first one being fully focused on Ignition. Whenever Michi finds an open question in the design docs or something freshly implemented is ready for testing, that’ll be my top priority for the time being.
The second part is more open and about the future of the game. I’m refining some older documents of improvements ideas, such as the one centered around politics (including some much desired features like governor accounting and reporting), but also taking a look at the bigger picture of what could be next in general. So there’s lots of note collecting and brainstorming going on right now. As usual, we will let you know as soon as things become more concrete.
Last week I played around with Facebook retargeting ads that allowed us to reach out to those that had already clicked on our ads before. This helps reinforce our game in their minds, and if they were intrigued before but either a) didn’t have time or b) were just curious, they now have another opportunity to take a second look. Unfortunately our ad tracker allocated many of these “second time observers” into the older ads section, meaning it will be difficult to see exactly how successful the retargeting ad performed. I will have to take a closer look to see, but according to my Facebook contact, we should be in the retargeting stage now. I see many of you current players are also posting on our ads along with new interested potential players. Thank you for your input and helping them understand what the game is actually is and not just “Eve Clone” as some like to comment.
Apart from Facebook, I’m hoping YouTube ads will be ready quite soon once music is finalized and then the final touches are in place. It will be interesting to see how people react different towards YouTube ads as compared to Facebook. I also have another YouTube influencer in the pipeline and I hope can show everyone towards the end of the month as it will coincide with Ignition. There will be some other announcements made this month so keep your eyes open for info dropping on social media and in the PrUn newsletter.
I know a lot of people in the PrUn community are interested in software development in one way or another, so this quick update is for you: As stated recently, I am currently working on an overhaul of several core backend systems. I’d rather skip this work in favor of more gameplay programming, but it has to be done for reasons yet to be revealed. I also mentioned that some of these systems are quite old, dating back all the way to the year 2007 when we started to commercialize our other game, AirlineSim. After all those years of development, and confronted with the resulting codebase, I can say with a pretty high degree of certainty: The primary enemy of good and stable software is shared mutable state! Not only in distributed systems, but in general. The very moment a variable can be touched from more than one place in your codebase, you are bound to be surprised by the fact 10 years later. Take my word for it. And with that: Back to an endless stream of surprises!