Or do you just jump on in there wily nilly…
Or maybe start with a proof of concept / core game mechanic then work out from there.
I’ve been reading up / trying to understand different forms of architecture and tech design, so interested to hear everyone’s ‘way of doing things’. (Esp from the ‘pros’/formally qualified/unity people too!)
I usualy write down my idea.
Then i make some code drawings (pros/cons, easy/hard, cool/ugly, etc…).
Make a structure of the program 
Attributes of the avatar, of the creatures, NPCs, dialogs…
But always i start with (i think is the base):
After that. the order doesnt matter much:
5. Inventory (pickup items, equip, drop, destroy, etc…) - could be only logicaly, not an actual UI
Test, Test, Test, Test again all the steps
6. Item/Object modifiers to your player
Test, Test, Test, Test again all the steps
7. Creatures - interaction, properties, AI
Test, Test, Test, Test again all the steps
8. Creation of the UI (HP, Inventory, Skills, etc…)
Test, Test, Test, Test again all the steps
9. Visual modifiers. Weapon in hand, Armor on the player, etc…
Test, Test, Test, Test again all the steps
10. Adding models to your avatar, creatures - animations (1 by one with tests after each model entry)
Test, Test, Test, Test again all the steps
11. Player customization - like avatar creation (can be last step)
Test, Test, Test, Test again all the steps
LAST ONE!
12. Bling - blings like: effects, sounds (this is the most tideous part, in my case )
Test, Test, Test, Test again all the steps
FINALLY. Network (if you need one)
Test, Test, Test, Test again all the steps
Test, Test, Test, Test again all the steps
Test, Test, Test, Test again all the steps
Test, Test, Test, Test again all the steps
Test, Test, Test, Test again all the steps
Test, Test, Test, Test again all the steps
ALPHA version…
Maybe i’ve lost a point or two, but the idea is to write the first 4 steps and then you choose with what you like to continue
What about early set up of managers like for save game, iCloud, Game Control, etc… My manager methods (just basic structure are usually my #1
Could work, but from experience i know that savings and tutorials are made at the end of the project, when we know exactly what we want to save and the data needed for a load to work.
Tutorials are mostly made when we know exactly all the mechanics of the game… to show to the player all the game can do.
Yeah, i forgot about game controls… so i introduce also the MENU at the end. This MENU should be introduced at the end stage of the game because we need to make fast tests, debuging and entering into the game by menu will slowes you.
iCloud, i don’t know nothing… but if you have to buy something to save your game there, buy that space when you have the save system.
Not sure I’d ever leave networking to the end, in my experience networking requires a completely different approach to large parts of the code compared to a single player game.
Leaving it until the end could result in a lot of extra work being required.
That would be me; I enjoy the adventure.
You’re right, but if you are alone… network must be at the end. In team is easy, because you take a person to do the network part and the rest of the team makes the funny part
I am alone (from a programming perspective), and that’s more reason to implement networking code as I go along in my opinion.
However, that’s just what I’ve found the easiest approach, which works best with the way I do things.
Depends if I know what I’m doing or not. If I know what I’m doing, I’ll plan out the design ahead of time. Usually in my head though, often while I’m driving to/from work (I commute 3+ hours a day). Then I’ll implement it, test, test, test, and fix what doesn’t work.
Eventually I’ll add on more to it later as I expand the functionality, and when it reaches some breaking point I will refactor.
If I don’t know what I’m doing, like I’m trying to do something I’ve never done before, I’ll be researching online and writing as I go. When I get something functional I’ll either throw it all away and redesign, or if I’m happy with what I ad hoc created I’ll run with it.
Networking and save need to be considered near the beginning or not at all. They affect too many other design decisions.
Like adibichea, I always start on paper. Many people follow Steve McConnell’s approach in Code Complete, by blocking out methods and typing their implementations using plain language pseudocode. Then they turn the pseudocode into comments and write the code below it. But this still strikes me as one step away from cowboy coding since you’re still writing one line at a time instead of blocking out entire systems on paper first.
If it’s something new, I’ll hack up a throwaway prototype. This gives me insight into how to implement it properly, and it highlights potential challenges. The key is throwaway prototype. More likely, I’ll write several isolated islands of prototypes for various systems and features. The Asset Store is a great way to fill in missing pieces to be able to prototype quickly. For example, if I’m working on a detection system for enemy AI, I might pull in a character controller from the Asset Store to allow the player to move around. Since the purpose of the prototype is the enemy AI, this keeps me from wasting time writing player movement code that isn’t relevant to the enemy AI system. Even if I don’t use that Asset Store character controller in my actual implementation, it allows me to put together the prototype faster.
At this point I should have a good idea of what each isolated module entails. Then I write as many tests as I can think of before writing actual implementation code. They not only confirm that the implementation works as intended, but the process of designing tests forces you to develop clear requirements. It may seem like a chore up front, but it’s a lot more fun (not to mention faster) than chasing down bugs or doing endless refactoring after the fact. (Refactoring is a fact of life, but the less you can do, the more you can move on to other things.)
Going willy nilly at it until i get a MVP prototype up and running, at that stage take a step back and reassess -both the design itself and the code structure.
About saving and networking, i’m trying to understand why is better to do it in early stages of the project.
Now about my style…
I make always saving/loading at the end of the game, because i already have the Items, Inventory, Creatures, etc. Could do it before bling-bling / visual stuff, but doesnt matter.
About network (i don’t speak about lag, packet loss… we assume that we have a good network script):
So, basically all the info that will be transfered over network will have a separate script for easy coding.
If i’m wrong please correct me, maybe i’m doing this like CoCoNutti said “wily nilly”.
With me, there are stages
First, we design the Basic game mechanics on paper and try to define the MVP. It really helps to try and write down stuff, maybe do some scetches (which is really hard on me because I have no discernible dawing Talent), and write down in words that main interacting parts, goals, and actors.
If there are any non-standard items (the first time we used a VR rig, the first time we used gestures, new mechanics or Interface) we build a tech demo / proof of concept.
Then we design the main data elements that need persisting. If the game uses Networking (which we currently avoid like the plague because Unity’s networking just isn’t anywhere near fit for production) we do this as well (if you don’t you’ll get screwed when you try to add networking after you have implemented your main game)
Next is the Interface: how to represent the player in the game world. This can be a basic point-and-click affair, but make sure that your UI metaphor always works before you start implementing. There’s nothing worse than an action that breaks the metaphor (e.g. ‘space’ is always ‘jump’ unless you are in a room, where it is ‘search’).
We then try and cut the game into groups along the use case: starting point, configuration, player selection, scenario selection (tutorials, campaigns, Scenarios), level selection – and how to integrate this into the experience: will the turorial be part of the game and integrated into the story or menu driven? If you are designing a VR game this frequently requires dedicated rooms instead of flat menus.
Then we’ll build a pre MVP using prototypes (cubes, capsules, spheres and Quads) to see if it can be done. Key (placed) elements we flesh out early if we can, and successively add the real models Remember to resist the temptation to add Features during this phase, as it only distracts from the core. Start vigorous testing instead.
If it works, well then complete the MVP and test. Publishing a buggy MVP will kill your Reputation. People can live with “ugly” graphics. They will not, however, stand for a frustrating (buggy) experience.
I hope you don’t mind me asking but, could you make this a tutorial? This kind of teaching is sorely missing here. 
Guerilla Games did a great talk on prototypes at GDC 2018:
On the project side, Valentin Simonov’s How to set up a smart and efficient development pipeline in Unity is excellent. I can’t link it enough.
The only thing it doesn’t cover is test-driven development. Fortunately, there’s an article for that, too: Test-Driven Development in Unity.
This is all great info. I forgot to mention that before I write any code I too do a ‘Proof of Concept’ first - that is a demo of the core game mechanic. From this I can get a good idea if it’s ‘fun’ or not or has potential and worth full development. Then I write out a design doc (game and tech) which is evergreen - I keep it updated through dev stage and never sway from it unless something is obviously amiss etc. It’s the code / tech planning aspect that has always alluded me though, so I’ll look into Steve McConnell’s Code Complete, thanks.
If anyone interested found the PDF of the above here.
Thanks for the info.
After taking a look at all this, it appears to me that this is for professionals not for silly amateurs like me. For now, I’m working on my first game; it’s all messy, I don’t really know what I want to do but I’m having fun and I have all the time in the world to make it. The only thing that bothers me is that I could get bored one day and give up but so far, so good, so I’m just going to keep up my way.
Actually, what saddens me is, when I mention that I’m making a game, people immediately ask me if I’m going to sell it and make a living out of it; it’s still the same as it has always been, people cannot understand that money is not everything in the world. Making money is absolutely not my goal, I just want to create something of my own, that’s it.
So true! It’s like if every time you bake a cake someone asks if you’re going to sell it to a bakery, or if you’re painting a watercolor in a park someone asks what your plans are to sell it to a big New York gallery. One of these days people will let games be art for art’s sake.
As for the article and video, no need to go all-in on everything they advise. I’ll usually tuck a few interesting points away in the back of my mind in case a lightbulb goes off later and I realize how I can use the advice. And in the meantime I just plow ahead. Otherwise a certain kind of paralysis sets in if you try to do everything exactly “right” from the start.
Just remember too that you CAN overplan. I have worked in the industry with large studios and I can tell you one truth. 100% (esp American publishers ) and some game devs have wayyyyy too many meetings and tools - so much so the actual work done (ie make that game or app) is slow and inefficient.