Not sure if I missed it but I definitely recommend creating a git repository for your project ASAP in addition to doing manual backup copies. Using branches especially can be incredibly helpful for organising features as well as creating pseudo backups you can quickly revert your dev branch to if you mess something up.
Immediately when i complete a task, I save changes to the repo. As a beginner, it's extremely useful to just discard changes if I royally screw something up or don't like the changes I've made.
It makes sense if you want to implement a feature you never tried before (never tried in the way you implement in this new game). You don't want to learn how to implement inventory system while getting snagged due to attack state or some other unrelated bugs. Focus on keeping the scope small and start putting things together once you have a grasp of the feature you are implementing.
@@lHuskyyyea, that's what I do too. Just a completely different scene and scripts, unaffected by the rest of the game. At first implementing the system independently, then integrating it with the rest of the project. That should be enough. Creating a different project is just more time consuming and you'll have multiple windows open at once for no reason.
Yeah I was going to say that, it also is useful in the first stage of creating different projects... you could do one project, 1 branch per feature and then merge them together
YES! SOMEONE ELSE GETS IT FINALLY. Hokay... some small bits of input... 1) 6:12 "simplest final product" is actually called "minimum viable product" 2) 2:40 I 100% agree that you should separate features (aka prototypes) into their own files,... then you use that to see what was a good idea and what is a bad idea. I WOULD NOT jump from prototypes to MVP and you kind of say that too at 3:42... but it's not called a prototype, but a vertical slice. I would do a vertical slice first, which is just those features that make the cut and smush them together quickly and dirty to see if the features create good mechanics; And if it doesn't work well, then you'll know what features need to be cut and reworked. So,... prototype all the features and remake them until you get all the features that IN THEORY work well together, then do a VS to see if they actually play nice and could possibly be fun... THEN do your MVP. Again you sort of say this, but... yeah... a VS is really its own thing. ONE TIP TO THOSE THAT COULD USE IT, ALWAYS ALWAYS ALWAYS start your MVP/RC from SCRATCH... blank files and no previous assets. I've made the mistake of saying "well... hmm... this is good enough... I could make this work for the final game" and I 100% of the time get burnt on that. ALWAYS go from VS to MVP with a completely blank slate. 3) 6:54 it is SUPER IMPORTANT to use git for backing up your projects. It not only backs up the projects but allows you to track when bugs entered the codebase. "I swear this was working last week" gets a quick answer of a list of all the things you actually did between then and now, and you can quickly narrow down that went wrong. It depends on the project... some that had some high level of secrecy didn't make it into github or other SaaS B2B website stuff... but 99% of projects can be hosted by 3rd parties without anything of value being lost in the way of secrecy. that said, anything you upload ANYWHERE can get stolen and viewed by bad actors... it's literally a matter of time (even github recently... hackers figured out a way to see any code ever pushed there even if the project was deleted and no matter the level of authorization nor how hard it was password-ed). If you 100% don't want anything to get leaked out to the public, host locally or write your own kanban board and similar tools. In short, use git locally if you are worried about people reading the source code, and you can use any free git SaaS if that's not super important - in ANY CASE use one or the other - but at least one... That said, I love the video and it is the closest I've seen to someone actually saying it right.
I’ve watched a lot of game dev videos in downtime and this is the best solo dev video I’ve ever come across. It makes perfect sense to develop your systems in independent projects. Why didn’t I think of that?! Bravo ❤
I was shouting "use git!" the moment that folder of backup copies appeared and he didn't mention it. You can still make your backup copies now and then but please guys for the love of all that is good in the world, use version control.
Making a separate project for each feature without worrying how they would communicate or connect sounds exactly like what I need to stop overthinking and developing horizontally, so I can develop faster. Thanks for the advice!
Fantastic to see the roadmap you go through. In particular I like how you're making each mechanic in it's own prototype project. That's something I should look at doing myself.
I have been working on my first game this year and I can confirm that if you can learn the basic skills for coding/designing a game (which anyone can), the hardest part of Game Dev is staying organized and not jumping from task to task without completing anything. Notion has been a lifesaver and being able to dump all my ideas into a page has made it feasible for me to continue on my project!
I've been making games for over two decades in AAA and indie... your claim anyone can code and design a game is patently false. That's not to say that I wouldn't wish for you to be right (I wish for anyone who wants to get into game development, to do so and I wish them luck), but it takes time and dedication to do either of those things in any competent (albeit basic) ways, and to put it bluntly, not everyone can do that. And that's okay, just like how not everyone is an artist, nor everyone is a programmer, nor everyone is great with management, nor everyone is great with marketing, nor everyone is a musician, etc... it takes a team of very specialized and technically challenging skills to make games. And that's okay. That said, being mindful of the management side of things and to be organized is a huge skill to have as well, and is a big player in if you have a chance at actually finishing anything (ever) or not; so on that point you are very correct. You don't need notion or any specific SaaS to make great games, and usually they get in the way rather than just paper and ink... but however you plan, it's important that you do... like the old saying goes: those that fail to plan, plan to fail.
oooo trello is a new one! not heard of that before, exactly what ive been needing to manage my scattered brain as soon as i start a project >.< appreciate the videos too worm! youve been a fantastic learning resource through my learning of game dev stuffs
Trello is just a kanban. There are dozens of similar web based software (paid and free) out there.... but if kanban/trello is exciting to you, you might want to look at obsidian - especially if you say things like 'managing a scattered brain'. That said any type of kanban boards are great for lining up specific small goals... ideal for use with agile and scrum. But with all things, even pen and paper has its place.
I really like the idea of building each prototype systems separately, in my head I'm thinking you can then also build up a bit of a library so the next time you use next time you need a feature.
Wouldn't it be easier to just keep prototypes in separate scenes and folders than to have a whole project for each? Still work as if they're separate projects, but don't actually make them separate games.
About the different projects for different mechanics, i don't do exactly that, but if a mechanic is too complex, or it's too unique, i will create it as a separate project, if not, just different scenes will do the trick
Great video! Would love some elaboration on step 1 - how do we know what our core features will be? How coarse or fine should this be? I’m having a hard time deciding this. Advice?
Depends on the project. I do a lot of 7-day game projects, and day 1 is spent brainstorming. I think of all the features I might like... and then, because I know how much work I can get done in the 3 days I have to work on the mechanics, I figure out what I have time to accomplish. I would suggest doing some very small projects to get an idea of what you can pull off in your budgeted timeframe.
A couple of thoughts: The concepting stage is never over. Sure you can come up with something to start, but it always morphs into something else, even if the game is very similar to the original idea (I'll bet it isn't though in a lot of cases). Also, I would never create a different project for each feature because that makes everything 10 times harder, and causes a lot more cognitive load on a beginner (and a pro). A lot of the game will need to be integrated to work together, especially if you want to make a better game than most. Having 20 projects for different features just multiplies the issues you will have with each. What UI is there, what menu, backgrounds, and what art is used in different projects? It just makes tons more to manage and that is already a lot for most people with assets in one decent sized project. Make copies of your game if you must as a bare minimum, but again, this will cause a lot of confusion and if you don't name them very precisely it will be hard to know what code is where. It is far easier to use git for this as you can easily have incremental copies with the click of a button without storing all that on a hard drive that may die at any time too. Just makes no sense.
You must have missed the part where he said to take all the separate projects and combine them into a new one, the one that'll become your game. There is no multiplication of difficulty or increase in cognitive load. If you want to do this in another way using Git, nobody is stopping you. The idea is similar. It's just nice to be able to play with systems in isolation, knowing that there isn't another part of your game that's breaking that system.
@@smokelingers Nope, didn't miss that. I get playing with things in isolation, but the integration of all the things might be the more difficult piece to learn and this will prolong that happening and be more confusing especially for beginners. I'm a professional programmer and game dev, so I know how this goes down the road. It is not easier. Relying on a local hard drive ONLY is the way you lose years of your game dev progress because they do fail often. Git not only makes things easier but allows you to go back in time and see each change and how it affects your game and is the RIGHT way to do it, eventually. It may not be needed for a while when learning but making copies is a bad practice when there are better options. You could at least copy it to a Google Drive or dropbox, etc. Losing years of progress is how you stop being a game dev quickly. I know because I have to help people pick up the pieces of their lost data frequently.
To be fair, I don't just want to be critical, because I think DevWorm is one of the very best on RUclips, makes way more sense than most tutorials do, and is very accessible for new devs (and old ones like me). Just wanted to add my thoughts from experience on what might not be the best ideas. You can for sure do what you want, but I wanted to chime in, just in case it helps. If not, that's cool too.
@nrwl23 What you and I are talking about is not the same thing. Don't forget we're discussing the video. Nowhere in the segment about prototyping every system did the video mention that you mustn't use online version control, or that you must rely only on a local harddrive. Prototyping every system separately before you begin work on your game project and using version control to prototype how every system could work in your game are not the same thing. They achieve different results. And that's what you were initially talking about, the prototyping segment in the video.
Thank you for the video! I think it would be nice if you could add the game title on the footage of the games you show. For example, I really like the game at 0:43 but I can't find a name here EDIT: Ah sorry, you added the game titles on the other gameplay sequences. Then maybe 0:43 was just a mistake :)
Love your videos, I've tried to do most of this but I can see a few things you've presented that could improve my process. I still haven't completed a game. I'm coming close right now but I'm also thinking about abandoning my project because I just don't think I did a good job creating a game loop that's fun' I'm struggling to make my game fun. It's making me want to scrap it and move on to something else that will inspire me and hopefully seem more fun to play for me. I'm realizing I need to spend more time in the prototyping stage specifically. Figure out if the game is fun before moving forward with it. I love how you said to split up the prototype stage into multiple small prototype for each game feature. I think that's really a great idea. Anyway, do you have thoughts on abandoning a game? I've spent about 75-80 hours on my game so far. I'm making small scoped games but I'm guessing it would take another 40-60 hours to make it some I could call a game even if it isn't fun. Let me know what you think about scrapping a project?
Sir I know nothing about coding can I create my dream project with any engine like unreal and for some coding If I need then Lot of AI bots ate there in the market. Sir I know nothing about creating a game. But definitely I wanna create the best ever made in the battle royale area.Can you suggest me some detailed way to get that done.By the way thanks gor this video.
Thanks for the analysis! I have a quick question: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
For some people its a way to make small projects that they can then learn to mesh together in their more finished project. its fast and is a good reference if you need to go back and look at notes. each project is essentially notes on each mechanic that you can reference if you're having trouble remembering something. also its good for repetition. The more you do something the more you remember and the better you get. It also helps when you're going in blind on something and you're testing out a bunch of things, you don't have to worry about it messing up weeks or months of progress if you really mess something up if you can't revert it for some reason.
it just helps to make that big project less overwhelming as you are only focusing on each aspect completely separate of each other. But yes @akumitakasu, that is a really great explanation of it.
Can you make 2D Fish game tutorial? Just like Hungry shark world or any Fish eating other fish game Look simple to me, what do you think? Maybe use Basic control and getting bigger by eating other fish, the map is just Square with Sea background Game end if you got eaten by bigger fish and that's it
That is some interesting take on prototypes! I've been thinking about prototyping lately and came to an opposite conclusion - I don't think it's always necessary. Since primary goal of prototype is to test whether the idea/mechanic is going to work, it really doesn't make sense to waste time on prototype if you are making an already established and proven mechanics that are present in existing games. For example - there's just no point in testing celeste-like platforming gameplay. You just know that it works, and it will work for you if you do it the same way. The more you deviate from proven gameplay and go wild with mechanics the more prototype becomes necessary. So you might need to prototype a few really experimental mechanics that might get you doubting, but that's it.
I mean sure, unless you're just learning game dev and those mechanics might be normal for veteran devs, but for new devs... you have to start somewhere. I mean pick up mechanics are simple to you or me, but to someone else its not as simple. not only that reputation is how some people learn and the best way to do that is to do something over and over. you can't just add a pick up mechanic in your game and then do it again for repetition, but you can if you do it in another project then do it again while adding other mechanics into the game. Yes this is going to take longer but this vid isn't for people who have experience. It's for newer devs, most more advanced devs know what they are doing and works for them.
7:00 my strongest advice is use GIT and learn about creating branches. It will honestly be the best thing you ever do. Source: me a senor programming dev for 6 odd years.
Love the advice but 6 years is not that much. Not trying to bash you, I just really dislike people using world like senior, pro, veteran, etc, without actually being one. Discredits actual senior devs that have been coding since the young internet days or before. That’s a senior dev.
@RadOpsTV totally feel you. But that is my official job title, technically it is ' senior web application developer'. Prior to that I was a regular Dev for about 8 years. Not trying to be a douche and flexing.
@@nrwl23 it really does matter for some people though. this vid also isn't for people who have a bunch of games under their belt, its for newer people that are going to make mistakes and debugging is easier when you don't have unrelated things causing the issues. If the systems interconnect then yes that is good to have in one project, but an inventory system and a fighting system can be done separately and then combined later. Just because you can't manage to do this doesn't mean others cant, it doesn't give any headache, if anything when testing new things out, having other things interact with it in an odd way because you're testing things is way more of a problem. Multiple projects can also prevent unused code that you forgot to delete because you were testing. I'm not saying everyone should make multiple projects for one game, I am saying that if it works for someone, they should do it. There isn't a right or wrong way to prototype, and for new devs they should either make small games or multiple projects as its the best way to learn. Just because you like doing it one way, doesn't, mean that way is the best for everyone. that type of mindset is bad and doesn't help anyone.
i personally don't do it, i always push changes to main since i get to track only one project at a time. could be very useful for beginners that way but i think creating different branches is inefficient if you're the only one working on your project
Thanks dude, honestly I think your road map is too much theoretical, a lot of things can change depending on the game type and the way the brain of the developer work, such factors impact a lot on the needed steps for each game road map
the point of prototyping would be to try new ideas out quickly. Making art of any quality doesn't lend itself to that. Like shown in the video, even just rectangles are good enough to get the idea across and tested, which is the goal of prototyping.
so you want to make games? if you think its gonna take you 1 year, multiply it by 2 then multiply it by the times a day you think you are tired of studying game dev, then you get the amount of years you need to be good enough to make a game. lol
I wonder if you deliberately showed “Pingo Adventure” here, as the developers seem to have done little testing beforehand and don't always respond to critics / comments (on Steam). That's a real shame, you shouldn't betray the trust of the first players / buyers.
I hope this blueprint is garenteed to actually make progress and finish my game. I just feel stuck and not going anywhere on my tring to make my game in my Godot game journey.
Learning how to effectively use Kanban boards or a similar project management system / tool will do WONDERS for helping you progress on a project of any kind
Hoping This Video was Informative!!
The first 500 people to use my link skl.sh/devworm10241 will get a 1 month free trial of Skillshare premium!
amazing video as always :D
13:45
I might have mocks tomorrow but i sure ain't missing the finial product
man you saved a lot of solo dav thanks
Not sure if I missed it but I definitely recommend creating a git repository for your project ASAP in addition to doing manual backup copies. Using branches especially can be incredibly helpful for organising features as well as creating pseudo backups you can quickly revert your dev branch to if you mess something up.
You missed nothing. He didn't talk about git
He said to make actual copies of your project regularly. I almost couldn't believe my eyes and ears. Like... What?
Immediately when i complete a task, I save changes to the repo. As a beginner, it's extremely useful to just discard changes if I royally screw something up or don't like the changes I've made.
This is my first time anywhere hearing I need to make entirely different prototype projects for each system and I am absolutely not doing that 😅😂
this is what i’m doing 🤷🏻♂️ small tech demos focused on different systems/mechanics i want to learn.
Yea, I just make them on different scenes.
That’s because it’s a load of crap. Next thing he’s saying ‘never reuse an existing engine’.
It makes sense if you want to implement a feature you never tried before (never tried in the way you implement in this new game). You don't want to learn how to implement inventory system while getting snagged due to attack state or some other unrelated bugs.
Focus on keeping the scope small and start putting things together once you have a grasp of the feature you are implementing.
@@lHuskyyyea, that's what I do too. Just a completely different scene and scripts, unaffected by the rest of the game. At first implementing the system independently, then integrating it with the rest of the project. That should be enough. Creating a different project is just more time consuming and you'll have multiple windows open at once for no reason.
06:55 use git, use git, use git please. With branches for separate features ofcourse.
yes, I was going to comment that
Yeah I was going to say that, it also is useful in the first stage of creating different projects... you could do one project, 1 branch per feature and then merge them together
I too was going to say that, or at least use some other version control system.
very very very good point! thank you for mentioning that!
YES! SOMEONE ELSE GETS IT FINALLY.
Hokay... some small bits of input...
1) 6:12 "simplest final product" is actually called "minimum viable product"
2) 2:40 I 100% agree that you should separate features (aka prototypes) into their own files,... then you use that to see what was a good idea and what is a bad idea. I WOULD NOT jump from prototypes to MVP and you kind of say that too at 3:42... but it's not called a prototype, but a vertical slice. I would do a vertical slice first, which is just those features that make the cut and smush them together quickly and dirty to see if the features create good mechanics; And if it doesn't work well, then you'll know what features need to be cut and reworked. So,... prototype all the features and remake them until you get all the features that IN THEORY work well together, then do a VS to see if they actually play nice and could possibly be fun... THEN do your MVP. Again you sort of say this, but... yeah... a VS is really its own thing. ONE TIP TO THOSE THAT COULD USE IT, ALWAYS ALWAYS ALWAYS start your MVP/RC from SCRATCH... blank files and no previous assets. I've made the mistake of saying "well... hmm... this is good enough... I could make this work for the final game" and I 100% of the time get burnt on that. ALWAYS go from VS to MVP with a completely blank slate.
3) 6:54 it is SUPER IMPORTANT to use git for backing up your projects. It not only backs up the projects but allows you to track when bugs entered the codebase. "I swear this was working last week" gets a quick answer of a list of all the things you actually did between then and now, and you can quickly narrow down that went wrong. It depends on the project... some that had some high level of secrecy didn't make it into github or other SaaS B2B website stuff... but 99% of projects can be hosted by 3rd parties without anything of value being lost in the way of secrecy. that said, anything you upload ANYWHERE can get stolen and viewed by bad actors... it's literally a matter of time (even github recently... hackers figured out a way to see any code ever pushed there even if the project was deleted and no matter the level of authorization nor how hard it was password-ed). If you 100% don't want anything to get leaked out to the public, host locally or write your own kanban board and similar tools. In short, use git locally if you are worried about people reading the source code, and you can use any free git SaaS if that's not super important - in ANY CASE use one or the other - but at least one...
That said, I love the video and it is the closest I've seen to someone actually saying it right.
You’re one of the best worms on the internet, thanks.
awee so sweet! thank you!
Hi dev worm 🪱. Nice videos I have just come across your channel. Am not leaving. Nice content
Bruh your channel description. I know this is the right place. Godot is the best. And game dev is my favourite hobbie. Though am still a noob, for now
I’ve watched a lot of game dev videos in downtime and this is the best solo dev video I’ve ever come across. It makes perfect sense to develop your systems in independent projects. Why didn’t I think of that?! Bravo ❤
Aw thank you so much!! I am truly so happy you found it useful!
I was shouting "use git!" the moment that folder of backup copies appeared and he didn't mention it. You can still make your backup copies now and then but please guys for the love of all that is good in the world, use version control.
Making a separate project for each feature without worrying how they would communicate or connect sounds exactly like what I need to stop overthinking and developing horizontally, so I can develop faster. Thanks for the advice!
exactly the reason I do it lol!! it makes things so much less complicated!
Fantastic to see the roadmap you go through. In particular I like how you're making each mechanic in it's own prototype project. That's something I should look at doing myself.
thank you! but you 100% should!! It has really helped me out a lot!
I have been working on my first game this year and I can confirm that if you can learn the basic skills for coding/designing a game (which anyone can), the hardest part of Game Dev is staying organized and not jumping from task to task without completing anything.
Notion has been a lifesaver and being able to dump all my ideas into a page has made it feasible for me to continue on my project!
I've been making games for over two decades in AAA and indie... your claim anyone can code and design a game is patently false. That's not to say that I wouldn't wish for you to be right (I wish for anyone who wants to get into game development, to do so and I wish them luck), but it takes time and dedication to do either of those things in any competent (albeit basic) ways, and to put it bluntly, not everyone can do that. And that's okay, just like how not everyone is an artist, nor everyone is a programmer, nor everyone is great with management, nor everyone is great with marketing, nor everyone is a musician, etc... it takes a team of very specialized and technically challenging skills to make games. And that's okay.
That said, being mindful of the management side of things and to be organized is a huge skill to have as well, and is a big player in if you have a chance at actually finishing anything (ever) or not; so on that point you are very correct. You don't need notion or any specific SaaS to make great games, and usually they get in the way rather than just paper and ink... but however you plan, it's important that you do... like the old saying goes: those that fail to plan, plan to fail.
i like the idea that you break down the project into system and each system is a seperate project.
oooo trello is a new one! not heard of that before, exactly what ive been needing to manage my scattered brain as soon as i start a project >.<
appreciate the videos too worm! youve been a fantastic learning resource through my learning of game dev stuffs
I like using Codecks for the easy Discord integration.
Trello is just a kanban. There are dozens of similar web based software (paid and free) out there.... but if kanban/trello is exciting to you, you might want to look at obsidian - especially if you say things like 'managing a scattered brain'. That said any type of kanban boards are great for lining up specific small goals... ideal for use with agile and scrum.
But with all things, even pen and paper has its place.
Glad it helped and I’m happy you’re finding this stuff useful! If you ever have any questions feel free to let me know!
I really like the idea of building each prototype systems separately, in my head I'm thinking you can then also build up a bit of a library so the next time you use next time you need a feature.
thx! have been looking for a vid like this! The way i started was just diving in head first and then burning out after a month or so lol
haha yep that burnout will get you, its for sure gotten me a couple times. I hope this method is able to help you stay on track a bit better!
Thank you for your honesty. Subbed
aw thank you! just hoping the video helped!
Solid advice. I'm a big fan of the "prototype systems separately" one. It helps keep things organised and promotes code/asset reuse. 👍🏽
thank you so much!! and I couldn't agree more!
My man! Great job the video!
thank you so much, it means the world! I hope it helped!
Wouldn't it be easier to just keep prototypes in separate scenes and folders than to have a whole project for each? Still work as if they're separate projects, but don't actually make them separate games.
About the different projects for different mechanics, i don't do exactly that, but if a mechanic is too complex, or it's too unique, i will create it as a separate project, if not, just different scenes will do the trick
I like it, but yeah sometimes just opening up something fresh whether it be a project or a scene is just so much less overwhelming.
I've used both Hacknplan and Obsidian (with the kanban plugin) as alternatives to Trello. I've found they work well.
thanks for sharing!! Ill be sure to check them out!
Great video! Would love some elaboration on step 1 - how do we know what our core features will be? How coarse or fine should this be? I’m having a hard time deciding this. Advice?
Depends on the project. I do a lot of 7-day game projects, and day 1 is spent brainstorming. I think of all the features I might like... and then, because I know how much work I can get done in the 3 days I have to work on the mechanics, I figure out what I have time to accomplish.
I would suggest doing some very small projects to get an idea of what you can pull off in your budgeted timeframe.
@ thank you! That makes sense.
Great video, thy!
thank you so much!! I hope it helped!
A couple of thoughts: The concepting stage is never over. Sure you can come up with something to start, but it always morphs into something else, even if the game is very similar to the original idea (I'll bet it isn't though in a lot of cases). Also, I would never create a different project for each feature because that makes everything 10 times harder, and causes a lot more cognitive load on a beginner (and a pro). A lot of the game will need to be integrated to work together, especially if you want to make a better game than most. Having 20 projects for different features just multiplies the issues you will have with each. What UI is there, what menu, backgrounds, and what art is used in different projects? It just makes tons more to manage and that is already a lot for most people with assets in one decent sized project. Make copies of your game if you must as a bare minimum, but again, this will cause a lot of confusion and if you don't name them very precisely it will be hard to know what code is where. It is far easier to use git for this as you can easily have incremental copies with the click of a button without storing all that on a hard drive that may die at any time too. Just makes no sense.
You must have missed the part where he said to take all the separate projects and combine them into a new one, the one that'll become your game. There is no multiplication of difficulty or increase in cognitive load. If you want to do this in another way using Git, nobody is stopping you. The idea is similar. It's just nice to be able to play with systems in isolation, knowing that there isn't another part of your game that's breaking that system.
@@smokelingers Nope, didn't miss that. I get playing with things in isolation, but the integration of all the things might be the more difficult piece to learn and this will prolong that happening and be more confusing especially for beginners. I'm a professional programmer and game dev, so I know how this goes down the road. It is not easier. Relying on a local hard drive ONLY is the way you lose years of your game dev progress because they do fail often. Git not only makes things easier but allows you to go back in time and see each change and how it affects your game and is the RIGHT way to do it, eventually. It may not be needed for a while when learning but making copies is a bad practice when there are better options. You could at least copy it to a Google Drive or dropbox, etc. Losing years of progress is how you stop being a game dev quickly. I know because I have to help people pick up the pieces of their lost data frequently.
To be fair, I don't just want to be critical, because I think DevWorm is one of the very best on RUclips, makes way more sense than most tutorials do, and is very accessible for new devs (and old ones like me). Just wanted to add my thoughts from experience on what might not be the best ideas. You can for sure do what you want, but I wanted to chime in, just in case it helps. If not, that's cool too.
@nrwl23 What you and I are talking about is not the same thing. Don't forget we're discussing the video. Nowhere in the segment about prototyping every system did the video mention that you mustn't use online version control, or that you must rely only on a local harddrive. Prototyping every system separately before you begin work on your game project and using version control to prototype how every system could work in your game are not the same thing. They achieve different results. And that's what you were initially talking about, the prototyping segment in the video.
I personally have to stop conceptualizing when I move from pre-production to production, or scope creep kills me.
Still making my prodotype
how is it going?
@@dev-worm I got player done = movement done , the jump & double jump , dash !
Another banger from the king 🤴
haha!! thanks Kurt!! your support really means the world to me!
I just learned Godot for month now and I realize impossible for me to create those Majestic Game yet 😅
Thank you for the video! I think it would be nice if you could add the game title on the footage of the games you show. For example, I really like the game at 0:43 but I can't find a name here
EDIT: Ah sorry, you added the game titles on the other gameplay sequences. Then maybe 0:43 was just a mistake :)
ahh yes that mustve been a mistake, but the game at 0:43 was Paw Rescuers by Meh Studios!!
Love your videos, I've tried to do most of this but I can see a few things you've presented that could improve my process. I still haven't completed a game. I'm coming close right now but I'm also thinking about abandoning my project because I just don't think I did a good job creating a game loop that's fun' I'm struggling to make my game fun. It's making me want to scrap it and move on to something else that will inspire me and hopefully seem more fun to play for me. I'm realizing I need to spend more time in the prototyping stage specifically. Figure out if the game is fun before moving forward with it. I love how you said to split up the prototype stage into multiple small prototype for each game feature. I think that's really a great idea. Anyway, do you have thoughts on abandoning a game? I've spent about 75-80 hours on my game so far. I'm making small scoped games but I'm guessing it would take another 40-60 hours to make it some I could call a game even if it isn't fun. Let me know what you think about scrapping a project?
Actually great advices
glad to hear that! thank you!
Sir I know nothing about coding can I create my dream project with any engine like unreal and for some coding If I need then Lot of AI bots ate there in the market. Sir I know nothing about creating a game. But definitely I wanna create the best ever made in the battle royale area.Can you suggest me some detailed way to get that done.By the way thanks gor this video.
Thanks for the analysis! I have a quick question: I have a SafePal wallet with USDT, and I have the seed phrase. (alarm fetch churn bridge exercise tape speak race clerk couch crater letter). How can I transfer them to Binance?
Why separate the prototype?
For some people its a way to make small projects that they can then learn to mesh together in their more finished project. its fast and is a good reference if you need to go back and look at notes. each project is essentially notes on each mechanic that you can reference if you're having trouble remembering something. also its good for repetition. The more you do something the more you remember and the better you get. It also helps when you're going in blind on something and you're testing out a bunch of things, you don't have to worry about it messing up weeks or months of progress if you really mess something up if you can't revert it for some reason.
it just helps to make that big project less overwhelming as you are only focusing on each aspect completely separate of each other. But yes @akumitakasu, that is a really great explanation of it.
Can you make 2D Fish game tutorial? Just like Hungry shark world or any Fish eating other fish game
Look simple to me, what do you think?
Maybe use Basic control and getting bigger by eating other fish, the map is just Square with Sea background
Game end if you got eaten by bigger fish and that's it
That is some interesting take on prototypes!
I've been thinking about prototyping lately and came to an opposite conclusion - I don't think it's always necessary.
Since primary goal of prototype is to test whether the idea/mechanic is going to work, it really doesn't make sense to waste time on prototype if you are making an already established and proven mechanics that are present in existing games. For example - there's just no point in testing celeste-like platforming gameplay. You just know that it works, and it will work for you if you do it the same way.
The more you deviate from proven gameplay and go wild with mechanics the more prototype becomes necessary.
So you might need to prototype a few really experimental mechanics that might get you doubting, but that's it.
I mean sure, unless you're just learning game dev and those mechanics might be normal for veteran devs, but for new devs... you have to start somewhere. I mean pick up mechanics are simple to you or me, but to someone else its not as simple. not only that reputation is how some people learn and the best way to do that is to do something over and over. you can't just add a pick up mechanic in your game and then do it again for repetition, but you can if you do it in another project then do it again while adding other mechanics into the game. Yes this is going to take longer but this vid isn't for people who have experience. It's for newer devs, most more advanced devs know what they are doing and works for them.
What games is playing in the background in the foundation stage section? 0:40 - 0:55
What game is it at 9:29? It's mislabeled as Daisy Dangerous.
That game is Gourdlets. It's super fun.
4:51 game name?
Y not just use some version control like git on 7:00? So you don't waste so much space on your disk.
you are right, that would probably be much smarter. I will most likely switch to that method soon! thanks for letting me know!
Where can we buy your game(s)?
7:00 my strongest advice is use GIT and learn about creating branches. It will honestly be the best thing you ever do. Source: me a senor programming dev for 6 odd years.
Love the advice but 6 years is not that much. Not trying to bash you, I just really dislike people using world like senior, pro, veteran, etc, without actually being one. Discredits actual senior devs that have been coding since the young internet days or before. That’s a senior dev.
@RadOpsTV totally feel you. But that is my official job title, technically it is ' senior web application developer'. Prior to that I was a regular Dev for about 8 years.
Not trying to be a douche and flexing.
@ ah okay, I get you that’s definitely valid then.
I thought it was crazy to build each part of my game on a separate project first. Glad to know that it was a good choice. Thank you 🙏
No it isn't a good idea. You are just giving yourself more headaches. One project or multiple doesn't matter really. Debugging is not easier that way.
@@nrwl23 it really does matter for some people though. this vid also isn't for people who have a bunch of games under their belt, its for newer people that are going to make mistakes and debugging is easier when you don't have unrelated things causing the issues. If the systems interconnect then yes that is good to have in one project, but an inventory system and a fighting system can be done separately and then combined later. Just because you can't manage to do this doesn't mean others cant, it doesn't give any headache, if anything when testing new things out, having other things interact with it in an odd way because you're testing things is way more of a problem. Multiple projects can also prevent unused code that you forgot to delete because you were testing. I'm not saying everyone should make multiple projects for one game, I am saying that if it works for someone, they should do it. There isn't a right or wrong way to prototype, and for new devs they should either make small games or multiple projects as its the best way to learn.
Just because you like doing it one way, doesn't, mean that way is the best for everyone. that type of mindset is bad and doesn't help anyone.
i personally don't do it, i always push changes to main since i get to track only one project at a time. could be very useful for beginners that way but i think creating different branches is inefficient if you're the only one working on your project
This video was informative, but the music was too quiet.
Finially
How much of your time is spent making games vs playing them would you say?
unsure to be honest, I for sure spend much more time making games then playing them though!
Nice ads transition lol, anyways, i think im gonna continue my game now, without combining the game development and blueprinting.
also, finial.
Comment and favorited.
thank you so much!! it means the world!
Thanks dude, honestly I think your road map is too much theoretical, a lot of things can change depending on the game type and the way the brain of the developer work, such factors impact a lot on the needed steps for each game road map
Hi dev worm i have a question
yes what is the questions? I hope I can help!
The prototype do not have art?
Art isn't important in prototypes. Hence "Programmer art."
the point of prototyping would be to try new ideas out quickly. Making art of any quality doesn't lend itself to that. Like shown in the video, even just rectangles are good enough to get the idea across and tested, which is the goal of prototyping.
it isn't important, prototypes are mainly just to get those features working together!
wait Godot? that didn't look like C# tho..
so you want to make games? if you think its gonna take you 1 year, multiply it by 2 then multiply it by the times a day you think you are tired of studying game dev, then you get the amount of years you need to be good enough to make a game. lol
I wonder if you deliberately showed “Pingo Adventure” here, as the developers seem to have done little testing beforehand and don't always respond to critics / comments (on Steam). That's a real shame, you shouldn't betray the trust of the first players / buyers.
Oh no, I actually didn't know that happen. Thanks for letting me know that is really interesting!
I like your music.
aw thanks lol, it is Island Dream by Chris Haugen!
Can you make a tutorial on how to make a jetpack?
I hope this blueprint is garenteed to actually make progress and finish my game. I just feel stuck and not going anywhere on my tring to make my game in my Godot game journey.
Learning how to effectively use Kanban boards or a similar project management system / tool will do WONDERS for helping you progress on a project of any kind
@@jak3legacy Thanks for the recommendation, I'll definitely try it out
I hope it will!! But like @jak3legacy said, organization and task management is so crucial