Can anyone point me in the right direction on a design pattern that would work well here or advice about pitfalls to avoid?
I have a top down 2D semi-newtonian physics game (think Escape Velocity or Asteroids), but with a more complicated simulation for the various ship and station components/weapons/armor (think Battletech/Mechwarrior).
My long term goals consist of:
- Turn based combat [Alpha]
- The ability issue movement and combat orders and see the predicted actions of the ship [Alpha]
- Dozens of playable ships
- Swapable weapons, equipment, and armor [HELP]
- Location based damage [Alpha]
- A single player campaign
- Appropriately challenging AI ship behaviors
- A save system that let’s you save mid mission [HELP]
I successfully planned and built rough alphas of the predictive order, turn based combat, and location based damage systems. I’m stuck on how to move forward with the ships, components, and saving. Any advice would be appreciated.
That’s a vague question but i think there’s bigger problem here - you planned too much
See it’s not bad to create large games, but you don’t know everything about them from the start, thing as simple as weather or temperature outside can make you change your decisions, and that’s just the beginning
Of course i could just tell you how you can make all of these things but i’m afraid it won’t help you much because in the end you might find them boring or useless for your game, on the other hand they might actually be more important, it’s just guessing game
What i can do tho is give you some advice on how you can make workflow easier with project this big and it’s just 3 steps:
- Set a vague long term goal of what you want, something you have now:
- random ideas land here
- outline of your game is also there
- theme/feelings too
- simple predictions of how much resources and time you can put into this game as well as team or maybe some general info
- something like your current version but little bit more expanded
- Choose a thing you can expand from into this entire game known as core loop or foundation:
- ask yourself if what you made in point 1 is just dream game or “nice to think, horrible to work on, boring to play” type of thing, then your entire game should be changed or fixed before work because its just waste of time then
- think what is this one thing that is just so simple and makes good game loop, for instance in minecraft it’s just building and breaking blocks, rest was built from this simple thing
- try adding some basic VFX or SFX and rate if it’s fun, it’s max 3 days of work
- overall try and have fun here, you forget plans because they’ll only stop good things to come out of prototypes
- Plan daily to weekly max, never higher:
- You keep track of your current tasks that are visible to you and understandable even if you asked random person on the street
- You check what tasks you’ve finished and what are important to do next, nothing more fancy, you can add 3 color solution where red means not done, yellow next and green done, simple as that, nothing more is required
- You try to give yourself a milestone/objective, it helps with direction but also motivation
- For most time you just follow list, i reccomend doing planning for next day mostly and more vague planning for weekly (milestone can be mechanic, while task can be physical step like changing color of button or making pressing W move player) other than that is not important
Also point 1 is really only usefull if you love boring pointless things that no one might ever see, if you prefer more creative workflow just abbandon point 1 and use points 2-3 to find something that is actually fun, after that expand, it works well for many games e.g minecraft, stardew, vampire survivors ect. - this logic also works post-launch, the entire idea is just constant updates for your game from start
Most important thing to remember is to never fall for planning, you can’t plan everything and as the saying goes “every good battle plan crumbles on the battlefield”
anyways i hope my yapping would help :\ good luck!
For the ships and components, I’d keep the data apart from the nodes. Each weapon, armor plate or engine is a Resource with its stats (mass, heat, damage, which slot it fits), and a ship is a hull Resource plus a list of what’s mounted in each slot. The ship scene reads that list at spawn and builds the sprites and hitboxes from it. Swapping a weapon then means editing a list, not rebuilding a scene, and dozens of ships cost you dozens of .tres files instead of dozens of scenes.
That split helps a lot with saving too. Since it’s turn based, the mission state at the end of a turn is small. Each ship’s position, velocity and heading, the damage per location, ammo, heat and the pending orders. Write a to_dict() for each ship and save the list as JSON or with store_var. Loading is the reverse, rebuild the ships from the dicts and drop them into a fresh scene. Saving the scene tree itself with PackedScene looks tempting and gets painful fast, because it drags in everything the nodes happen to hold.
I did something close to this in a card game. The whole match is a plain dictionary outside the scene tree, and the nodes only draw it. Saving, replays and the server code all got much easier after that. Worth doing early: give every component Resource an id, so old saves keep loading after you rename or rebalance a weapon.