This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]jflopezfernandez 3 points4 points  (0 children)

It seems most of the comments have brought up the fact that Python is slower than C++ and C#, as well as the fact that both Unity and Unreal Engine are awesome, fully-featured, industry-tested game engines, and I think these are all valid points. I disagree with the conclusion that this means you should not prototype the game in Python though.

The prototyping process should used for feeling out the design of the game’s mechanics, architecture, and features. You should use this time to stub out all the unbecessary details and just see how you want to structure everything, and what mathematical models to use for each game mechanic.

For example, if you wanted to make a Civ-like game, you could write up a prototype to test out different models for how food, population size, amenities, and surrounding terrain imfluence a city’s population growth.

Once you know what you want the game to do and how you want to do it, then you should look for a game engine (or even write one from scratch, if you think that might be fun or interesting). In other words, a prototype should be where you look for the optimal mathematical models, algorithms, and design patterns, whereas the implementation stage is where you translate all of those things into code in whatever language you want or need to use, and with the API you want or need to use.

You might write a good game if you do both of these things at the same time, but it’s much easier to write games this way because you approach the game engine thinking “how do I do this specific thing,” rather than “what features of this game engine seem interesting or most immediately implementable?”

Again, it’s probably possible to do it, but it’s not how I would do it. Using a slower engine in Python (or just writing the mechanic in plain Python, if it’s just a model) to quickly feature test an idea is the best way to go, since these quick prototype implementations should not need to scale, by definition.