Are you better off writing a quick no graphics simulation of your game before starting a prototype?

1. You have your game idea running in your head and it's like a AAA game/movie of how amazing your game idea is.
2. You start developing the idea and quickly building and adding the pieces to Unity you need to make your game.
3. 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.

Anything else is just amateur hour IMHO.

 

What's your tests adjust cycle times and could you use a non-graphics simulation to search for better gameplay/balance faster?

 

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.

 

What if you actually try it out for yourself and see if it works?

I don't think anything in Unity is stopping you from doing this.

 

There's many different kinds of prototypes, and what you describe just sounds like yet another kind to me. Create one if you think it has value.

 

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.

 

As far as I'm concerned, the only times games and spreadsheets should be combined is in the context of EVE: Online.

 

There is this thing called machinations that looks really neat for this kind of thing

 

So all we need is the a Unity DOTS Spreadsheet class that runs each cell as a entity.

 

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...).

 

Having fun and showing people that this is why he's the lead designer.

 

What if a Simulation mode could speed up your iteration cycles allowing you to more quickly find better game balance?

 

For what kind of game? and why is balance important? Most games are better when there is imbalance unless you're talking about multiplayer, and even then it's debatable if anything should be balanced all that much (outside of casual obvious titles that balance for retention and spending).

Pause for a moment and consider that World of Warcraft has almost 2 decades of being imbalanced, simply because they can't and won't be able to balance it. The fun is in the nerfs and buffs, which happen every patch, so there isn't what they call a FOTM - flavour of the month. When a class or ability is perfectly balanced, everyone uses it and the fun dies, subscription revenue is down, and so on.

For balancing difficulty level, lets say a single player RTS - what are you balancing? In a mobile title that would be retention vs difficulty. For a desktop game that would be difficulty vs cookie cutter strategies. Already the fun is being sucked out. I don't think I'd be one to advocate balance being the important part. For me, balance is only applied if the problem area actually not fun for the majority.

So I don't think I want things to be balanced more than I want them to be fun. But in the spirit of the thread and questions, I believe there is a benefit to general automated testing but it's very hard to get right, and gets harder as the game complexity grows.

A roguelike or deckbuilder could have iteration based balance because it's not as hard to simulate the player actions. But such titles are actually best off balanced on a spreadsheet, as it's deterministic.

To simulate or do iterative balance as you suggest, you'd have to have a game that you didn't know the outcome of at all. Perhaps a fighting game introduces a new character? even if it's the case, how will the AI testing this, know how to break it, and why would you trust the results?

 

I absolutely love this guy. Hahahaha!

 

What if it couldnt?

 

Yesterday, I just put together a 9 month schedule for my next project.

I ended up speccing out time for greyboxing and all that. But I was, and am, torn on the subject of overly stripped down prototyping.

My gut keeps telling me that it's a waste of time to use overly stripped prototyping environments and that including more elements in the code base will save time in the long run. For example, including root motion based animation and a rig that will hopefully match final vs using a capsule.

You still need to write code to move the capsule around. If you're presenting the prototype to others, it's likely you will still need some level of polish in terms of presentation. Any time spent polishing the control for a capsule is completely wasted if you're going to use root motion. Might as while just start with proper animation in the first place.

I tend to think that the main value in the absolutely stripped approach has to do with dependencies on other work. For example, if the animation won't be available for 2 months, then you have no choice but to skip animation.

If otoh, you are planning on using off the shelf locomotion, or you can guarantee that production animation will have similar rotations and the like, then might as while include it in early prototype.

 

I would argue that using root motion for gameplay related animations is a bad idea most of the time.

 

I think this kind of thing is often done for training neural network AI, so I don't see why it couldn't be applied to finding a good game balance.

 

Imagine a DnD world with a balanced ecosystem that might fluctuate but is stable and then you open it to online players and they destroy the worlds balance.

Or any larger open living world game, with a fast non-graphical simulation you could probably evolve a stable world system that will not fall apart as quickly once you let players loose in it. And also check that NPC bandits can't just rob all the gold before the players get's there.

We are building more complex games and worlds and fast simulations may be another tool that allow our games to be less buggy or need as many nerfs and buffs after release.

 

Seems like it would cost more doing this than the costs it will save, if any, I don't feel convinced by this. It seems like it searches for a problem to solve.

 

It's just trying to apply high speed automation to game development test/adjust cycles.

 

what is it about simulating without players that lets you best work out what players will break?

 

I think whoever said it earlier that there is no "fun" to be found in a spreadsheet hit the nail on the head. I don't think there will be any benefit to this, or very little benefit, because a lot of what you're talking about comes down to "feel". Only the players who are playing the game can truly tell you whether your game is fun. Players might even say "it feels unbalanced" but maybe that's not really accurate "by the numbers".... It's a perception based on how the game "feels" when playing it.

I think that no amount of automation will help identify what "feels right".

 

Also, the lead of Subnautica in his GDC talk mentioned how whenever he was lost in the weeds and needed to remind himself of what the game was all about, he went back to the main menu + music.

I think in the same talk, he mentioned that the thing that really created the concept of subnautica from a disparate set of random ideas was some near-final art that was made at the beginning of the project that made the team realize they could create a game that was all about ambience and atmosphere of an underwater world.

I always feel a bit weird when I see people talk about spreadsheets and primitives, at best it only lets you test half of the game.

 

Well you can very quickly test out lots of permutations of items and interactions in your game that could find flaws and with player profiles you could ensure there are good trade offs for different player styles e.g. stealthy, defensive, offensive

 

This is pretty much only valid for games, with mechanics similar to card games.
You got A - B = C. Result.

Once you got things moving and path finding, elevations, covers, move speed, turn speed, fire accuracy, distance, fog etc, complexity increases dramatically. Spreadsheet become little of any use, other than data base, and generic parameters. You will not calculate results in spreadsheets.

 

So you're asserting that the answer to your own question is 'yes', then?

 

Exactly that's why I'm proposing the use of none graphical simulation as a quick way to test and adjust the complexity of your game.

 

As I am aware, unity offers solutions, which allows playing AI vs AI in cloud, or servers.
You can do that on your machine too. But most often you want to see what is going on, if AI is not cheating, so you need visual feedback. Or extensive testing features, which may not be feasible for smal studios and indies.
You can test your balance.
Hence whats new here?

If anything, you probably want to hire machine learning for such jobs.
Nothing but simple.

 

What you are 'proposing' is what is a pretty standard practice for... decades? It's nice that you are just learning about it, but... yea. It's part of what game developers do.

It varies depending on the game type and how you implement it, but it is unit testing(ish) for play.

It's is pretty much a requirement for any game of scale or complexity. No matter how much play testing you do, or how big your QA team is, it is not in the millions. Launching a game and/or turning on UA will instantly expose you game to several millions of players and they are going to blow by any amount of human testing you have done. Simulation (doesn't even have to ML or complex) is going to help find stuff you don't have time to test for. On our biggest games, new levels were always put through a smoke test. It would play the level millions of times with all possible combinations (and had the ability focus on key areas). It would show success rates, pinch points and provided cool heat maps of whatever element we wanted to look at. It was invaluable data for the designers to polish the level and adjust settings for them.

And when it comes to casual/puzzle games, simulation is critical for many reasons... avoiding duplication, playability, solvability and difficulty assessment. Heck, you basically cannot make some types of games (like sudoku) without a robust solver/simulator.

Simulation/automated play testing, though varied depending on game, is tool in your tool box. And while critical on large games, it can be very, very helpful on small teams who may not have deep QA resources. Alternately/additionally you can (should) have a method to record player gameplay (analytics) to play back and blend/asses to find problem spots (in gameplay, but sometimes technically too).

 

Could Unity make it easier to run our games as simulations e.g. without graphics or on servers linked to the Editor. And could more tools provide better simulation cycles with testing of permutations within our games?

 

Of course it could, but then, there are priorities.

I think you should really give a shot trying to do this and answer for yourself.