Steam Update

I've been working pretty hard to make Shores of Hazeron totally solo playable, in preparation for a Steam release. A huge amount of work was needed to stitch everything together.

This was one of those great house keeping opportunities, from a coding perspective. It was a chance to unify some code under a common interface, code that was getting duplicated on the client side and on the server side. That work flushed out a couple of bugs.

The first wave of changes is complete. All game functions are ready for solo use. A fair bit of testing is needed.

I started building my first solo city. With a little agent-level help along the way, the city could be launching spacecraft by the end of today.

The bug I am currently chasing causes a new avatar to sometimes start in orbit, suffocating to death. It happens a lot in the solo play version. I ended the day on Friday with the bug in hand. The cause of the bug was a surprise, not at all what I expected. The bug will be fixed before I continue building my city.

I am tentatively planning for a Dec 1 release date of the Steam version. That seems very achievable, at this point.

Server Crash

The master server crashed during the weekend, which broke the server grid. It is back up again.

Server software was not updated. Changes have been made that require a coordinated release of a new client with the server. I am not quite ready for that yet.

I didn't have these problems before but since a week or so, ships constantly blow up when approaching a planet or when landing at an airport. I give a mission order to the AI captain, like "orbit over city" and when we get close to the planet it's KABOOM! Ship destroyed. Also happens a lot when landing at an airport. It's always with an AI at the helm. Maybe they approach too fast or something.

The ships we fly cost a lot of resources. It's frustrating to say the least. I would be very grateful if this was fixed. Otherwise I may as well just stop playing cause it's a real game killer.

I love the core feeling of Shores of Hazeron.


I just love that feeling of being on a moon, with my custom-made space ship hovering in the distance, looking at the beautiful planets slowly roll in the sky, and knowing that each little bright dot I see is a complete system with its own wonders, and all within my grasp - and who knows what I'll find there?


Unfortunately, that feeling comes at a high cost.


For years now, new updates have brought time and again more complexity to the game - very often creating more barriers for new players to overcome, new players which are critical to the financial survival of this game, particularly as it will soon go on Steam.


I tried to get some friends into the game throughout the years. Many didn't mind the poor graphics - but the fact that it was absolutely unintuitive and full of lag or bugs with overly-complex gameplay made them all run away. Myself included, only coming back every now and then for nostalgia's sake - like many here, it seems.


And yet I don't think that having hundreds, if not thousands of dedicated players for this game would be so hard. I can see SoH's population easily increasing a hundred fold, and it's revenue even more.


It's just a matter of designing the game for its audience.


But for that, the mindset for the development of this game needs to switch to "What does the game's audience want? What needs to be done to attract, retain and monetize more users?"



Designing a game is just like any other business - you've got the understand some core concepts and have a specific frame of mind to be successful. This is roughly broken down into:



-Understanding the customer's needs (what do my users want?)

-Creating a product that meets those needs (in this case, a sandbox space MMO)

-Communicating to the customer that the product meets those needs


I believe the core reason behind SoH's poor performance over the years is due to the development team being unaware of these concepts.



As a well-known example, we've seen a completely new overhaul of the ship and building designer. While the idea behind it makes sense (allowing for greater creative freedom and customization), it has, in my opinion, created a barrier to the majority of potential users, who would be disengage with the game as they see this new feature too complex and doesn't meet their needs (effort to entertainment ratio). This has been widely expressed since its implementation.



On the other end, we have had some great improvements to increase usability and entertainment - for instance, having "under construction" airports automatically fetch the required resources to allow its construction, hence greatly reducing the tedious micro-management required to build colonies - which I personally love and has single-handedly rekindled my interest in the game.



In fact, were it not for this, I would not be here, and would be playing another game as I write this.



My suggestion is to strategize profoundly on what Shores of Hazeron is about - its purpose and identity.



An online game's purpose is most often to provide entertainment to a niche of players. How does SoH aim to do so? What features does it need to have to create that entertainment?


We've all made loads of suggestions about how we'd want the game to be improved - the features we think would be good to implement. But unless the mentality towards the development of the game changes, then none of this will work in the long-term.


The launch to Steam is coming soon, and Haxus has expressed that it's either going to work or the project will be abandoned. Like many other players, I often rage about SoH's complexity and features. But I always come back for a reason. It's one of the games with the most potential to bring me lots of pleasure. I'd hate to see that potential unrealized.

Last few days everything my crews were doing was often VERY laggy. Not laggy on my side, but their. Examples:
- Crewman can't stop at path nodes - they simply walk further for one-two seconds, then turns back, and then again walks back one-two seconds longer after he reaches node. Result: they simply can't move around ship, walks into walls, can't get to their stations.
- Crewmen stops ships with delay after reaching waypoints. Today I've observed ship landing. It nosedived into ground, and continued for few seconds with engines on, before realizing it's too far, then leveled, ascended, tried to land with very delayed reactions, which was both funny and sad to watch.
No idea how they are handled by engine, but it looks like due to some bug there's some (way too big) delay between checks for their waypoints maybe?

Starships blowing up as soon as they get close to/land on a planet (AI crew-manned) . Doesn't happen every time, but often enough to be very bothersome.

Hey all,

Since two days I have massive problems with the space crew. Yesterday I lost my spacecraft because the crew thought that it was fun to go up and down with orbiting a planet and suddenly smashing right into it. The spacecraft was recovered afterwards and the new boarded crew was from a different empire (??!), they also couldn't find their way to the bridge. Nothing worked.

On my other alt account I tried to fly my second spacecraft to an airport but it was glitched as hell. Maybe it's time to reboot the server?

It is way too often that new players think that broker shipments cost money to send. If we had a government account like in the old days I guess it could, but as it is right now it is just confusing.
As long as the broker shipment price is only for manual shipping, hide the cost from the shipment creation dialog, it simply isn't necessary information and causes confusion.

Same can be said for the TEU count. It makes no difference and doesn't matter at all for automatic shipping. It is a cute little counter though, but while it has no use outside of manual shipping it just adds to the confusion.
I guess you could add something like a TEU per hour limit per office or something, but I doubt it is really needed as it would just mean more buildings and more separate shipments.

See also: (Bug report) Broker doesn't show Shipment limit

Somewhat related: (Bug report) Selling at broker glitch

PS: Can we also get a confirmation on shipment travel speed? It is unclear if it uses empire's best warp drive technology or if it is always warp 1 or 2c.

being able to jump a planet into another solar system

I was talking in galactic and Doppler effect had said that you should be able to tow a station into warp without a problem.

I have tried 3 times now and lost 3 stations that take a week each to make, all with reports of collision damage anywhere from 600m-1b damage from the station (and vice versa from the station point of view).

Doppler effect suggested I write in the bug reports forum but before I did I tried one more time to tow a station into warp. The last time I had one account caption of the ship so I could respawn it and one caption of the station for the same reason. This attempt resulted in the same collision at warp but when I try to respawn either the station or the ship it says "Sir, this ship is ready to be recovered from stasis in the Void Dimension. You must go to a repair shop in the Void Dimension to recover this ship"

This is getting really annoying waiting a week at a time for both new ship and stations and any help would be great.

It would be cool to have idle animations on ships. Since it still needs to fit into the data budget, I think complexity will be reasonable.



Potential applications:

• Functional Observatories/Orreries
  
• Moving engine parts
  
• Coffee replicator [beam in coffee (startup) -> spinning coffee bubbles (active) -> coffee goes into garbage (deactivating)]
  
• Breathing/beating organs
  
• Deploying animated bridge (eg. Gipsy Danger)
  
• Milling Wind Mill
  

1. Add State gives 4 options
          a. Inactive. A starting, resting, "off" state. If there is no inactive state, the loop will stop on whatever "Active" state is active at the time, and start on "Active 1" when the design spawns. All animations have and start with an "Active 1" state.       b. Startup. Starting the animation will run through these states before entering the loop.       c. Active. The active cycle of states. They show at their "time". "Delays" would add time to the cycle, effectively pausing the timer if they are present. They mean there is a delay before that part shows. All animations start with an "Active 1" state, and it cannot be removed.       d. Deactivating. Turning off the animation will run through these states before resting on "Inactive" once again. Using a time from the loop will be when the loop breaks, and states will be spaced using "delays". Breaking the loop means that, when the trigger to turn off is made, the last loop will run all its states from time 0 to the deactivation time.                i. Deactivating states with different times or 0 delay will cause errors, and shouldn't let you leave this window without sorting them.
2. Powered means that the reactor must be on for the animation to start. Pressing switches or sitting down or otherwise, nothing will happen. If there is no "Powered" or "Event", the animation will always loop from the moment the design spawns.
   
3. Events are triggers that activate the animation. "Switches" and "Proximity" use the same placement function as door switches. Occupied Seats are "Associated" with the animation part.
   
4. Animations are made using a Part -> Make -> Animation function. 
   
5. For the sake of preventing too much abuse, voids, barriers and paths cannot be associated with these states. They are treated like landing gear for collision and volume.
   

• Absolute X degrees
  
• Absolute Y degrees
  
• Absolute Z degrees
  
• Time Interval (frames, or 1/60 seconds), the how frames between updating the angle.
  
• PlaceAxis, select the spot the thing spins around.