• entries
    42
  • comments
    139
  • views
    50989

"Overland" Ship Movement with Random Encounters

Sign in to follow this  

1094 views

Personal Update:


Busy week! We bought bikes for the family and I'm teaching the kiddo how to ride. We had some car trouble where the front wheel well was smoking terribly and we had to get it towed and repaired (leaky pump dropping coolant onto the wheel). And I should be getting to the quarter-round trim soon in order to finish the laminate floor installation. And my free AutoSave Asset finally got published:
https://www.assetstore.unity3d.com/en/#!/content/43605

I'm happy I shared an early version for the Week of Awesome III. Otherwise it would have been far too late. Also, as of the writing of this, the Check Engine light came on in my other vehicle. >.<

Game Update:


This week, I started working on my "overland" movement system. It's called overland because originally I was thinking of a medieval travelling merchant game and I couldn't think of a better name. I may change Overland to Solar or Space. Anyway... I now have planets being randomly positioned, and the player can send his ship around on the map. Currently, you can only choose to go to a planet, but in the future, I'll be letting the player select deep space locations, intercept other ships, etc. As the player moves, there's a random chance that he gets jumped by a pirate scout which triggers the battle scene.



I'm debating on whether or not to go with a more realistic layout of the solar map. Like have a star in the center, and let the planets travel an orbit path very slowly each turn. Or something like I have now where planets, star ports, and other interesting things are just scattered about. My original grand idea was on the more realistic side. Planets orbit the star, moons orbit the planet, space stations orbit any of these. There's definite cool factor there, but a single solar system might have over 200 meaningful places to dock. When I'm planning to allow the player to travel between star systems, it's a little overwhelming. Lately, I've been enjoying some more abstract games with text popups describing different scenarios, so I'm leaning that way. I'm also thinking about going with 2d sprites instead of 3d models.

Next week I plan to focus on learning Unity's UI system. I need better user feedback on the selection of units, and I also want to offer the user choices during their random encounters. Hopeuflly I'll get a simple system in place for that. I also want to work on cleaning up my Game State management and look at different screen transitions.


Unity Gotchas:


Unity does not like how I setup my objects, or i'm just doing it wrong. Case in point, my ship configuration works like this:
I have a ShipParentController that dynamically loads game objects for the Hull (physical/visible/game stats), the GhostModel (for indicating planned movement), and the GameObjectCanvas for the health bar. To spawn a particular ShipConfiguration, you just have to set a ShipConfigurationName and then in Start() it loads everything up and sets some local reference variables to the child objects. No big deal yet... But when I create a random encounter, I generate an enemy ship by picking a ShipConfigurationName and passing the ShipParentController to the BattleSystem. The problem is that the BattleSystem is expecting those child objects to already be loaded but the ShipParentController.Start() hasn't been called yet. I guess I just can't treat the Start() function like a constructor.

I ran into similar issues when I have game objects start out disabled in Unity. Setting a GameObject to Active doesn't run Awake or Start right when you turn it on. Unity has to do an Update cycle first to call these. Then after that, all my child objects are loaded up nice and neat. I was mainly doing this to avoid GetComponent/GetChildComponent() calls in Update code so my performance didn't go to crap. And I prefer to do this dynamic wiring up rather than using the Inspector to wire up my Child objects because when I refactor code by changing the name of a field, it breaks much more cleanly.

I'm an old Object Oriented Programming vet so it's taking some adjusting to shift my mental paradigm over to a Component Entity System. I hacked together some things just so I could "finish" for the week and get things working, but I'm not happy with the current state of the code. I think I'm going to have to move my initialization code into my own function with a flag. Anytime I need to create a new object, I'll have to run the initialization code myself and the function will set a flag to say it's Initialized.

I'm also still a little fuzzy on scene changes. Right now, I don't have separate Scenes. Since I'll have so much data to go from overland to battle and back again. LoadSceneAdditive did not seem like the wise choice. I just have the relevant objects childed to an OverlandScreen and BattleScreen GameObject and I disable/enable when I'm switching scenes. I have a zoomed out orthographic camera for the Overland screen. And a zoomed in, perspective camera for the Battle screen. Both are AudioListeners which is one problem, and the other is that the OverlandScreen and BattleScreen are turning each other on and off. I think I'm going to need a GameStateController for Screen changing, and I'm going to need to separate out my AudioListener to follow around the currently active camera.

Tons to do!
Sign in to follow this  


2 Comments


Recommended Comments

Interesting, you wouldn't be the first person I've heard who does everything with just one Scene.  Does have me tempted to try what you're doing when I get around to doing my 'overland' map.

 

I like your overland map, and agree that slowly rotating planetary bodies are neat to look at, but don't add much to gameplay.

 

I ended up with a stack of states, that ended up each being monobehaviors, so that if they wanted they could do their own Updates.  I disable them during pop/push, and call things like OnEnter / OnLeave to let me cleanup things.  (The bulletcam is a state, and i reset the TimeScale property to 1 when leaving, turn off the ghostmodel, etc)

Share this comment


Link to comment

There would be two cool things from moving planetary bodies. It'd be a little more interesting to look at like you said. And the distance between planets changes as time moves forward. So at first, Mars and Earth might be close together, but after 100 turns, the planets could be on the opposite side of the solar system. This could be more fun, but it could also be less fun depending on the rest of the game play elements. If reliable supply & demand chains were critical to success then it would really suck to have one of your colonies collapse once the food supply migrated away from it. :)

 

That's an interesting way to do State Management. I'll be messing around with that more this week.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now