Here is the substack post: heartgamedev.substack.com/p/production-point Here is the book: courses.heartgamedev.com/p/my-downloadable-87616?coupon_code=UA-cam_REF
Nintendo actually uses this exact approach for most of their in-house games. They have teams who just develop game systems with no planned products to use them. When they come across something fun then the senior staff decide what franchise would make best use of that gameplay, then the product is developed around those systems. This approach seems to be the legacy of when Nintendo was a toy company as that industry does a lot of prototyping for toy concepts and the best are chosen to go into production. This method is why we have Splatoon. If you ever watched documentaries on its development you'll discover that the senior Nintendo folks loved the prototype but didn't feel that it fit with anything like Mario, Zelda, Metroid or any IP they had. But rather than discard it, they created an all new IP built around the gameplay - and so the Squidlings were born.
That is... legitimately interesting. I think this is why feel some game franchises can do with some "unguided" experimentation. A little time to play around with some ideas. Though I imagine that that can get expensive.
@@Donzy213 Not as expensive as starting with the idea for a game, then building systems around the idea before realising too late that the idea worked better on paper than in practice. Start with systems and build the idea around that gameplay. Quite often I've seen gameplay problems occur with clear solutions but the creators avoid those solutions because they don't fit within the aesthetic of their game idea.
@@KryyssTV yeah I can see that. I remember when I was working on a stealth game for an online Videogame development course it was difficult for me to conceptualize the game without the characters, graphics etc. But that was the point: working out the mechanics on paper can be an important exercise. Something that was reinforce in my Computer methodology class.
Exactly i find that really fascinating a big reason why Nintendo games can be so fun and deep at the same time is because they approach gameplay first and how it feels. If it dosent pass that stage then they dont even bother they build an entire game with those mechanics rather than coming up with a story point and having to jam gameplay alongside it.
This is a really smart take on project management. A lot of people get bogged down for example, in fine tuning graphics and content really early on, when they could drop in some ms-paint placeholders and focus on getting the mechanics done. Thats especially common in the RPG maker community, you can build an entire game with the standard assets and come back later and replace and refine them as needed. I really nenjoyed this video, would love to see more like this!
@@atlantic_love Usually any type of 2D games. The equivalent for 3D games would be something like "grey box" levels where you mostly use untextured cubes to rough in the level layout, check sightlines, and work out how to direct the player's progression through the map.
@@atlantic_love Are you implying that 2D games aren't "serious game development"? Or no serious developer would use MS Paint? If you're a solo developer and you're prototyping a 2D game, MS Paint is a perfectly adequate tool to use for placeholder art that doesn't cost $50/month like Photoshop.
@@timezonelafontaine4987 They aren’t serious. If I’m being honest, neither are 3D games. 4D games are adequate enough I suppose, but 5D is where it’s at.
I decide to make an arpg game using Godot, HeartBeast starts his arpg series literally the day after I begin. I get unmotivated, a few days later HeartBeast has a video about him feeling unmotivated and how he deals with that. I take a break and start thinking about how to manage my time and the project in general. Again, LITERALLY the day after, HeartBeast posts a video about it on youtube... Are you in my head or what? I swear if I ever finish the game it'll be thanks to you
I think, very important thing in solo developing is change of activity. When I code day after day, at some moment I get tired and my productivity is declining. At that moment I need to switch to writing music or drawing graphics. If I don't do that (like, I cannot draw graphics when I don't know where to use it), I won't be able to get any progress and will abandon the game for several months. That's not what I want, so it's important to always have possibility to switch between prototyping and production. It is sometimes very hard to finish something, if it is big enough. Not hard or complicated, just big.
I second the activity changing, but what destroyed any chance of me becoming a software developer is that I have multiple interests (fine art painting, programming) and I would switch back and forth between those. Obviously when you switch back and forth between a text editor and an easel it is very difficult to get back in that frame of mind again.
@@atlantic_love I'm a bit similar, I cannot stick to anything, it just stops being enjoyable for me, and I only began any of my projects because I really felt a strong compulsion to do so. If there is no more enjoyment, I just won't do it. Sometimes I even start working on yet another idea I have while 100% aware that I'm gonna just work on it for 2 weeks and drop it afterwards
@@atlantic_love I'm the same way, and I juggle multiple projects of multiple sorts all day long. What works for me is dividing the day up into two hour blocks devoted to specific tasks - long enough to get into that 'flow' but not long enough to get tired - and then switch. So from, say, 8am to 10am I'm writing a novel, from 10am to noon I'll be coding, take a break for lunch, then from 1pm to 3pm I'll be doing pixel art, then 3pm to 5pm maybe I'm doing marketing or working on a different project or doing some video editing. Keeps me busy, keeps me fresh, keeps me productive. (I've also tried breaking things up *weekly* - like project A on Monday and Wednesday, B on Tuesday and Thursday, bookkeeping/marketing/blogging on Friday, but this has seen mixed results.) The key is scheduling and being flexible enough to adjust when needed.
Awesome content Ben! Regarding the "when to switch to production phase", had you read Sprint? The Google's book about prototyping? There they mention something that really stuck to my head: - Each prototype should answer questions that must be known by the time of the actual production Things like "how players react to X mechanism" or "which GUI is more intuitive". So I think that when you have these important questions answered with a prototype, it's time for production
Yeah, it's about removing uncertainty. If a developer is really new to making games they should combine all those small sprints into a completed experience before moving to production because even the act of putting it all together may cause large issues for a new developer. If they have experience with stuff like that they may not need to. I've also come to the conclusion that calling phase 1 the prototyping phase is bad, it makes people assume that the phase is about making a prototype, but it's not, it's about making several prototypes and finding one that has removed nearly all the uncertainty. I think a common issue (one I've experienced myself) is committing way too soon to production when there are still large areas of uncertainty.
Really important: keeping files, assets, code-examples, design docs and workflow-steps etc organized. Projects often run into a complexity trap, where adding a new system or mechanic is exponentially more complex than in the early prototyping phase, simply because there are so much more files and dependencies to regard, a much larger codebase and unclear workflow in the asset pipeline.
Shoutout to the book “algorithms to live by,” you’ll get nuggets of wisdom like that (like the multi arm bandit problem). Definitely worth your time to anyone interested. Audiobook is great too.
It's good to note that if you're a hobbyist solo game developer with no desire to make money, you can do whatever tf you want! Just make games that sound cool to you without worry of making a successful hit or filling a space in the market.
I find this approach very useful phase 1: experiment and find a solid and fun "game loop". phase 2: complete levels, graphics, music, fix bugs, etc... Thank you
One critique I want to make and that you should address is, as a fellow solo developer, it’s really important for me to break up the monotony, working too long on systems or content production can really be draining mentally. On the other hand, alternating between content production and systems can really be fulfilling once you get into a sustainable rhythm. I feel like the most important aspect of making games, especially if you haven’t released any commercial games yet, is fostering your motivation and creative drive. If you are not fulfilled with your current project it is often too easy to switch to another project. Take this with a grain of salt tho as I’ve only released my first commercial game last year haha
Same way and I've been Youtubing for 9 years with 6k+ videos and 1.6k subs,Writing novels for 2 years with 1 released, been doing arts and TT/Video game dev for 1 year and music writing for a few monrths... Jumping between by works when I get bored of one, works great!
I feel like the first indicator that you’re ready for the production phase is when the prototyping slope reaches its limits. I can get caught up polishing my prototypes “game feel” forever, so I think that’s probably the first hint that it’s time to move on
@JahvaughnEllisidk, but most likely it's a diminishing returns kind of thing, where after working on the prototype for so long the changes and benefits are smaller and smaller over time.
This is solid advice! You know a solution is valuable when after you heard it, it seems obvious. I have previously experienced similar problems and come up with similar solutions, but you put it down very concisely and clearly!
One thing that really helps you learn proper planning of a solo project is to participate in game jams. You have limited time to get everything done, so in order to finish on time you have to learn really fast what's gonna help you progress & what's gonna slow you down. And when you're done with the jam, you can keep working on the project using the same methodology applied to a longer period of time.
Game jams definitely help you manage scope and decide what's important and what isn't, what can be cut and what the core features are vs nice to haves, that's a reaaaaally useful skill for a solo gamedev. That said, planning and executing over a long period of time (months, years... decades?) is a whole other skill. They compliment each other.
Discovered this naturally while working on a game. It's nice to have a system put into words so I can better understand the flow. Thanks for making this!
As a learning solodev with a bad habit for leaving or forgetting projects, starting a new project... this video has helped me think about prioritising what I need to focus on and what can be done later in development Thanks for keeping the gears in my head turning!
Thanks for clearing up in my face attic. I was already doing most of this intuitively, but more in a jumbled messy way, really great to see it all clearly laid out like that. That should really help.
It's great to see you here 😀. This is an amazing advice on management, and I'll probably apply this to my game development process (solo dev here). And I would definitely buy this book. Thanks!
Your videos are so great, man. They inspired me to start my solo-dev journey and they continue to inspire me. Thanks for all you do, looking forward to your stuff coming out!
This is really helpful. Thank you for clearing up my mind. I love the point about being playful with the prototype phase, sometimes I really spread myself thin by aiming for polish when prototyping.
Ben is the only game dev teacher on youtube that speaks in a way that works with my brain. He is just verbose enough but not so much that I get lost and not so little that I can't grasp the concept.
You really helped me get over a mental block with this. Extremely valuable take on project management.
2 роки тому+6
Wow, this is exactly what I was looking for. I'm graduated in Game Design, but there we used to create games in groups. They haven't teach any solo game dev methodologies, strategies, frameworks, etc. Thanks very much for this video! Subscribed to your channel.
This is very useful. Thanks. one thing I might add from my experience as solo developer is that in prototype phase you may also need to prototype your production pipeline. Depending on the sort of art assets you are using, it may be a serious endevaour to figure out how or if you'll be able to produce the content you need, and so you need to actually go through the process of making that stuff to ensure you'll be able to survive the production phase. And so if you have to do a bit of that, then you sort of end up making a vertical slice by the end of your prototype phase - that is, you have a good bit of "finished" art ready, anyway. Obviously it depends on your games art needs. If you are relying on bought assets and wont need to make things on your own, you probably wont have to spend time validating production pipeline liek this.
11:14 that startled me when you mentioned rpg maker, i picked your video to take notes on specifically bc a friend recommended them to me but i was feeling a little lost on where to start! thank you for making this video i feel a bit more confident now
wow, what a perfectly concise and helpful video. understanding where to put your energies at every stage is most of the battle but the way you explained it makes it seem intuitive.
Wow, I was just describing the "super position" feeling to a friend earlier this week. You really helped me diagnose why I was in that state, and what design issues I was having.
This is a great video, helped me realise that I'm in the prototyping phase on my project and dipping into production a bit too much. It seems much clearer how I should manage it now, thanks very much! :D
The comparison between work modes expressed as exponential vs linear effort/reward is wonderful. Even a large long-term project could benefit from clearly transitioning between these prototyping/production modes at a regular interval.
Such a boss I resonate with everything in this especially that superposition stage. Thanks Benjamin, can't wait for more on this as a solo dev very insightful, and clearly experienced based insights you're sharing.
This is quite helpful. I think I’m gonna try and mess around with different game mechanics and try to find something fun and then build an idea onto that game mechanic
REALLY great info. I'm a self taught database developer who moonlights picking up gigs on upwork, and I just don't have any training with managing projects at all. I've been doing it by the seat of my pants for 20 years, but I recently landed a bigger contract and I'm drowning in managing it to the point where every time I sit down with it I just stare at the screen not knowing what to do next. Your concepts are applicable to general programming. I can kind of cross apply most of this, but I would love to see another video where you abstract this out and maybe even talk about tools that help you manage everything.
Thanks so much for this video. Project management is a very complex discipline. After investigating several approaches none seem to really fit with the process of solo game development. Agile for example has been tremendously hard to apply because of the months and months of no "releases" as such. It was about time someone took a good look at how to better organize this type of workflow. I would be very interested in a book if you decide to write it!
This has been a huge battle for me in every single project. I don't know how to create a good plan to follow either. I get inspired and jump straight to coding it which is fun until it's not lol and not the right way to go about it from a business standpoint. I was just last week able to identify why all my projects stop and this was it. This and separating classes and systems with good communication between them. Great video hope you and the family are well.
As someone looking to test their capabilities and not being sure where to start this video is really helpful as overview for a clearer start point and progressive goals, very helpful, thank you!
my game is currently WELL into that superposition, and I am currently scrapping what was going to be for a way more structured and planned out base gameplay style etc. This video helped me out for when I need to transition my game from prototype to polish and production!
I really enjoyed the presentation and clear explanation of this concept. I find it very useful to clearly see the line between both the prototyping and production phases :) Thank you.
Enjoyed the video. It's a simple idea once it's understood. I related to the issues brought up about not having a defined separation between prototyping and production.
I was just thinking to add vertical slice to this as a transition between prototype and production, And I see you mention that in the book. I'll def pick up the book. So far I think goals for developement are rough prototype, vertical slice and then finished product.
Absolutely incredible video. I have struggled in this exact point during game development and was unable to articulate why and how to fix it but I believe that this video has just done that.
When i released 1 game i waited for my first donation but i got nothing and now i made 3 and i got my first donation The tip is : - Dont wait for progress just it will come gradually - concentrate on one game and when you finish it make a new game Dont start a new game without finishing an old one - a good start will get you a good progress so release the game better from the 1st time
Great video! I never looked at development this way but it makes so much sense. I've had moments where I'll be making content along side a system causing me to go back and forth and not getting much progress done. The distinct attitudes to have for prototype and production that you mentioned make having consistent progress attainable. Thanks for sharing!
This is an amazing video. I would say only 3% of videos on UA-cam really make me go "wow, that was really good" and your video did exactly that. Keep up the good work.
This is very very helpful! Thank you. You hit the nail on the head. If you have not heard of Mark Cerny's "Method" (youtube the DICE talk from early 2000's), they are similar sentiments in that as well that could be good additional reference.
The main problem with my projects is getting assets which is what makes my production phase more longer and the other problem is I dont have deadlines which actually makes me work less everyday instead of actually working for hours on it when I could. These points made me realize deadlines and pre planning is very important to actually reach a goal and complete a game.
Handy Thanks. I didn't know you still made tutorials online. I bought your ebook years ago and LOVED IT but sadly I lost the file and couldnt re-download the pdf because I couldnt find the link again but the ebook was awesome and I would very much like to be able to redownload it again somehow.
This is an amazing articulation of a problem which commonly plagues the average indie developer, perhaps with many of us not even aware of it. Thank you so much for making this video!
This approach is perfect to me, when I saw the first question in the faq section I realized how to separate prototyping and production in my game, which is a roguelike, so is quite hard to leave the first phase. Great video as always! I've been into Godot watching your action rpg tutorial and never left it since, I'm very grateful for your content!
Great content. Reflecting on it, I realized that I already did many of these things subconsciously - different mentality, different focus and trying to keep the two kind of separate. One point I wouldn't agree with is the graphs; I feel like (at least for me) adding new systems doesn't tend to spike up in effort exponentially. What does tend to go exponentially in effort is adding _depth_ to the systems (compare simple character controller with a very well-developed one; in couple of my pet projects I've spent combined several month developing a controller)
OMG this helped me out quite a bit. I am really new to making any games that I wanted to bring out, but I needed to figure out how to actually start. I have been in the stuck for many many years on this game unsure where to start and what all to do. Though I did figure out more of the story aspect while in this phase. I did figure out a few things I wanted to do with it, but it is still a very much WIP at this point. Someday I want to see my game out, but it will be a good while since I am working on the story and everything myself. Thank you for making this video. I will try doing my best to set myself a deadline for things to be finished so I feel a bit more organized with it.
Thanks for this video! Definitely looking forward to anything else you release on project management as a solo dev or small team. I'm always trying to plan better mainly cuz when I'm unorganized I've noticed I lose a lot motivation in my projects. In fact, your point to separate the 2 focuses (prototype v prod) is really useful. Can't wait for the next vid!
Great Video! It took me several years to figure that out... I used to make everything in Unity and got so frustrated of not finishing my projects because I wanted to do everything at once and also perfectly. A few Months ago, I discovered that you can prototype on your Phone with JavaScript and html canvas, which basically means you can do it whenever and wherever you want. Now I can sit relaxed outside in the park and enjoy the sun while prototyping :) PS: Not sure if this is an actual valid strategy in the long run because I currently can only do it after Work. Sofar I'm only on my second prototype (partly because I also wrote half a Game Engine for it) but it brought me back the joy of Game Dev, so I thought I share it for inspiration :)
My timestamp may not be perfectmy timestamp may not be perfect Time: 0:00 Production Point Time: 0:27 Multi-Armed Bandit Problem Time: 2:40 Explore & Exploit Time: 3:12 Prototyping & Production Time: 3:56 Superposition Time: 4:16 Focus Time: 5:27 How to Scope? Time: 6:22 Mentality Time: 7:06 Feedback Time: 8:44 Graph Time: 9:43 Production Point Time: 10:14 FAQ I encourage to watch the whole video. this was for me to recap, hope this helps.
I've seen this video quite a while ago. It really affected how I work. Now I revisited it, and it motivated me yet again. I realize thay I will want to view this regularly. At least once a year! I say that about 0 other videos on UA-cam.
Treat your project the way you make a cake - even a virtual one Create a base - the biscuit, the bread - the base of your gameplay Then create fillings - cream and jam and stuff - add your personal touch to it Then coat it in icing smoothing out the surface - make it all work Then decorate it - and only then add flishy-flashies like sound design, music, effects, polish out the graphics and what not
This is incredibly helpful, I am brand spanking new to this, and I had a project that started as a fan game project and has evolved into a full blown personal project that has. Very little actually going for it right now. I have 10 notebooks floating around my workspace with plans and ideas and a tiny level with nothing but a basic greybox. Aiming for modular-openworld survival horror. I know what I want to happen, where I want things to go, and have good paper progress for levels. But I sit down in my workspace and feel flustered as to where to start - a lot of "well I need the inventory system coded" "yeah but I may as well start with the assets first" "yeah but what's the point of the assets without the code". I've come to the conclusion that I'm going to aim for a demo that *is* a fan game, figuring out all my coding and using the assets already present, and if everything works out well, continuing on with the original idea. Kinda feels like giving in and loosing progress, but it'll give me more time to work towards a bigger and better comercial product, I think.
I love the pace of this video specifically because I can comfortably listen to it in 2x speed - I do this all the time but there's finally a video where I don't feel like I'm missing content. I loved how simple your visual aids were - fantastic presentation and usage of the dividing line in the center. It kept our brain engaged to Prototyping on the left, and then Production on the right, which also enforces the order of these two phases based on simply how most of the world reads (left to right). Seeing the differences and graphs between the two phases alone helps motivate me towards development as I'm able to understand more about what phase I'm in, and can focus on the right features at the right times. Thanks for the great instructional video!
I love you. and i love this video, its so perfectly articulated what changes I need to make in my work. in fact i think this can be applied to development of other things, for example animation ( im an animator by study )
My current idea for adding RPG systems without needing a lot of content is having an adventure-quest style click-through menu where each beat of the game is available, complete with area enemies, location navigation, shops, and boss fights (and inns/any other buildings you may plan to have in your game like alchemy or whatever - just turned into collapsible menus for testing). This would allow you to test all the mechanics relevant to those things. You could eventually grow this click-through menu into the entire game and even add all of your story to a prototype version without needing a game world at all. Not even so much as a starting town/your mom's house (a la pokemon). This was just my first idea though, I'm sure proper developers have simplified this way more than I have XD
Excellent deliniation. I might add that, as boring as they can be to create and to use, unit test can be life savers for the prototyping phase and the transition from prototyping to production. With tests that make sure that the systems in place are working fine, you can catch very early on when you are building something that breaks the rest of your systems on a code level. Say you are creating a LootDrop system that goes on top of a damage dealer for enemies, and you somehow messed up something, it might take a while to see that you messed up, especially when testing just for fun you might be focusing on the feature you are building. With unit testing you just see the gauge go red and say "yep, something's wrong, I might want to do that differently". Oh and version your project for the love of you! Make feature branches for the prototyping and merge into dev or main when it's polished enough (and when it passes all of your unit tests ;) ) You'll feel even more free to go bonkers if you know you can just switch branch to go back to the clean project.
Thanks for a video. Your videos can support. They are insightful and your attitude is stoic. Although I was conscious about prototype / polish phases, in the retrospect I fell for the trap in the last year, polishing features that are then thrown away. On the topic: during the prototyping those exploration paths that are most uncertain must be explored first, I think. In a sense there can be a value metric to choose the next task - in the exploration phase it may be positively dependent on the uncertainty. In the exploitation phase I find it convenient to use some kind of agile methodology with frequent releases. So the most important tasks requiring the least effort should be done first. I don't follow a strict plan or timed sprints, but toss around tasks to make a release as soon as possible having the least possible amount of features. Thanks again.
Here is the substack post: heartgamedev.substack.com/p/production-point
Here is the book: courses.heartgamedev.com/p/my-downloadable-87616?coupon_code=UA-cam_REF
Nintendo actually uses this exact approach for most of their in-house games. They have teams who just develop game systems with no planned products to use them. When they come across something fun then the senior staff decide what franchise would make best use of that gameplay, then the product is developed around those systems. This approach seems to be the legacy of when Nintendo was a toy company as that industry does a lot of prototyping for toy concepts and the best are chosen to go into production.
This method is why we have Splatoon. If you ever watched documentaries on its development you'll discover that the senior Nintendo folks loved the prototype but didn't feel that it fit with anything like Mario, Zelda, Metroid or any IP they had. But rather than discard it, they created an all new IP built around the gameplay - and so the Squidlings were born.
That is... legitimately interesting. I think this is why feel some game franchises can do with some "unguided" experimentation. A little time to play around with some ideas. Though I imagine that that can get expensive.
@@Donzy213 Not as expensive as starting with the idea for a game, then building systems around the idea before realising too late that the idea worked better on paper than in practice. Start with systems and build the idea around that gameplay.
Quite often I've seen gameplay problems occur with clear solutions but the creators avoid those solutions because they don't fit within the aesthetic of their game idea.
@@KryyssTV yeah I can see that. I remember when I was working on a stealth game for an online Videogame development course it was difficult for me to conceptualize the game without the characters, graphics etc. But that was the point: working out the mechanics on paper can be an important exercise. Something that was reinforce in my Computer methodology class.
Exactly i find that really fascinating a big reason why Nintendo games can be so fun and deep at the same time is because they approach gameplay first and how it feels. If it dosent pass that stage then they dont even bother they build an entire game with those mechanics rather than coming up with a story point and having to jam gameplay alongside it.
That explains the diverse mechanics in Mario spinoffs
This is a really smart take on project management. A lot of people get bogged down for example, in fine tuning graphics and content really early on, when they could drop in some ms-paint placeholders and focus on getting the mechanics done. Thats especially common in the RPG maker community, you can build an entire game with the standard assets and come back later and replace and refine them as needed. I really nenjoyed this video, would love to see more like this!
What types of games could you put ms-paint placeholders in early in the process?
@@atlantic_love Usually any type of 2D games. The equivalent for 3D games would be something like "grey box" levels where you mostly use untextured cubes to rough in the level layout, check sightlines, and work out how to direct the player's progression through the map.
@@Zoyous Okay, so most serious game development wouldn't include putting in ms-paint placeholders?
@@atlantic_love Are you implying that 2D games aren't "serious game development"? Or no serious developer would use MS Paint? If you're a solo developer and you're prototyping a 2D game, MS Paint is a perfectly adequate tool to use for placeholder art that doesn't cost $50/month like Photoshop.
@@timezonelafontaine4987 They aren’t serious. If I’m being honest, neither are 3D games. 4D games are adequate enough I suppose, but 5D is where it’s at.
I decide to make an arpg game using Godot, HeartBeast starts his arpg series literally the day after I begin.
I get unmotivated, a few days later HeartBeast has a video about him feeling unmotivated and how he deals with that.
I take a break and start thinking about how to manage my time and the project in general. Again, LITERALLY the day after, HeartBeast posts a video about it on youtube... Are you in my head or what?
I swear if I ever finish the game it'll be thanks to you
Did u finish it?
@@IcedCub i guess we will never know :(
update us pls
Cringe
I think, very important thing in solo developing is change of activity. When I code day after day, at some moment I get tired and my productivity is declining. At that moment I need to switch to writing music or drawing graphics. If I don't do that (like, I cannot draw graphics when I don't know where to use it), I won't be able to get any progress and will abandon the game for several months. That's not what I want, so it's important to always have possibility to switch between prototyping and production.
It is sometimes very hard to finish something, if it is big enough. Not hard or complicated, just big.
wow thats clever when i was doing some coding later i was just drawing characters, background and never returned to it sadly
I second the activity changing, but what destroyed any chance of me becoming a software developer is that I have multiple interests (fine art painting, programming) and I would switch back and forth between those. Obviously when you switch back and forth between a text editor and an easel it is very difficult to get back in that frame of mind again.
@@atlantic_love I'm a bit similar, I cannot stick to anything, it just stops being enjoyable for me, and I only began any of my projects because I really felt a strong compulsion to do so. If there is no more enjoyment, I just won't do it. Sometimes I even start working on yet another idea I have while 100% aware that I'm gonna just work on it for 2 weeks and drop it afterwards
@@atlantic_love I'm the same way, and I juggle multiple projects of multiple sorts all day long. What works for me is dividing the day up into two hour blocks devoted to specific tasks - long enough to get into that 'flow' but not long enough to get tired - and then switch. So from, say, 8am to 10am I'm writing a novel, from 10am to noon I'll be coding, take a break for lunch, then from 1pm to 3pm I'll be doing pixel art, then 3pm to 5pm maybe I'm doing marketing or working on a different project or doing some video editing. Keeps me busy, keeps me fresh, keeps me productive.
(I've also tried breaking things up *weekly* - like project A on Monday and Wednesday, B on Tuesday and Thursday, bookkeeping/marketing/blogging on Friday, but this has seen mixed results.)
The key is scheduling and being flexible enough to adjust when needed.
Yeah that's reasonable, I'm trying to regularly switch between coding and modeling/texturing
Awesome content Ben!
Regarding the "when to switch to production phase", had you read Sprint? The Google's book about prototyping? There they mention something that really stuck to my head:
- Each prototype should answer questions that must be known by the time of the actual production
Things like "how players react to X mechanism" or "which GUI is more intuitive". So I think that when you have these important questions answered with a prototype, it's time for production
Yeah, it's about removing uncertainty. If a developer is really new to making games they should combine all those small sprints into a completed experience before moving to production because even the act of putting it all together may cause large issues for a new developer.
If they have experience with stuff like that they may not need to.
I've also come to the conclusion that calling phase 1 the prototyping phase is bad, it makes people assume that the phase is about making a prototype, but it's not, it's about making several prototypes and finding one that has removed nearly all the uncertainty. I think a common issue (one I've experienced myself) is committing way too soon to production when there are still large areas of uncertainty.
Your comment got liked 69 times.
Really important: keeping files, assets, code-examples, design docs and workflow-steps etc organized. Projects often run into a complexity trap, where adding a new system or mechanic is exponentially more complex than in the early prototyping phase, simply because there are so much more files and dependencies to regard, a much larger codebase and unclear workflow in the asset pipeline.
That's really important and something I'm beggining to understand more as I make my first shy steps in the field
Shoutout to the book “algorithms to live by,” you’ll get nuggets of wisdom like that (like the multi arm bandit problem). Definitely worth your time to anyone interested. Audiobook is great too.
It's good to note that if you're a hobbyist solo game developer with no desire to make money, you can do whatever tf you want! Just make games that sound cool to you without worry of making a successful hit or filling a space in the market.
I find this approach very useful
phase 1: experiment and find a solid and fun "game loop".
phase 2: complete levels, graphics, music, fix bugs, etc...
Thank you
One critique I want to make and that you should address is, as a fellow solo developer, it’s really important for me to break up the monotony, working too long on systems or content production can really be draining mentally. On the other hand, alternating between content production and systems can really be fulfilling once you get into a sustainable rhythm.
I feel like the most important aspect of making games, especially if you haven’t released any commercial games yet, is fostering your motivation and creative drive. If you are not fulfilled with your current project it is often too easy to switch to another project.
Take this with a grain of salt tho as I’ve only released my first commercial game last year haha
Agreed.
Same way and I've been Youtubing for 9 years with 6k+ videos and 1.6k subs,Writing novels for 2 years with 1 released, been doing arts and TT/Video game dev for 1 year and music writing for a few monrths... Jumping between by works when I get bored of one, works great!
This is the shortest 16-minute video I've ever watched. Thanks for the advice.
I feel like the first indicator that you’re ready for the production phase is when the prototyping slope reaches its limits. I can get caught up polishing my prototypes “game feel” forever, so I think that’s probably the first hint that it’s time to move on
@JahvaughnEllisidk, but most likely it's a diminishing returns kind of thing, where after working on the prototype for so long the changes and benefits are smaller and smaller over time.
This is solid advice! You know a solution is valuable when after you heard it, it seems obvious. I have previously experienced similar problems and come up with similar solutions, but you put it down very concisely and clearly!
One thing that really helps you learn proper planning of a solo project is to participate in game jams. You have limited time to get everything done, so in order to finish on time you have to learn really fast what's gonna help you progress & what's gonna slow you down. And when you're done with the jam, you can keep working on the project using the same methodology applied to a longer period of time.
Game jams definitely help you manage scope and decide what's important and what isn't, what can be cut and what the core features are vs nice to haves, that's a reaaaaally useful skill for a solo gamedev. That said, planning and executing over a long period of time (months, years... decades?) is a whole other skill. They compliment each other.
Discovered this naturally while working on a game. It's nice to have a system put into words so I can better understand the flow. Thanks for making this!
As a learning solodev with a bad habit for leaving or forgetting projects, starting a new project... this video has helped me think about prioritising what I need to focus on and what can be done later in development
Thanks for keeping the gears in my head turning!
Thanks for clearing up in my face attic.
I was already doing most of this intuitively, but more in a jumbled messy way, really great to see it all clearly laid out like that. That should really help.
People doesn't understand the importance of methods and ways of working! Thanks for helping people.
It's great to see you here 😀. This is an amazing advice on management, and I'll probably apply this to my game development process (solo dev here). And I would definitely buy this book. Thanks!
Your videos are so great, man. They inspired me to start my solo-dev journey and they continue to inspire me. Thanks for all you do, looking forward to your stuff coming out!
The scope aspect was particularly insightful, thank you.
This is really helpful. Thank you for clearing up my mind. I love the point about being playful with the prototype phase, sometimes I really spread myself thin by aiming for polish when prototyping.
Ben is the only game dev teacher on youtube that speaks in a way that works with my brain. He is just verbose enough but not so much that I get lost and not so little that I can't grasp the concept.
You really helped me get over a mental block with this. Extremely valuable take on project management.
Wow, this is exactly what I was looking for. I'm graduated in Game Design, but there we used to create games in groups. They haven't teach any solo game dev methodologies, strategies, frameworks, etc. Thanks very much for this video! Subscribed to your channel.
Thank you! Welcome to the channel :)
I really like the Valve process which mirrors a lot from this video. They put emphasis on play testing early and often.
This is very useful. Thanks.
one thing I might add from my experience as solo developer is that in prototype phase you may also need to prototype your production pipeline. Depending on the sort of art assets you are using, it may be a serious endevaour to figure out how or if you'll be able to produce the content you need, and so you need to actually go through the process of making that stuff to ensure you'll be able to survive the production phase.
And so if you have to do a bit of that, then you sort of end up making a vertical slice by the end of your prototype phase - that is, you have a good bit of "finished" art ready, anyway.
Obviously it depends on your games art needs. If you are relying on bought assets and wont need to make things on your own, you probably wont have to spend time validating production pipeline liek this.
Thank you for the great information. It is great that you are using project management methodologies while maintaining a simplistic explanation.
11:14 that startled me when you mentioned rpg maker, i picked your video to take notes on specifically bc a friend recommended them to me but i was feeling a little lost on where to start! thank you for making this video i feel a bit more confident now
wow, what a perfectly concise and helpful video. understanding where to put your energies at every stage is most of the battle but the way you explained it makes it seem intuitive.
I naturally discovered this approach in working on my latest project. This video has confirmed I'm on the right track with how I'm tackling things.
I'm considering solo dev-ing a game and this made a lot of sense and reminded me of a couple of my own videos. Cheers.
Wow, I was just describing the "super position" feeling to a friend earlier this week. You really helped me diagnose why I was in that state, and what design issues I was having.
This is a great video, helped me realise that I'm in the prototyping phase on my project and dipping into production a bit too much. It seems much clearer how I should manage it now, thanks very much! :D
The comparison between work modes expressed as exponential vs linear effort/reward is wonderful. Even a large long-term project could benefit from clearly transitioning between these prototyping/production modes at a regular interval.
Your "How to scope" section alone has solved the problems I always faced planning projects
Such a boss I resonate with everything in this especially that superposition stage. Thanks Benjamin, can't wait for more on this as a solo dev very insightful, and clearly experienced based insights you're sharing.
This is quite helpful. I think I’m gonna try and mess around with different game mechanics and try to find something fun and then build an idea onto that game mechanic
REALLY great info. I'm a self taught database developer who moonlights picking up gigs on upwork, and I just don't have any training with managing projects at all. I've been doing it by the seat of my pants for 20 years, but I recently landed a bigger contract and I'm drowning in managing it to the point where every time I sit down with it I just stare at the screen not knowing what to do next.
Your concepts are applicable to general programming. I can kind of cross apply most of this, but I would love to see another video where you abstract this out and maybe even talk about tools that help you manage everything.
This video so perfectly describes thw issues I've been having with the development process. I can't wait to apply this. Great video.
Thanks so much for this video. Project management is a very complex discipline. After investigating several approaches none seem to really fit with the process of solo game development. Agile for example has been tremendously hard to apply because of the months and months of no "releases" as such. It was about time someone took a good look at how to better organize this type of workflow. I would be very interested in a book if you decide to write it!
This has been a huge battle for me in every single project. I don't know how to create a good plan to follow either. I get inspired and jump straight to coding it which is fun until it's not lol and not the right way to go about it from a business standpoint. I was just last week able to identify why all my projects stop and this was it. This and separating classes and systems with good communication between them. Great video hope you and the family are well.
As someone looking to test their capabilities and not being sure where to start this video is really helpful as overview for a clearer start point and progressive goals, very helpful, thank you!
my game is currently WELL into that superposition, and I am currently scrapping what was going to be for a way more structured and planned out base gameplay style etc. This video helped me out for when I need to transition my game from prototype to polish and production!
A lot of good info, I have struggles with balancing workflow, and it's nice to have it broken down into a simpler process.
I really enjoyed the presentation and clear explanation of this concept.
I find it very useful to clearly see the line between both the prototyping and production phases :)
Thank you.
Its been 4 years since last time i watched a video in this channel and i still like that dude he’s a nice men
This is sooooo good!!! 🌟 Thank you! A huge trap that I fall into is making more content when the game isn't fun enough.
Enjoyed the video. It's a simple idea once it's understood. I related to the issues brought up about not having a defined separation between prototyping and production.
I was just thinking to add vertical slice to this as a transition between prototype and production, And I see you mention that in the book. I'll def pick up the book. So far I think goals for developement are rough prototype, vertical slice and then finished product.
I can thank you for this enough, the amount of hours and headaches you just saved me is unimaginable.
The exponential graph for Systems and Mechanics. Wow, thanks for pointing that out
MASSIVE value, thank you for debbunking the thinking process
Absolutely incredible video. I have struggled in this exact point during game development and was unable to articulate why and how to fix it but I believe that this video has just done that.
When i released 1 game i waited for my first donation but i got nothing and now i made 3 and i got my first donation
The tip is :
- Dont wait for progress just it will come gradually
- concentrate on one game and when you finish it make a new game
Dont start a new game without finishing an old one
- a good start will get you a good progress so release the game better from the 1st time
Great video! I never looked at development this way but it makes so much sense. I've had moments where I'll be making content along side a system causing me to go back and forth and not getting much progress done. The distinct attitudes to have for prototype and production that you mentioned make having consistent progress attainable. Thanks for sharing!
No one could have done this better. This is really helpful! Thank you so much!
This video was extremely helpful! Also looking forward to checking out your book. Thank you
This is an amazing video. I would say only 3% of videos on UA-cam really make me go "wow, that was really good" and your video did exactly that. Keep up the good work.
This is very very helpful! Thank you. You hit the nail on the head.
If you have not heard of Mark Cerny's "Method" (youtube the DICE talk from early 2000's), they are similar sentiments in that as well that could be good additional reference.
I'll check it out!
What the heck! This is talk so validating. It feels good to see an industry giant like this who feels so similarly to me about this.
The main problem with my projects is getting assets which is what makes my production phase more longer and the other problem is I dont have deadlines which actually makes me work less everyday instead of actually working for hours on it when I could. These points made me realize deadlines and pre planning is very important to actually reach a goal and complete a game.
best greeting ever "wherever and whenever you are" 😄 Nice content too.
Just four minutes in, and I can already tell this is a fantastic video on the subject
I definitely go back-and-forth between these phases.
Handy Thanks. I didn't know you still made tutorials online. I bought your ebook years ago and LOVED IT but sadly I lost the file and couldnt re-download the pdf because I couldnt find the link again but the ebook was awesome and I would very much like to be able to redownload it again somehow.
Send me an email and I can get you a link to download it again: heartbeast.studios@gmail.com
This is an amazing articulation of a problem which commonly plagues the average indie developer, perhaps with many of us not even aware of it. Thank you so much for making this video!
Thank you!
This is genuinely fantastic.
Great Video! I already have some takeaway that I will try to use in my next project. I think a book on this would be very helpful.
Thanks for making the video, it was useful and I look forward to you flushing it out to even the extent of a book.
Absolutely fantastic & practical method, thanks for sharing!
very nice video you are using. kind of related sidequestion: what kind of app/program are you using for your slide show?
This approach is perfect to me, when I saw the first question in the faq section I realized how to separate prototyping and production in my game, which is a roguelike, so is quite hard to leave the first phase.
Great video as always! I've been into Godot watching your action rpg tutorial and never left it since, I'm very grateful for your content!
Great content. Reflecting on it, I realized that I already did many of these things subconsciously - different mentality, different focus and trying to keep the two kind of separate.
One point I wouldn't agree with is the graphs; I feel like (at least for me) adding new systems doesn't tend to spike up in effort exponentially. What does tend to go exponentially in effort is adding _depth_ to the systems (compare simple character controller with a very well-developed one; in couple of my pet projects I've spent combined several month developing a controller)
thats some real project management gold here, have never thought about that yet
OMG this helped me out quite a bit. I am really new to making any games that I wanted to bring out, but I needed to figure out how to actually start. I have been in the stuck for many many years on this game unsure where to start and what all to do. Though I did figure out more of the story aspect while in this phase. I did figure out a few things I wanted to do with it, but it is still a very much WIP at this point. Someday I want to see my game out, but it will be a good while since I am working on the story and everything myself.
Thank you for making this video. I will try doing my best to set myself a deadline for things to be finished so I feel a bit more organized with it.
Thanks for this video!
Definitely looking forward to anything else you release on project management as a solo dev or small team. I'm always trying to plan better mainly cuz when I'm unorganized I've noticed I lose a lot motivation in my projects. In fact, your point to separate the 2 focuses (prototype v prod) is really useful.
Can't wait for the next vid!
This is by far the best solo dev suggestion video! Thank you
Very interesting to hear your perspective and approach to this, it seems effective and attempts to eliminate most problems, thanks!
Great Video!
It took me several years to figure that out... I used to make everything in Unity and got so frustrated of not finishing my projects because I wanted to do everything at once and also perfectly.
A few Months ago, I discovered that you can prototype on your Phone with JavaScript and html canvas, which basically means you can do it whenever and wherever you want. Now I can sit relaxed outside in the park and enjoy the sun while prototyping :)
PS: Not sure if this is an actual valid strategy in the long run because I currently can only do it after Work. Sofar I'm only on my second prototype (partly because I also wrote half a Game Engine for it) but it brought me back the joy of Game Dev, so I thought I share it for inspiration :)
My timestamp may not be perfectmy timestamp may not be perfect
Time: 0:00 Production Point
Time: 0:27 Multi-Armed Bandit Problem
Time: 2:40 Explore & Exploit
Time: 3:12 Prototyping & Production
Time: 3:56 Superposition
Time: 4:16 Focus
Time: 5:27 How to Scope?
Time: 6:22 Mentality
Time: 7:06 Feedback
Time: 8:44 Graph
Time: 9:43 Production Point
Time: 10:14 FAQ
I encourage to watch the whole video.
this was for me to recap, hope this helps.
I've seen this video quite a while ago. It really affected how I work. Now I revisited it, and it motivated me yet again. I realize thay I will want to view this regularly. At least once a year! I say that about 0 other videos on UA-cam.
Treat your project the way you make a cake - even a virtual one
Create a base - the biscuit, the bread - the base of your gameplay
Then create fillings - cream and jam and stuff - add your personal touch to it
Then coat it in icing smoothing out the surface - make it all work
Then decorate it - and only then add flishy-flashies like sound design, music, effects, polish out the graphics and what not
This is incredibly helpful, I am brand spanking new to this, and I had a project that started as a fan game project and has evolved into a full blown personal project that has. Very little actually going for it right now. I have 10 notebooks floating around my workspace with plans and ideas and a tiny level with nothing but a basic greybox. Aiming for modular-openworld survival horror. I know what I want to happen, where I want things to go, and have good paper progress for levels. But I sit down in my workspace and feel flustered as to where to start - a lot of "well I need the inventory system coded" "yeah but I may as well start with the assets first" "yeah but what's the point of the assets without the code".
I've come to the conclusion that I'm going to aim for a demo that *is* a fan game, figuring out all my coding and using the assets already present, and if everything works out well, continuing on with the original idea. Kinda feels like giving in and loosing progress, but it'll give me more time to work towards a bigger and better comercial product, I think.
this has answered a lot of questions for me. idk what to put here, I just wanna try to boost your engagement
this is really well thought out. great advice
Great observations about game design, but also project management in general!
Thanks for making me better at the Pokemon Game Corner with that slot machine intro.
I really liked your explanations, and it was all very relevant to my own experience going solo. very well done
Absolutely gold content, please return to form and post often HeartBeast
I love the pace of this video specifically because I can comfortably listen to it in 2x speed - I do this all the time but there's finally a video where I don't feel like I'm missing content. I loved how simple your visual aids were - fantastic presentation and usage of the dividing line in the center. It kept our brain engaged to Prototyping on the left, and then Production on the right, which also enforces the order of these two phases based on simply how most of the world reads (left to right). Seeing the differences and graphs between the two phases alone helps motivate me towards development as I'm able to understand more about what phase I'm in, and can focus on the right features at the right times.
Thanks for the great instructional video!
What I have learned: I am almost at production, But still have some prototyping to do, Thank you, This video feels useful.
I appreciate you. 🙃
Glad it was helpful!
geez this guy is good. I had to double-check that I wasn't paying for a college course. Thank you for not making us read 4 books before this Thursday!
Thanks. That was awesome. I will buy the book.
Thank you so, sooo much. I've been looking for a video like this for a while now and this is the most helpful! 😢
Such fun comprehensible content! Thank you :)
I love you. and i love this video, its so perfectly articulated what changes I need to make in my work. in fact i think this can be applied to development of other things, for example animation ( im an animator by study )
My current idea for adding RPG systems without needing a lot of content is having an adventure-quest style click-through menu where each beat of the game is available, complete with area enemies, location navigation, shops, and boss fights (and inns/any other buildings you may plan to have in your game like alchemy or whatever - just turned into collapsible menus for testing). This would allow you to test all the mechanics relevant to those things. You could eventually grow this click-through menu into the entire game and even add all of your story to a prototype version without needing a game world at all. Not even so much as a starting town/your mom's house (a la pokemon).
This was just my first idea though, I'm sure proper developers have simplified this way more than I have XD
Excellent deliniation.
I might add that, as boring as they can be to create and to use, unit test can be life savers for the prototyping phase and the transition from prototyping to production. With tests that make sure that the systems in place are working fine, you can catch very early on when you are building something that breaks the rest of your systems on a code level. Say you are creating a LootDrop system that goes on top of a damage dealer for enemies, and you somehow messed up something, it might take a while to see that you messed up, especially when testing just for fun you might be focusing on the feature you are building. With unit testing you just see the gauge go red and say "yep, something's wrong, I might want to do that differently".
Oh and version your project for the love of you! Make feature branches for the prototyping and merge into dev or main when it's polished enough (and when it passes all of your unit tests ;) ) You'll feel even more free to go bonkers if you know you can just switch branch to go back to the clean project.
Thanks for a video. Your videos can support. They are insightful and your attitude is stoic.
Although I was conscious about prototype / polish phases, in the retrospect I fell for the trap in the last year, polishing features that are then thrown away.
On the topic: during the prototyping those exploration paths that are most uncertain must be explored first, I think. In a sense there can be a value metric to choose the next task - in the exploration phase it may be positively dependent on the uncertainty. In the exploitation phase I find it convenient to use some kind of agile methodology with frequent releases. So the most important tasks requiring the least effort should be done first. I don't follow a strict plan or timed sprints, but toss around tasks to make a release as soon as possible having the least possible amount of features.
Thanks again.