Say I have a small source of high quality metal, together lots of low quality metal. I want to make sure the small, high quality source is used for important things like shipbuilding and weapons, while bullion, plantpots, picture frames and so on can use any old junk. 

It would be a practical and easy quality-of-life improvement to forbid certain processes to fetch input resources above a certain Q.

As far as we know, decay is a necessary evil to prevent server resources from going to waste on cities that aren't being used. But since the change to the Land claim system, decay of cities has felt really confusing.
I think we would all love it if decay didn't have to be a thing at all, since exploring and encountering other civilizations is one of the awesome things in this game. So without the full understanding about the reasons for decay, lets discuss alternatives.

If the number of cities is what is actually costing the most server issues, then I really don't know what can be done, aside from upgrading the server hardware. But storing information shouldn't be as big an issue if it isn't actually being used.

Assuming that it is the amount of computation it takes to handle the large amount of cities and units in them, maybe it would be possible to make the cities go dormant when their founder/owner/claimer hasn't been online for 7-30 days.

All manufacturing could either stop completely, slow down a lot, or be more selective; such as only working essential jobs.

Something similar to the old neglect mechanic could make the military units despawn and otherwise leave the military bases nonfunctional. And leaving the worlds defenseless against attacks in the process.

See also: (Idea thread) Automatically Add To Land

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 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.

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?

being able to jump a planet into another solar system

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.
  

The mating animation is horrible and ridiculous.

I suggested Hazeron to a group of people that had never hear, they immediately saw the "ages 17+" tag and read the "sex" warning. They dismissed the game after that, since their computer is in the living room where their whole family is.

Basic solution is to just remove the mating pose and animation. Instead have a more cartoony version of it, fade the screen to black of the avatars involved and then have the "bonk" message of success after stamina drain or whatever. Onlookers wouldn't need to even know that it happened at all, or they can just see a small heart sprite above the creatures similar to what you see in Minecraft when breeding animals.

There is nothing wrong with procreation apart from that. Though it is nice to keep procreation mostly PG-13, even if you want the game to be for an somewhat mature audience.

If this was done, the worst offender of "ages 17+" tag could be removed and make the game a lot more acceptable.

The update for reference: (Update thread) 2019-10-31 Animal Poses

Exchange Cache

The building and spacecraft blueprint exchanges download a large and growing blob of data every time a client logs in. That data is now cached on the client.

Universe Change

The arrangement of galaxies in the Hazeron universe was changed so that the war and peace dimensions each contain ten galaxies, arranged in a similar way in each dimension. Refer to the update universe map here.

https://www.hazeron.com/wiki/index.php/Universe

Items Block Doors

Items no longer block doors open. This usually caused trouble, especially when turbo lift doors were blocked open.

Startup Galaxy

The default startup galaxy for new players is now Veil of Targoss. A red message appears when Shores of Hazeron is selected, to warn about the brutal life that awaits players there.

I am stoked to be modeling the first ship for my new empire using Blender. Is there a thread or tutorial I may have missed that covers the rest of the learning curve/wall beyond this point?