You have your game idea running in your head and it’s like a AAA game/movie of how amazing your game idea is.
You start developing the idea and quickly building and adding the pieces to Unity you need to make your game.
Only all of these mechanics problems pop up after you have already made the elements in your game.
You can then get bogged down in game balancing all of the now complex set of moving systems in your game.
So would you be better off writing a quick no graphics simulation of your game before even starting a prototype?
Are there mathematical modelling techniques that could allow a modern game to be ‘simplified’ and it’s systems simulated to give the developer an overview of how the game should be balanced?
The idea being that if a simulation of your game could be run in a fraction of the time it takes to play the game you could run hundreds or thousands of game balancing tests to fine tune your games mechanics before you even start making it.
Or what is the FPS of your FPS/RTS/TD/Game with no graphics?
No. Quickest way would be to open unity and start working on a prototype using basic shapes and relatively little art or even free assets. Engines have frameworks already setup; rendering, physics, ect. That takes time to setup. use what Unity (you are on the Unity forums ya know? lol) to quickly prototype gameplay, not systems.
Let’s say your working on an RTS or FPS and once you have your basic prototype playing you can start adapting the mechanics only you have probably built it as a player controlled system and therefore need to playtests it over and over to help refine the game mechanics/level design.
Your test and adjust cycle:
2 - 30 minutes
Which is fine if you games best mechanics/level balance can be found within tens of iterations a level. You can probably make a game level in a day or a great game level in a few days or a week.
What if you set up your game to be a automatic simulation without graphics so it can run a frame in less than a millisecond then your test and adjust cycle could be run via a search algorithm and be:
1.2 seconds to 18 seconds
So you could cycle and search through 86,400 permutations of your games mechanics a day and probably many multiples of this if you use DOTS, Burst and Jobs* to run multiple game simulations on multiple cores.
*Side benefit you ensure you games mechanics/simulation code is super fast.
My point being if you can search further and faster over the potential permutation landscape of your games mechanics for the highest peak your more likely to find the best in your game.
It’s just trying to applying automation to game development and it doesn’t have to be just a no graphics simulation or player controlled with graphics you could write it so you can run in both modes with a simple global toggle.
Potential Side Benefit: With a no graphics simulation mode built into your game in theory switching to server based multiplayer should be a lot easier.
All my stuff is made with Unity primitives. Just use boxes for the level, capsules for the characters and go. Placeholder graphics (primitives) and grey-boxing are required in most cases as the code will have to deal with physics as well. You don’t save time doing a pre-prototype. That’s just the idea phase and doesn’t tell you anything. It doesn’t save time over using primitives.
I make the entire game like this. Art is designed alongside but deliberately kept separate until code hits alpha, then the two are brought together in a planned fashion.
Maybe but amateurs have to learn a lot of things to get up to speed in game development so no wonder they don’t initially try with just a simulation or primitives approach especially when Unity makes it so easy to drop in models/animation/sound fx/textures and has an asset store full of ready to play stuff you can just drop into your game.
A box and a capsule? Beginners will benefit much more from seeing a result moving. You also didn’t mention beginners in your initial post.
People need to use placeholder graphics to visualise the prototype. Doing spreadsheets and analytical builds are later, when you need proper balance, and only for games that require that proper balance.
Fun isn’t found on a spreadsheet, it’s balanced there later.
Idea → Prototype → Alpha → Beta
The only issue with alpha is when people think it’s just barely past prototype. It’s not, it’s basically the full game. You are proposing people do more work before a prototype (balancing before it’s designed), and more work after the prototype (by avoiding basic graphics that can reveal many pitfalls early on - especially with physics or movement being part of the game).
I don’t think it’s a good idea really to add more work, especially now you’ve mentioned beginners.
I don’t really disagree, but I guess I will disagree a bit:
As the goal of a prototype is to find the interesting thing in the game you are making, if your game isn’t really focused on mechanics, sometimes you do need pretty final art and music to see if your game is working and if the mood you’re going for is working.
I can’t be bothered to find it now, but there was a talk about Firewatch, where they talk about how in the quest to see if “walking around in the forest while having conversations” is interesting, they had to produce pretty close to final art for it.
What kind of iteration times do you get with this approach and could a Proto/simulation allow faster cycles?
Mind you there is a potential problem with a simulation approach:
Does the games industry have detailed open data on player response times, accuracy and ability to cope with multiple simultaneous targets or moving units?
As with this kind of information you could simulate various level of players and ideally with more data on play styles ensure your game has a great flow for a range of players.
That could explain why my boxy Unity prototype FPS games just don’t feel like AAA games and it’s hard to work on them over and over again trying to refine and improve their mechanics/level design to flow well. :(
What if Unity had a simulation mode where it cuts out all graphical rendering and allows your game to run at the top speed of your CPU (and GPU if you use GPU compute) in the editor, maybe even across multiple cores as processes to get around the issue with the main thread.
You can build your project for a dedicated server which would be ideal for simulation cycles if you could link the editor to the server and run lots of simulations.
Depends on the person. A while back our lead designer prototyped gameplay in spreadsheets. Including simulation, rudimentary AI and balancing (economy and progression). You could “play” the game end to end in the sheets, it was freaking amazing. He had loads fun… but he was weird.
I agree totally, I’m weird in a different way, but by this point beginners had entered the problem space and so I played it safe with the answers I felt were more useful to a typical Unity user. I think the nuance here is, some games are much better on spreadsheets, and some people function better visualising it differently. I think most people are herded toward some form of grotesque unity capsule with tutorials, so why fight it?
Fully agreed. I just saw ‘spreadsheets’ and felt compelled to take a shot at my friend. ;). (he is immensely successful, so I take every opportunity to make fun of him).
I think ultimately it depends on the game. For a typical 3d-space type game, capsules and such are prefect. If you are working in a larger org, they are actually very helpful, for the same reasons that artists/designers use pencil sketches. If others are testing it, with capsules/primitives they can only focus on the game play. If you are are using placeholder art that is similar… you tend to get feedback about the art, even though it is known it is placeholder. People focus on what is front of them.
And certainly for beginners this is very true. With so much to do/learn, it is easy to go down a rabbit hole making a prototype look good. With capsules, it is harder to get distracted with stuff that is going be fully replaced later.
For personal and small teams stuff, I prototype with old game assets. Stuff I have worked on before. Primarily because it is super fast and typically has a bunch of the stuff I already need. (animation, controls, etc…).