How can you use game engines to improve your prototyping?

Choosing a game engine to prototype also provides a level of understanding of that engine, beyond the actual programming for example: - Do your programmers feel comfortable with it? - Do your designers feel they can utilise what is already there and build on it? - Do your artists feel there is a workflow for them to use? - Does your QA team understand the tooling available to write unit or autotests in the future, or could they build a sensible test harness around it? Obviously, the key objective will be around the prototype, but understanding the potential (and limitations) by those responsible to deliver is a crucial part of it that must not be ignored.

Prototypes should be done fast, with as few resources as possible. I’ve prototyped with paper and sharpies. Choose whatever makes the most sense—and target what you’re testing. I’ll pick whatever software I can use to get at whatever I’m testing the fastest, be it Figma, or Unreal, or paper and tape.

It even does not have to be a game engine. For example, I used Excel for an idle game prototype. Pick a tool that is the fastest and the easiest to work with. The prototype is just for internal use to test an idea, so you may decide on the engine for the real game later.

Focus on testing out the smallest feature possible to answer the biggest question you have. Start minimalistic and with grey block assets. Plan to throw away the work early and often as you learn.

If you start with a new game engine - find and follow a tutorial on youtube for a simple game to get a grasp of it and only after start creating your prototype.

Not everything needs to be prototyped in an engine. Go low-tech rather than engine if you can. If it has to be more than “reactive” to validate/invalidate a design then an engine makes sense. Use placeholders but keep the assets structure as clean as a GDD. Can’t code? Learn the basics of coding . Start simple and build on it. Look up code that does something similar to what you want and skin it down to its bare bone. Break it, fix it. Learn to debug. Then use generative AI to give you code to do things that are more complex and do the same. Build your protos and kill them. Be ruthless. Still too scared of code? Use an engine with visual scripting (plugging blocks together). This will teach you the logic behind the code.

Nowadays most of the mainstream game engines like Unity Unreal or Godot has got their own plugins for direct transfer from within the DCC softwares itself like for eg. Maya has got an option to directly send the model to unity and do what is called as roundtripping. There is no more a need of converting it to a fbx or 3ds and then importing it into unity, those days are gone and now it's more easy. Also unreal has what is called as Datasmith exporter for 3dsmax. This plugin automatically converts a 3dsmax file into a udatasmith file which can be directly imported into Unreal engine and the plugin also has the option to realtime sync 3dsmax and unreal engine. Even for blender there are add-ons for export to unreal and unity.

Prototyping is a DESIGN PROCESS that happens early and is about trying out an idea as fast as possible and as simple as possible. A prototype is supposed to be cheap. If you are spending a lot of time on polishing, you might be approaching prototyping wrong. Prototype is good for: - Concept validation: Is this fun? Does it work? - Risk reduction: Is this design choice risky? How hard is it to implement it? - Increased communication: how can I communicate what is this game about? A good prototype usually will tackle fundamental aspects of the design such as level design, UI, gameplay mechanics, graphics/art style/art direction, sound and music, scalability, and technical feasibility. A great prototype will tackle many of those.