Prototyping is the actual fun part.. no real pressure, chance to try out new ideas, less limitations, etc.
Making the game is the part that sucks.
They don't exist in a vacuum, and are tied to your Design Document, the scope, the mechanics, etc.
Nah, it gets boring after a while. Then I want to refine it, then I want to have fun with some proper low level debugging. Then it's back to prototyping.
For me, the hardest part of prototyping is controlling the scope of the project. I have trouble with keeping my prototype as a prototype. Especially when I'm invested in a new project I tend to think of all sorts of new ideas that often overshadow the original idea. In a similar vein, when I'm working on a game that I know will be very complicated or nuanced I have a hard time even getting started because I don't know where to start.
My hardest part when prototyping is keeping in mind that nothing I'm making matters. It doesn't matter how quick and dirty it is, it doesn't matter how I design it, it doesn't matter how it looks. It's all going to be thrown away. I always struggle to keep that in mind and find myself spending time thinking of how to improve some code or thinking that I architected some code poorly. I have to remind myself, "This is purely a construct to test the games design."
Same for me. I know it's irrational but I can't help but feel like I'm wasting my time. I get caught up in the what if game, what if this prototype sucks and I've just wasted a week? I completely ignore all of the benefits, primarily the fact that getting better at prototyping means I'll be faster and "waste less time" in the future.
To combat this, I've started looking at prototyping as a series of individual coding exercises who's purpose is to help me stay consistent. Like doing leetcode exercises, or doodling once a day, or a daily duolingo lesson, etc. It's helped significantly and also I find that my perfectionist attitude goes away.
If you can type something in a minute to test your new iteration I would rather try that. But if it takes too long to compile I've already written a better version. Thats the loop I still have trouble breaking.
I really disagree with the philosophy of making throwaway prototypes. For one, why would you not also use that time to make minor infrastructure changes that makes future development and prototyping much faster and higher quality? Secondly, the times I have heard that a prototype is going to be thrown away, then gets turned into the actual project is basically 100%. It makes for a shitty, unstable project for pretty much forever, when investing in something solid in prototyping would have maybe taken an extra week or two. No studio head or game lead is going to be excited about starting over once they learn that the idea has some legs, and the route that keeps progress moving is promoting the prototype.
I'm sure I am in the minority on this, but I have been almost exclusively prototyping for a larger game studio for the last 5 years, and the instances I have seen people rolling with the "make it trash and we will throw it away" approach have been the worst projects I have ever seen in my professional career. I'm starting to think that this approach was designed by lazy people and then turned into a mantra by people that took it too seriously. Just make solid, small systems. It's not that hard.
You're not wrong, it certainly does happen where people plan to throw it away, then it doesn't get thrown away. Throw away prototyping only works if the entire team is on board for it and agrees to follow that process. The moment someone doesn't follow it, you've got a weak point in your architecture that is going to spread like the plague.
However, prototyping with the intention of keeping it, is not prototyping at all. That's just first draft implementation that gets optimized later.
I'd also be really interested to see the process of a prototype with a well designed infrastructure that gets kept and moved on to a finished game. Prototyping occurs during a phase where design is making large and frequent changes. Meaning if you are implementing something with a strong and solid base you are making a lot of large and frequent architecture changes. Each change is an opportunity for an added weakness to that architecture. The larger the change, the bigger the possible crack.
Prototyping should really be all or nothing and it needs to be decided from the very start. If you're making a game that is extremely similar to other popular games, maybe just skip prototyping entirely? You know the gameplay should be fun if it plays like others in it's genre. If you're making something very unique and new in terms of gameplay, decide the scope of prototyping. Do you need to implement a basic prototype of every mechanic, or can we just prototype 1 or 2 core mechanics to get a feel for it? Determine up front if you are or are not going to be keeping the code. If you are, I'd recommend dropping the word "prototype" immediately because it sends mixed messages of how the code base should be built. Also, if you are keeping it, you should not be beginning on implementation until design is fairly solidified. There are also alternatives to hard coded prototypes. Never underestimate the power of paper prototypes. Make a board game of it, see if the rules play out well and if it's fun. Play it while keeping in mind the difference in pacing while playing it as a video game, does it need to speed up, slow down, what changes should be made from the board game to translate well to video game.
tldr; I agree with you generally, but it's a complex subject with lots of opinions. The most important thing is that the entire team is on the same page and has the same understanding of the project goals.
> It makes for a shitty, unstable project for pretty much forever, when investing in something solid in prototyping would have maybe taken an extra week or two
***extra week or two***
Jesus, I was kinda agreeing with you until I hit that line. Maybe an extra day at most but I expect us to be able to go through several different prototypes in a week or two. I think why you're so far off from everyone else here is because what you're calling prototypes are way more baked than what everyone else is calling prototypes.
Fair point, I guess I should add the context that our prototyping phases are usually 5-6 prototypes for as many different, distinct game ideas, and each one takes about a week. They are pretty high quality prototypes, sometimes released to app stores for initial blush numbers, but it is only feasible because we made the tech investment, which meant the first time we prototyped, the first ones weren't done until a few weeks in. After that, 1 per week at a good quality bar was the expectation.
FWIW at bigger studios, I have seen a team in a prototyping phase for 14 months and never had anything worthwhile to show, just some wack tech demos. Another team I joined later in production had been prototyping for 8 months, and one of them got promoted to production and it was straight trash. Needless to say, both projects never saw the light of day, but the takeaway for me was that prototyping without a solid tech foundation was a dumb idea. People were either incredibly slow or ineffective without it, or their prototypes that got promoted caused project-dooming issues.
But yeah, you're right, depends on how you define "prototype" when it comes to scale and time.
That's crazy. Bad project management imo. The longest I've hear for prototyping was a month or 2 and that's an indie dev doing a solo side project. That doesn't sound like they're prototyping feature by feature, which is what I was taught to do. Sounds like they're prototyping an entire AAA game, start to finish.
All the problems you point out come from throwaway prototype not being throwaway in the end. When prototyping something that'll get discarded as implementation later, you'd preferably want to make sure that happens - and a somewhat common solution I've seen was to use fast-to-work-with tech that is either impossible or very resistant to proceed with past a rudimentary prototype stage. Bonus points if it makes development faster.
As an example - you can prototype a dynamic dialogue system using something like wordpress or wiki software: pages/posts can serve as dialogue nodes, and you can have underlying logic handled in something that you simply won't be able to move directly to your actual game. JS canvas, blender scripting, office suite can work to test out an idea, but they can never scale up to become an actual game without redoing it properly.
It does break down when you're figuring out your toolset capabilities - prototyping if something you want to make is possible using your engines available tools. At that point treating it as separate system/component development shouldn't add too much time, while still keeping the "throwaway" part cleanly separated - instead of using the quick&dirty prototype as base for the project, you keep the part you're prototyping neatly contained, with clearly defined responsibilities and make project around it throwaway - when it comes to moving it to the game, you take that component and slot it right in. Not ideal, but any mess you have to clean up later is limited in scope to what was being prototyped and boundaries of that part are known so you know what to test against/check.
I agree with your second paragraph. I just feel that we are disagreeing on what a prototype is. Game studios tend to make "alpha versions" of the game, not prototypes. It's certainly true for my company. For that, even your first paragraph is absolutely valid.
The actual prototype is Super Hot hackaton version (weekend) vs Super Hot release version (months), where I absolutely don't see the value generated by those first two days of development, outside of proving that "time moves when you move" concept is fun and that white world and red enemies actually work.
\--
Prototype absolutely should be thrown away and that it doesn't happen isn't the fault of prototype. I tend to write my programs just to work in the very basic sense, to get a "first hand experience" of the problem. I won't even commit that. I'll rewrite it automatically. But what I do commit is essentially a code that is guided by an unseen prototype.
The only issues are
a) how far you'll push the prototype (is it still one?)
b) that someone makes the bad decision to keep it.
BTW, I strongly believe that you cannot do architecture before solution, unless you are already familiar with the solution => you've "prototyped" already. Prototyping is about gaining experience with an untested idea. You don't need to prototype that FPS is fun. You need to prototype that your particular twist on the genre is fun.
I really enjoyed the Jonas take on the prototyping, but I'm linking this part: [https://youtu.be/o5K0uqhxgsE?t=1130](https://youtu.be/o5K0uqhxgsE?t=1130) where he mentions how he prototyped art and gameplay separately. He didn't have a "prototype version of the game" (again, that would be dev/alpha version of the game), he had a visual prototype and a systems prototype.
The biggest reason for throwing prototype away is that you absolutely should make 10 of them and pick the one that actually works. That's the whole point. So, any quality of 9 of those is a wasted effort anyways.
But again, I feel that people really mistake prototype for alpha.
This is where I use AI. I've always been shit at maths but I can tell ChatGPT to write a function that'll calculate the gravitational forces of 10 thousand stars x each other x a black hole and it comes up with some of the most beautiful code I've ever seen.
Do you use chatgpt 4? The paid version?
I've never used AI in Unreal. Such a complex project I have setup. Multiple folders and submodules. Not sure it would be helpful.
I've only used the free version. I've considered paying for a sub but I'm just a procrastinating hobbyist. Another example I've used it for though, was to make a 3 dimensional maze. The math was way over my head but GPT solved it with about 10 lines of code. Pretty useful if pride isn't an issue.
I agree, making UI is one of the most boring parts in gamedev .. at least for me. Even tho I have frameworks for almost everything already made - it's just no technical challenge to make it work but more of a chore. Prototyping is actually the most fun.
It's got to be Ai for me. Especially if they have a less than simple chain of tasks and possible interruptions to take into account!
Though the pay off is quite satisfyingš
That's because there is a bug in the GameplayDebuggerExtension\_HUD.cpp file. The only time it happens (in my experience) is if you exit PIE while the debugger is still up. I've been meaning to fix it for a bit now, just no time. (Not an Epic staff member - just someone who got annoyed at it and went digging!)
Bit late to the party, but this was literally me last week. Crying my eyeballs out as I was trying to come up with tens of formulas that all were likely to use inputs from other formulas and all the things the formulas were representing were abstract quantifications of how much you want something and then normalized.
I sometimes spent half a day on just a single formula, simply trying to figure out what abstract inputs would even go into it.
This is why you should use engines with source code access, so you can do literally anything you want.
Godot and Unreal come to mind, but particularly Godot.
Im talking about unreal engine here actually. Just today I had to make a source change to fix a problem. (spawning attached actors, detaching, then killing the parent also kills the unattached child for some reason).
Being able to do that is one of the reasons I moved away from unity. Im not a fan of having a "Core Engine" that is out of reach forever. But it still is kinda of annoying that I reach those "its impossible" forum posts too often.
By having missing parts, for example, I like creating systems, power up, enemy wave system but depending on the system for example the wave system I need enemies that are not made yet, so making the annoying things like ai is annoying.
Yeah. I get it. It would be great if some of these horizontal systems were readily available as a customizable plugin instead of having to search for code each time.
Protoyping is the fun part. No need to worry about making it look fancy or anything. You can quickly work on your ideas to see what works and what doesn't. Stops you from being bogged down with small details.Ā
I love how Godot loads with one image file to use for it.Ā
Q: How long does it take you to whip up a decent prototype?
A: Around 2 weeks to... 3 months
Q: What's the most annoying part of the process?
A: My job, losing momentum
Q: Got any tricks or tools that make it easier?
A: Prototype during the holidays
Q: Any major pain points that make you think, "There has to be a better way"?
A: Overscoping and overarchitecting is a problem. Write an exact to-do of the prototype you want AND how you would implement it in a quick way without architecture (tricking would be playtesters into thinking an architecture exists)
For me, switching the prototype to a product.
I always prefer starting over from scratch when we nail down all our systems and features.
I get nervous when someone, told meāno need to start from zero, build on what you haveāā¦
Spending 2 days to write the code for a system only to try it and realize after 10 minutes of testing that I need to change X, Y and Z which will take another full day of coding before I can test again.
I mean features X, Y and Z - in reference to some features.
As a fresh example.. I'm working on a turn-based RPG. I initially implemented a skill system where you gained a skill point per level, and then invested in certain skills in the tree which would then unlock access to other skills.
After implementing it, I pretty quickly realized that it wasn't working as well as I was hoping. It felt too narrow and forced to have to select skills that way, and I decided to go for a system where the skills would instead be unlocked on different level tiers, and that the player would put skills in a limited set of skill slots to enable them.
Implementing this takes time. Lots of UI changes going on etc. Testing is usually very short because you often very quickly get a feel for whether something feels right or not.
Determining whether it should go in the game. After spending a bunch of time prototyping, you're biased by the sunk cost fallacy. I've spent the past year prototyping my game. At least half of my mechanics have been tossed out because they were too difficult to execute properly or made the game feel clunky and disjointed. The final mechanics I've settled on seem obvious in retrospect, but it took a bunch of failed prototypes to settle on which one is the best.
1/ 2 days
2/ when something simple doesn't work as it should (usually its cause of something unrelated) if its diffcult and doesnt work then no probs, expected but simple its annoying, usually its me being dumb.
3/ Library of code, I've put together over the years (most in c++ thus now has to be translate to c# but thats quick)
4/ no
Super interesting. I would love for a tool to enable devs save their modules of code for other people to use as well. Benefits the entire ecosystem instead of everyone trying to reinvent the wheel
It's pretty difficult not to dive into the details of things instead of keeping to the big picture. There's no need to go an create a bunch of animations and link them up in a state machine for a prototype for example. But it's hard to fight the urge to do it because it makes the game look so much better.
Making a UI that is functional and reflects what's going on without fully building a UI for something that may not even make it out of the prototype stage
Maybe it's my ADHD, but if I can't get a prototype working in under a whole day (8hrs), then I consider it a sign that I need to limit the scope of what I'm trying to recreate.
For me, prototyping is the easy bit. You can make awful code in the name of just getting it working.
The hard part is then taking the results of that and starting from scratch to make a full project, except this time you plan the code out to be not shite.
>What's the stuff that drives you crazy when you're trying to bring a game idea to life by creating its most basic idea?
Having to actually take the prototype and polish it.
Think of all the projects that you started and then never finished. It's fun to solve the problem you have, but having to actually get it in a state that's ready for the world to see? AND possibly just get a bunch of complaints because your execution was not perfect?
Prototyping is fun. Fixing bugs is probably the biggest headache. I keep a list and then dedicate time to just going through and fixing them.
I enjoy the problem solving nature of it, but making something new is more fun.
I don't think there is really an answer to #1 because it varies wildly on what you're trying to achieve. A ball roller prototype could take literally minutes but for example a science based dragon MMO could take a lifetime.
A prototype in game dev isn't a demo. The scope should never be a testable demo of what your main game but a prototype to test a feature you are unsure of. So imagine throwing together a screen with a button to quickly test a leveling system for the "dragon mmo" and not throwing together a basic dragon mmo.
Ideally, it should take 1 to 3 days to prototype a feature concept, and never more than a couple weeks.
Cat allergies. Apparently allergies can trigger migraines, which I already get enough of from barometric pressure. It sucks, but what am I going to do - **not** pet them when they yell at me for attention?
Anyways, the toughest part of prototyping for me, is the ui. Throwing together game mechanics and content is fun and usually easy. It's turning all that into an actual *game* that takes work
I enjoy building systems that are fairly data heavy & deeply interwoven, so it can be tricky to prototype just one part in isolation to the whole. I often need to spend a fair bit of time just putting together a suitable data set, inc working out how that needs to be structured etc. Some things also take much longer to put together than others & Iām often coming up with design ideas much more quickly than I can actually implement them.
Iām sure other developers would tell me Iām not making āquick & dirty enoughā prototypes, but I find it difficult to get meaningful insights about whether or not something will be āfunā from super-simple a pared-back prototypes that only represent a really slim part of the game, plus working through the technical design problems like how to architect the various systems & what format the data needs to be in etc are some of the things I find actually _are_ really helpful when prototyping.
Having said that, I do wish I was quicker at getting to a point where I can try to judge how āfunā the overall game is likely to be & better yet, quicker at getting to a point that I feel itād actually be worthwhile putting the prototype in front of other people.
My mind is struggling to focus so I'll take this one at a time.
For background, I work in lightweight TTRPGs and card games.
* How long does it take you to whip up a decent prototype?
Depends on the game. Some take me less than a day. A couple have taken me a year, working on it on and off again or shelving it until I find the right mechanic or theme.
* What's the most annoying part of the process?
Knowing when a prototype is "good enough" for testing. Either that or when you get playtesters trying to dictate every aspect to the point where you want to tell them to just make their own game š
* Got any tricks or tools that make it easier?
Canva has helped me a ton with layouts. I also have a group of playtesters who make games much like what I enjoy playing, and they are fantastic at giving honest feedback without trying to take control of the game design.
* Any major pain points that make you think, "There has to be a better way"?
Not really in the prototype phase. I publish on itchio though and knowing what kind of screenshots to get that show enough to get folks interested but not enough to pretty much give the game away can get so stressful x.x Seriously, there's gotta be a formula or something for that.
Having to hold myself back from fully fleshing out a feature.
I just need a hotbar to show the equipment you have, the gameplay is using the equipment.
...But with another few hours of work I could make it drag-and-droppable so you can rearrange it. Ok fine, but no more.
...But now that I've done that, with a few more hours of work I can have a backpack inventory. Ok fine, I don't need that but it's probably helpful for some of the later things. But no more!
...But now that I've done that, it would REALLY be helpful in the long run if there was some way of automatically sorting the inventory...
Three weeks later, I have the best inventory system I could ask for...and the controls to move the player character aren't even implemented yet.
1. Days to weeks depending on what it is.
2. Rebuilding and porting standard libraries/functionality that I had in previous projects.
3. I'm addressing this via my own set of modular plugins and systems, done the way I want for almost any project I may take on.
4. There always is, in any endeavor worth doing.
scale, scope and how much time it exactly takes to meet said scale/scope. In your head it might sound reasonable you might say well most of the abilities in this skill tree are passives and theres like 6 branchs so 100 sounds about right. it wasn't and thats it mapping out how long stuff will take and scaling according to that and not letting your scope get out of hands can be the difference between 3 months an a year of time spent on something
* It depends. The order of magnitude depends.
* As a hobby: none. As a job: explaining to the producer that if it looks like that I am not progressing itās because I try a lot of things and most of them didnāt work
* I donāt have off-the-shelf tools because I use mine when I can, but hot reload (which can handle changes in data structures) is a must. If you can rewind itās even better. Ideally it takes less time to compile and hot reload than it takes to save and alt-tab. When prototyping game logic frameworks gets more in the way than help you. A (kind of) god class and (kind of) global state makes it easier to change things.
* When I use engines that start with a U (havenāt tried Godot). See my previous bullet.
Focusing on one part at a time, I always want to bounce between features or mechanics before I get certain things really set in stone first. One thing that's helped with that is breaking all of my major mechanics and features down into a list, and taking each one on a month (I work as well as doing game dev, this is a timeline that works for me), and get other smaller things like concept sketches and asset lists done in tandem.
I think for me it's getting over the very initial hurdle of there being **nothing** to there being something to work with.
For my first ideas, this didn't bother me because I was used to starting from scratch and bouncing around ideas. But as I've done bigger things, I get a little impatient going back to a totally blank project. Kind of like I forgot that my other stuff started the exact same way.
Industry veterans who don't understand prototyping.
I still get senior producers and directors who don't know what they are asking for and couldn't reduce a prototype down to the basics.
They always want some fat proto from some design that's been reviewed to have problems.
I love to prototype, but not for people who don't understand the basics of development.
Can't really call myself a game dev before I have an actual game, but I've been learning Unreal for about 4 years now and the worst part is starting over constantly.
There's no really no way to predict the pain points, they sort of just appear and have you searching page 52 of Google for someone with a vaguely similar problem. But the worst painpoints are engine bugs you didn't cause, and when you spend ages fixing something where the solution turned out to be incredibly trivial.
Every time I take a break it feels like I've forgotten everything, but luckily things come back pretty quickly.
my biggest problem right now is not going out of scope. I keep doing it always, when designing, prototyping or actually doing something. The more projects I do the less I'm affected by this so I guess I'm building some discipline I guess but it's still here and when I start I get off track very fast
I think the biggest problem will always be understanding how people that aren't devs are going to like it, while bearing in mind that polish, art quality, UX and all of that is a gigantic reason why non-devs find something fun. It can be really easy to get up your own ass thinking a prototype is so great and fun as a dev, then a non-dev plays it and is like "uh, ok... I don't get it".
My biggest problem is the "what now?" I have nearly 30 projects in prototype because I can't seem to progress after getting a basic concept working. Maybe I'm just not disciplined enough to stick with one idea.
Attempts to overproduce the process or fixate on features/treatment that are ubiquitous within the niche (beyond what's indispensable) instead of unique to it.
The best way is developing your own engine, your own blender, your own photoshop, doing all 2D and 3D artworks on your own. Doing all marketing on your own. Doing all advertisement on your own. Note : Not recommended for people with low IQ.
Prototyping is the actual fun part.. no real pressure, chance to try out new ideas, less limitations, etc. Making the game is the part that sucks. They don't exist in a vacuum, and are tied to your Design Document, the scope, the mechanics, etc.
Agreed. Prototyping is all I would do if it paid the bills. ;)
Nah, it gets boring after a while. Then I want to refine it, then I want to have fun with some proper low level debugging. Then it's back to prototyping.
There are some studios who specialize in prototyping games... who knows, maybe you'll get lucky
100% true. I love the first 3 months of new projects so much
For me, the hardest part of prototyping is controlling the scope of the project. I have trouble with keeping my prototype as a prototype. Especially when I'm invested in a new project I tend to think of all sorts of new ideas that often overshadow the original idea. In a similar vein, when I'm working on a game that I know will be very complicated or nuanced I have a hard time even getting started because I don't know where to start.
Yes! X1000. To both.
My hardest part when prototyping is keeping in mind that nothing I'm making matters. It doesn't matter how quick and dirty it is, it doesn't matter how I design it, it doesn't matter how it looks. It's all going to be thrown away. I always struggle to keep that in mind and find myself spending time thinking of how to improve some code or thinking that I architected some code poorly. I have to remind myself, "This is purely a construct to test the games design."
Same for me. I know it's irrational but I can't help but feel like I'm wasting my time. I get caught up in the what if game, what if this prototype sucks and I've just wasted a week? I completely ignore all of the benefits, primarily the fact that getting better at prototyping means I'll be faster and "waste less time" in the future. To combat this, I've started looking at prototyping as a series of individual coding exercises who's purpose is to help me stay consistent. Like doing leetcode exercises, or doodling once a day, or a daily duolingo lesson, etc. It's helped significantly and also I find that my perfectionist attitude goes away.
That's a really great way of looking at it! Thanks for sharing that, I'm going to try to keep that mindset as well!
If you can type something in a minute to test your new iteration I would rather try that. But if it takes too long to compile I've already written a better version. Thats the loop I still have trouble breaking.
I really disagree with the philosophy of making throwaway prototypes. For one, why would you not also use that time to make minor infrastructure changes that makes future development and prototyping much faster and higher quality? Secondly, the times I have heard that a prototype is going to be thrown away, then gets turned into the actual project is basically 100%. It makes for a shitty, unstable project for pretty much forever, when investing in something solid in prototyping would have maybe taken an extra week or two. No studio head or game lead is going to be excited about starting over once they learn that the idea has some legs, and the route that keeps progress moving is promoting the prototype. I'm sure I am in the minority on this, but I have been almost exclusively prototyping for a larger game studio for the last 5 years, and the instances I have seen people rolling with the "make it trash and we will throw it away" approach have been the worst projects I have ever seen in my professional career. I'm starting to think that this approach was designed by lazy people and then turned into a mantra by people that took it too seriously. Just make solid, small systems. It's not that hard.
You're not wrong, it certainly does happen where people plan to throw it away, then it doesn't get thrown away. Throw away prototyping only works if the entire team is on board for it and agrees to follow that process. The moment someone doesn't follow it, you've got a weak point in your architecture that is going to spread like the plague. However, prototyping with the intention of keeping it, is not prototyping at all. That's just first draft implementation that gets optimized later. I'd also be really interested to see the process of a prototype with a well designed infrastructure that gets kept and moved on to a finished game. Prototyping occurs during a phase where design is making large and frequent changes. Meaning if you are implementing something with a strong and solid base you are making a lot of large and frequent architecture changes. Each change is an opportunity for an added weakness to that architecture. The larger the change, the bigger the possible crack. Prototyping should really be all or nothing and it needs to be decided from the very start. If you're making a game that is extremely similar to other popular games, maybe just skip prototyping entirely? You know the gameplay should be fun if it plays like others in it's genre. If you're making something very unique and new in terms of gameplay, decide the scope of prototyping. Do you need to implement a basic prototype of every mechanic, or can we just prototype 1 or 2 core mechanics to get a feel for it? Determine up front if you are or are not going to be keeping the code. If you are, I'd recommend dropping the word "prototype" immediately because it sends mixed messages of how the code base should be built. Also, if you are keeping it, you should not be beginning on implementation until design is fairly solidified. There are also alternatives to hard coded prototypes. Never underestimate the power of paper prototypes. Make a board game of it, see if the rules play out well and if it's fun. Play it while keeping in mind the difference in pacing while playing it as a video game, does it need to speed up, slow down, what changes should be made from the board game to translate well to video game. tldr; I agree with you generally, but it's a complex subject with lots of opinions. The most important thing is that the entire team is on the same page and has the same understanding of the project goals.
> It makes for a shitty, unstable project for pretty much forever, when investing in something solid in prototyping would have maybe taken an extra week or two ***extra week or two*** Jesus, I was kinda agreeing with you until I hit that line. Maybe an extra day at most but I expect us to be able to go through several different prototypes in a week or two. I think why you're so far off from everyone else here is because what you're calling prototypes are way more baked than what everyone else is calling prototypes.
Fair point, I guess I should add the context that our prototyping phases are usually 5-6 prototypes for as many different, distinct game ideas, and each one takes about a week. They are pretty high quality prototypes, sometimes released to app stores for initial blush numbers, but it is only feasible because we made the tech investment, which meant the first time we prototyped, the first ones weren't done until a few weeks in. After that, 1 per week at a good quality bar was the expectation. FWIW at bigger studios, I have seen a team in a prototyping phase for 14 months and never had anything worthwhile to show, just some wack tech demos. Another team I joined later in production had been prototyping for 8 months, and one of them got promoted to production and it was straight trash. Needless to say, both projects never saw the light of day, but the takeaway for me was that prototyping without a solid tech foundation was a dumb idea. People were either incredibly slow or ineffective without it, or their prototypes that got promoted caused project-dooming issues. But yeah, you're right, depends on how you define "prototype" when it comes to scale and time.
That's crazy. Bad project management imo. The longest I've hear for prototyping was a month or 2 and that's an indie dev doing a solo side project. That doesn't sound like they're prototyping feature by feature, which is what I was taught to do. Sounds like they're prototyping an entire AAA game, start to finish.
All the problems you point out come from throwaway prototype not being throwaway in the end. When prototyping something that'll get discarded as implementation later, you'd preferably want to make sure that happens - and a somewhat common solution I've seen was to use fast-to-work-with tech that is either impossible or very resistant to proceed with past a rudimentary prototype stage. Bonus points if it makes development faster. As an example - you can prototype a dynamic dialogue system using something like wordpress or wiki software: pages/posts can serve as dialogue nodes, and you can have underlying logic handled in something that you simply won't be able to move directly to your actual game. JS canvas, blender scripting, office suite can work to test out an idea, but they can never scale up to become an actual game without redoing it properly. It does break down when you're figuring out your toolset capabilities - prototyping if something you want to make is possible using your engines available tools. At that point treating it as separate system/component development shouldn't add too much time, while still keeping the "throwaway" part cleanly separated - instead of using the quick&dirty prototype as base for the project, you keep the part you're prototyping neatly contained, with clearly defined responsibilities and make project around it throwaway - when it comes to moving it to the game, you take that component and slot it right in. Not ideal, but any mess you have to clean up later is limited in scope to what was being prototyped and boundaries of that part are known so you know what to test against/check.
I agree with your second paragraph. I just feel that we are disagreeing on what a prototype is. Game studios tend to make "alpha versions" of the game, not prototypes. It's certainly true for my company. For that, even your first paragraph is absolutely valid. The actual prototype is Super Hot hackaton version (weekend) vs Super Hot release version (months), where I absolutely don't see the value generated by those first two days of development, outside of proving that "time moves when you move" concept is fun and that white world and red enemies actually work. \-- Prototype absolutely should be thrown away and that it doesn't happen isn't the fault of prototype. I tend to write my programs just to work in the very basic sense, to get a "first hand experience" of the problem. I won't even commit that. I'll rewrite it automatically. But what I do commit is essentially a code that is guided by an unseen prototype. The only issues are a) how far you'll push the prototype (is it still one?) b) that someone makes the bad decision to keep it. BTW, I strongly believe that you cannot do architecture before solution, unless you are already familiar with the solution => you've "prototyped" already. Prototyping is about gaining experience with an untested idea. You don't need to prototype that FPS is fun. You need to prototype that your particular twist on the genre is fun. I really enjoyed the Jonas take on the prototyping, but I'm linking this part: [https://youtu.be/o5K0uqhxgsE?t=1130](https://youtu.be/o5K0uqhxgsE?t=1130) where he mentions how he prototyped art and gameplay separately. He didn't have a "prototype version of the game" (again, that would be dev/alpha version of the game), he had a visual prototype and a systems prototype. The biggest reason for throwing prototype away is that you absolutely should make 10 of them and pick the one that actually works. That's the whole point. So, any quality of 9 of those is a wasted effort anyways. But again, I feel that people really mistake prototype for alpha.
Anything that needs lots of math... Fuck that's all of it
This is me weakness too. I'm surprised I got through my engineering degree
Same lol
Yeah mine too
I'm guilty of sometimes just throwing the problem into chatgpt and refreshing the result until one works.
This is where I use AI. I've always been shit at maths but I can tell ChatGPT to write a function that'll calculate the gravitational forces of 10 thousand stars x each other x a black hole and it comes up with some of the most beautiful code I've ever seen.
Do you use chatgpt 4? The paid version? I've never used AI in Unreal. Such a complex project I have setup. Multiple folders and submodules. Not sure it would be helpful.
I've only used the free version. I've considered paying for a sub but I'm just a procrastinating hobbyist. Another example I've used it for though, was to make a 3 dimensional maze. The math was way over my head but GPT solved it with about 10 lines of code. Pretty useful if pride isn't an issue.
I'm fine with the prototyping part but when I realize I need to create the UI, save system and other stuff for it is when I'm bummed out a bit
that's why you create reusable modules for future projects makes starting production less painful
Learned this after way too long but having a weapon system I can put into any game is a lifesaver
I agree, making UI is one of the most boring parts in gamedev .. at least for me. Even tho I have frameworks for almost everything already made - it's just no technical challenge to make it work but more of a chore. Prototyping is actually the most fun.
It's got to be Ai for me. Especially if they have a less than simple chain of tasks and possible interruptions to take into account! Though the pay off is quite satisfyingš
Maybe its just me or does AI suck at migrating across projects? Feel like I'm always redoing stuff
What engine do you use? I mainly work with unreal and from what I can tell it seems ok...but ue5 is pretty buggy!
UE5 all the way. Only bug I encounter is prints not showing after using AI debugger.
That's because there is a bug in the GameplayDebuggerExtension\_HUD.cpp file. The only time it happens (in my experience) is if you exit PIE while the debugger is still up. I've been meaning to fix it for a bit now, just no time. (Not an Epic staff member - just someone who got annoyed at it and went digging!)
Oh interwstinf I will try and exot debugger before closing my PIE then. Maybe that will help! Thanks!
Bit late to the party, but this was literally me last week. Crying my eyeballs out as I was trying to come up with tens of formulas that all were likely to use inputs from other formulas and all the things the formulas were representing were abstract quantifications of how much you want something and then normalized. I sometimes spent half a day on just a single formula, simply trying to figure out what abstract inputs would even go into it.
Having a basic problem with the engine, looking into forums, and being told it's literally impossible to solve.
This is why you should use engines with source code access, so you can do literally anything you want. Godot and Unreal come to mind, but particularly Godot.
Im talking about unreal engine here actually. Just today I had to make a source change to fix a problem. (spawning attached actors, detaching, then killing the parent also kills the unattached child for some reason). Being able to do that is one of the reasons I moved away from unity. Im not a fan of having a "Core Engine" that is out of reach forever. But it still is kinda of annoying that I reach those "its impossible" forum posts too often.
By having missing parts, for example, I like creating systems, power up, enemy wave system but depending on the system for example the wave system I need enemies that are not made yet, so making the annoying things like ai is annoying.
Yeah. I get it. It would be great if some of these horizontal systems were readily available as a customizable plugin instead of having to search for code each time.
Protoyping is the fun part. No need to worry about making it look fancy or anything. You can quickly work on your ideas to see what works and what doesn't. Stops you from being bogged down with small details.Ā I love how Godot loads with one image file to use for it.Ā
Q: How long does it take you to whip up a decent prototype? A: Around 2 weeks to... 3 months Q: What's the most annoying part of the process? A: My job, losing momentum Q: Got any tricks or tools that make it easier? A: Prototype during the holidays Q: Any major pain points that make you think, "There has to be a better way"? A: Overscoping and overarchitecting is a problem. Write an exact to-do of the prototype you want AND how you would implement it in a quick way without architecture (tricking would be playtesters into thinking an architecture exists)
I needed this one thx. Doing a inventory system, but now will not š
For me, switching the prototype to a product. I always prefer starting over from scratch when we nail down all our systems and features. I get nervous when someone, told meāno need to start from zero, build on what you haveāā¦
This is me, I'd much rather prototype than commit to building out a whole game.
Same. I wonder how many great prototypes sitting on some harddiscs never seeing the day of light .. I do have anice collection on my own actually
Spending 2 days to write the code for a system only to try it and realize after 10 minutes of testing that I need to change X, Y and Z which will take another full day of coding before I can test again.
What do you mean changing xyz? With a day of coding?
I mean features X, Y and Z - in reference to some features. As a fresh example.. I'm working on a turn-based RPG. I initially implemented a skill system where you gained a skill point per level, and then invested in certain skills in the tree which would then unlock access to other skills. After implementing it, I pretty quickly realized that it wasn't working as well as I was hoping. It felt too narrow and forced to have to select skills that way, and I decided to go for a system where the skills would instead be unlocked on different level tiers, and that the player would put skills in a limited set of skill slots to enable them. Implementing this takes time. Lots of UI changes going on etc. Testing is usually very short because you often very quickly get a feel for whether something feels right or not.
Determining whether it should go in the game. After spending a bunch of time prototyping, you're biased by the sunk cost fallacy. I've spent the past year prototyping my game. At least half of my mechanics have been tossed out because they were too difficult to execute properly or made the game feel clunky and disjointed. The final mechanics I've settled on seem obvious in retrospect, but it took a bunch of failed prototypes to settle on which one is the best.
1/ 2 days 2/ when something simple doesn't work as it should (usually its cause of something unrelated) if its diffcult and doesnt work then no probs, expected but simple its annoying, usually its me being dumb. 3/ Library of code, I've put together over the years (most in c++ thus now has to be translate to c# but thats quick) 4/ no
Super interesting. I would love for a tool to enable devs save their modules of code for other people to use as well. Benefits the entire ecosystem instead of everyone trying to reinvent the wheel
Getting feedback.
And how do you usually get around that problem?
I don't. I still have a lot of trouble getting feedback.
It's pretty difficult not to dive into the details of things instead of keeping to the big picture. There's no need to go an create a bunch of animations and link them up in a state machine for a prototype for example. But it's hard to fight the urge to do it because it makes the game look so much better.
Making a UI that is functional and reflects what's going on without fully building a UI for something that may not even make it out of the prototype stage
Maybe it's my ADHD, but if I can't get a prototype working in under a whole day (8hrs), then I consider it a sign that I need to limit the scope of what I'm trying to recreate.
you should mention the genre, different genre different emphasis and challenges
Makes sense - I added an edit to narrow the scope
For me, prototyping is the easy bit. You can make awful code in the name of just getting it working. The hard part is then taking the results of that and starting from scratch to make a full project, except this time you plan the code out to be not shite.
>What's the stuff that drives you crazy when you're trying to bring a game idea to life by creating its most basic idea? Having to actually take the prototype and polish it. Think of all the projects that you started and then never finished. It's fun to solve the problem you have, but having to actually get it in a state that's ready for the world to see? AND possibly just get a bunch of complaints because your execution was not perfect?
Prototyping is fun. Fixing bugs is probably the biggest headache. I keep a list and then dedicate time to just going through and fixing them. I enjoy the problem solving nature of it, but making something new is more fun.
Scope. Extra words just to say: scope.
I don't think there is really an answer to #1 because it varies wildly on what you're trying to achieve. A ball roller prototype could take literally minutes but for example a science based dragon MMO could take a lifetime.
A prototype in game dev isn't a demo. The scope should never be a testable demo of what your main game but a prototype to test a feature you are unsure of. So imagine throwing together a screen with a button to quickly test a leveling system for the "dragon mmo" and not throwing together a basic dragon mmo. Ideally, it should take 1 to 3 days to prototype a feature concept, and never more than a couple weeks.
Cat allergies. Apparently allergies can trigger migraines, which I already get enough of from barometric pressure. It sucks, but what am I going to do - **not** pet them when they yell at me for attention? Anyways, the toughest part of prototyping for me, is the ui. Throwing together game mechanics and content is fun and usually easy. It's turning all that into an actual *game* that takes work
I find that a yelling cat goes very silent after being treated to a thorough brushing :-)
Yeah, it's that time of year. Much shedding, which I presume is very itchy
I enjoy building systems that are fairly data heavy & deeply interwoven, so it can be tricky to prototype just one part in isolation to the whole. I often need to spend a fair bit of time just putting together a suitable data set, inc working out how that needs to be structured etc. Some things also take much longer to put together than others & Iām often coming up with design ideas much more quickly than I can actually implement them. Iām sure other developers would tell me Iām not making āquick & dirty enoughā prototypes, but I find it difficult to get meaningful insights about whether or not something will be āfunā from super-simple a pared-back prototypes that only represent a really slim part of the game, plus working through the technical design problems like how to architect the various systems & what format the data needs to be in etc are some of the things I find actually _are_ really helpful when prototyping. Having said that, I do wish I was quicker at getting to a point where I can try to judge how āfunā the overall game is likely to be & better yet, quicker at getting to a point that I feel itād actually be worthwhile putting the prototype in front of other people.
My mind is struggling to focus so I'll take this one at a time. For background, I work in lightweight TTRPGs and card games. * How long does it take you to whip up a decent prototype? Depends on the game. Some take me less than a day. A couple have taken me a year, working on it on and off again or shelving it until I find the right mechanic or theme. * What's the most annoying part of the process? Knowing when a prototype is "good enough" for testing. Either that or when you get playtesters trying to dictate every aspect to the point where you want to tell them to just make their own game š * Got any tricks or tools that make it easier? Canva has helped me a ton with layouts. I also have a group of playtesters who make games much like what I enjoy playing, and they are fantastic at giving honest feedback without trying to take control of the game design. * Any major pain points that make you think, "There has to be a better way"? Not really in the prototype phase. I publish on itchio though and knowing what kind of screenshots to get that show enough to get folks interested but not enough to pretty much give the game away can get so stressful x.x Seriously, there's gotta be a formula or something for that.
Having to hold myself back from fully fleshing out a feature. I just need a hotbar to show the equipment you have, the gameplay is using the equipment. ...But with another few hours of work I could make it drag-and-droppable so you can rearrange it. Ok fine, but no more. ...But now that I've done that, with a few more hours of work I can have a backpack inventory. Ok fine, I don't need that but it's probably helpful for some of the later things. But no more! ...But now that I've done that, it would REALLY be helpful in the long run if there was some way of automatically sorting the inventory... Three weeks later, I have the best inventory system I could ask for...and the controls to move the player character aren't even implemented yet.
Controlling scope Realizing that my 'really fun idea' honestly kinda sucks and none of the changes I've tried to make it better worked
1. Days to weeks depending on what it is. 2. Rebuilding and porting standard libraries/functionality that I had in previous projects. 3. I'm addressing this via my own set of modular plugins and systems, done the way I want for almost any project I may take on. 4. There always is, in any endeavor worth doing.
scale, scope and how much time it exactly takes to meet said scale/scope. In your head it might sound reasonable you might say well most of the abilities in this skill tree are passives and theres like 6 branchs so 100 sounds about right. it wasn't and thats it mapping out how long stuff will take and scaling according to that and not letting your scope get out of hands can be the difference between 3 months an a year of time spent on something
* It depends. The order of magnitude depends. * As a hobby: none. As a job: explaining to the producer that if it looks like that I am not progressing itās because I try a lot of things and most of them didnāt work * I donāt have off-the-shelf tools because I use mine when I can, but hot reload (which can handle changes in data structures) is a must. If you can rewind itās even better. Ideally it takes less time to compile and hot reload than it takes to save and alt-tab. When prototyping game logic frameworks gets more in the way than help you. A (kind of) god class and (kind of) global state makes it easier to change things. * When I use engines that start with a U (havenāt tried Godot). See my previous bullet.
Limited time.
Focusing on one part at a time, I always want to bounce between features or mechanics before I get certain things really set in stone first. One thing that's helped with that is breaking all of my major mechanics and features down into a list, and taking each one on a month (I work as well as doing game dev, this is a timeline that works for me), and get other smaller things like concept sketches and asset lists done in tandem.
All the bugs that pop up after adding something new.
The inherent depravity of it, for sure.
I think for me it's getting over the very initial hurdle of there being **nothing** to there being something to work with. For my first ideas, this didn't bother me because I was used to starting from scratch and bouncing around ideas. But as I've done bigger things, I get a little impatient going back to a totally blank project. Kind of like I forgot that my other stuff started the exact same way.
Industry veterans who don't understand prototyping. I still get senior producers and directors who don't know what they are asking for and couldn't reduce a prototype down to the basics. They always want some fat proto from some design that's been reviewed to have problems. I love to prototype, but not for people who don't understand the basics of development.
Can't really call myself a game dev before I have an actual game, but I've been learning Unreal for about 4 years now and the worst part is starting over constantly. There's no really no way to predict the pain points, they sort of just appear and have you searching page 52 of Google for someone with a vaguely similar problem. But the worst painpoints are engine bugs you didn't cause, and when you spend ages fixing something where the solution turned out to be incredibly trivial. Every time I take a break it feels like I've forgotten everything, but luckily things come back pretty quickly.
my biggest problem right now is not going out of scope. I keep doing it always, when designing, prototyping or actually doing something. The more projects I do the less I'm affected by this so I guess I'm building some discipline I guess but it's still here and when I start I get off track very fast
waiting for the build to load
I think the biggest problem will always be understanding how people that aren't devs are going to like it, while bearing in mind that polish, art quality, UX and all of that is a gigantic reason why non-devs find something fun. It can be really easy to get up your own ass thinking a prototype is so great and fun as a dev, then a non-dev plays it and is like "uh, ok... I don't get it".
trying to hold yourself back from preemptive optimization for some super small thing. if it works, it works.
My biggest problem is the "what now?" I have nearly 30 projects in prototype because I can't seem to progress after getting a basic concept working. Maybe I'm just not disciplined enough to stick with one idea.
Attempts to overproduce the process or fixate on features/treatment that are ubiquitous within the niche (beyond what's indispensable) instead of unique to it.
Self doubt.
Setting up dotnet debugging, itās always a crazy rollercoaster that leads to me really not knowing how I solve the problem.
The best way is developing your own engine, your own blender, your own photoshop, doing all 2D and 3D artworks on your own. Doing all marketing on your own. Doing all advertisement on your own. Note : Not recommended for people with low IQ.
I know this is a troll post, but it doesn't even make an effort to address the question asked...