Hmm… your question(s) is veeeery open-ended.
Game design is a blend between so many things (UX, art, sound, story) - and people relate with games in many ways (player types and all that…) – I wouldn’t really feel confident in giving you advice on game design. While there are certain templates to making a game (such as genre e.g. RTS or FPS) and science on how to improve usability, games is, for me, about creating an experience for people and expressing yourself – to evoke emotion. To say that you should design something a certain way would just feel wrong.
However, I’ll give you some things to think about when designing a game. The answer is up to you.
Game design considerations
As I just said, games is about creating an experience and expressing yourself. The question is:
Question #1: What experience do you want to create?
You know that you want to make RTS games, but why? What about RTS games excites you; and what do you think would be cool/fun/interesting to add to such a game? Perhaps a different way of controlling units (I never liked traditional RTS controls – too fast xD), or a new type of unit: underground units? It’s up to you. The important thing is defining your idea so you have something to work towards; from macro to micro.
To take the underground unit as an example, it will probably be capable of travelling underground. What does this afford the unit in relation to the game? Air invulnerability? Tunnel creation? And why should the player care about having this type of unit; how does it fit into the overall game and what does it contribute to the feeling of playing the game?
Question #2: How many people are you making the game with?
This is not really a design question but from my own experience, the amount of people you have on a project severely dictates what is possible for a game. You may say “well, I can do most things to a good degree” but every skill requires its own headspace; it’s own mindset in order for you to make good decisions and do good work. Orienting your mind to a different headspace takes at least 30-60 minutes for me. Therefore, think about what your core strength is in relation to game creation and cater your game’s design towards work that you (or your team) can manage so you don’t have to break your flow.
If only my past self would listen to this advice. You know what they say --hindsight and all that…
Question #3: What are the minimum requirements for your game to function?
Again, not necessarily a design question but it’s good to know the mandatory features for your game. For an RTS it’s probably:
- A top-down camera
- Units
- A way to select units
- A way to get resources
- …
It’s not my game though. You may have something completely different in mind.
Technical tips
I can try and give you some tips on the technical side of making a game – that part is somewhat objective.
Organize your project
Even a small game can become cumbersome to manage if you intend to finish it. If you leave objects unnamed, files scattered in the same directory, or forget to make comments in your code, it will slow you down.
- Name and group stuff
- Make
Nodes to group similar nodes (if needed)
- Make folders for specific file types (scenes, models, textures, scripts etc.)
- Briefly describe even moderately complex code
Your future self will thank you.
Coupled vs decoupled systems
As a guy “well-versed in programming”, you know how important encapsulation is. For games, it is very important to keep things as separated as possible (from a technical standpoint). The state of a game is under constant change and a sudden null-value that wasn’t accounted for can quickly cause frustration and a sudden hour-long bug hunt due to compounded errors.
Therefore, you should always try to minimize coupling in your overall system. Of course coupled systems can’t be avoided because the different systems need to interact in order for something to happen (e.g. player and enemies). As such, the coupling should be as “weak” as possible; if one of the coupled objects changes or disappears, the system should be able to handle it.
One way of doing this is through callbacks (a.k.a. signals, delegates, actions etc.). In godot, they are called signals (see the Getting Started chapter on Signals) and can be used to make loosely coupled systems.
I’m not too keen on programming patterns; I haven’t really studied all the patterns that exist. However, you can probably do a quick google search on what patterns facilitate loose coupling.
There’s probably stuff that I’m forgetting. My mind never worked that well with vague questions. If you have more specific questions, feel free to ask them here.