@@247BrettzleAnd I can tell you, as a game developer myself, that the Early Access graveyard is maybe about 1% the size of the collective wasteland of abandoned projects on countless hard disks.
Doesn't apply to just video games, but everything else in life when learning a new skill. You start off sucking at something before you become decent at it.
It's true for literally everything in human existence. The fact this isn't the baseline approach for some people is what's wrong. Overconfidence is a heck of a drug.
It's not so much overconfidence. I have spent 30 years thinking I lacked any ambition or drive. Turned out I was being a perfectionist, holding myself to absurd standards I could never dream to meet - and not being aware of it.@@GruppeSechs
"What can you make in a week?" That's why the 7 Day Roguelike (7DRL) challenge exists. If you only have a week, it means you need to have a compact and focused design. Build a core thing that's fun. Once you're done, you can choose to add to it if you want, but at least you have a core that you can build upon.
and anyone doing that challenge (I would assume) has already done at least many "small games" before, meaning that this is a challenge mainly about time constraints, not knowledge/experience. As you say, great for focusing the mind on a "key mechanic".
@@paulmdevenney it's not just good for people who have done many small games before, it still applies to these new people, cause the hardest part about making games is keeping the scope small without constantly wanting to add things. So having a time constraint forces you to keep it small within your means.
@@TwoWayOrbitalStation however, early projects will be subject to learning the tools which cannot be done in a very short time and will obscure the purpose of designing the game
@@MagicGonads Exactly. I mean it is fair to say that you could get all the assets from the free market places and that you can make it as simple as possible so that an average joe could learn a lot on the way. This challenge is otherwise as you state for people with an already established rather intermediate skill-level. But OP is right, that this would be a good example to learn to focus and organize themselves. With a good tutorial working with accessible and easily set up framework/engine/pipeline at hand you can follow through several times it might be possible to get someone ready within weeks to tackle the challenge. With an established pipeline or even a fundamental understanding of Code or Design you can make a lot. This is why game jam exists. I would also add "What can you do in 6 Months?" or "What can you learn in one year?".
You mean spend 6 days trying to do something and then realise your scope is for 7 months, not days, only have 1 day left and you can't turn it into anything playable?
As a former Senior Software Engineer (22+ years), I can attest that this is exactly how I approached large projects. Both when on my own and when with a team. The deliverable was broken down into many small parts and those were each fully developed and debugged before integration into the system. Then whatever additional issues that would crop up would be resolved before adding in anything new. Works a charm and results in some pretty robust software. :) Learning new system is exactly the same. New languages traditionally start with the ubiquitous "Hello World" application. And then continue with small, incremental additions to the new programmer's toolkit. A superior way of learning compared to the 'throw them into the deep end of the pool' methodology.
That is the next hurdle, make sure those tiny pieces actually fit together. I find the game industry have no clue what balancing is. They just want to keep adding ideas at any cost.
For experience I can tell you, as cool as it is looking at the more advance stuff, you will never be able to properly understand it without good fundamentals of anything before that Just learn the small pieces and try to enjoy the process and you will be able to do more advance stuff before you can even realize it
I definitely agree, but I also think jumping into the deep end can be a good way to figure out what you should learn next, how the stuff you're currently learning will interact with things, etc. It's not the main thing you should be doing, but it can help a lot once in a while.
@@ghostlandered I wouldn't call a multi monitor set-up multi tasking... You primarily focus on your main monitor, the second one is used to play stuff in the background like a twitch stream or yt video, which isn't active but passive. Or you open up a wiki or map for a game, this is the multitasking needed if you just play a game with a map inside. so not really multi tasking at all.
I did this writing. I wrote a bunch of short stories. Wrote a bunch of stupid little things for a small forum. Started slowly working my way up. Got some feedback from a big name author, and kept going. Then it kinda just happened. I wrote a small simple thing for reddit. I started three years ago. I'm finishing the fifth novel in the series and working on planning for the next two.
This is the best advice for any creative process, not just video games. People always tend to want to make their masterpiece before learning how to start their first draft, before they even know the fundamentals.
some very good words of wisdom i once heard was "the difference between a master and student is the master has failed more times then the student has tried".
Everyone's brain works differently, though. While people here say it's mentally taxing to work on something for x months, I enjoy it. The important part is that 1. You are doing thing 2. You are taking notes on how to get better and attempting to do so. The process you use to ensure those two things doesn't matter as long as it works for you.
Often times me and my friends underestimate just how much work goes into some of our projects and art. It’s fun even when we mess up, but learning how is much better than figuring it out after it fails spectacularly😂
yup, it is how i am currently approaching learning computer programming. finally made my first basic project in C++ which was a random number generator to pick a game from a list at random to choose what i should play next. i am still trying to learn the basics and get them hammered in though. i had to use chatgpt fpr quite a lot of the code so i plan on recreating it without using chatgpt
The basic mechanics were done with Kings Field Demons Souls added more to combat and experimental features Some features were added and removed in Dark Souls 1 while older ones were further improved. Dark Souls 2 did a lot of experimentation while giving other members more experience (the best worked on Bloodborne) Bloodborne used new mechanics and tried designing the core gameplay around hyper aggression and moveset versatility. Dark Souls 3 went back to the older combat formula while using some of the features and experience from BloodBorne Sekiro played around with a new combat system and mechanics too. Elden Ring took bits and pieces from all of the above while also trying something new (open world) If you look at inspired works most didn't do a wonderful job with the exception of Lies of P. Although derivative people were able to overlook that fact and still enjoy it for how good it is because it used the Fromsoft formula and simply tried to refine it. Same thing with Palworlds for Ark: Survival, LoZ: BotW and Pokemon. It took the best pieces from them and tried to make something fun. ^ it's good to do your own thing but if you want to also take inspiration from others try to not make the same mistakes they made in the past. It's good to take time and understand what you are doing and to have a goal.
Silly? FromSoft is not a small company anymore, DS3 sold millions and millions, I think it’s fair to expect new models and animations for their biggest and most hyped game. Instead, thet reuse every damn enemy and animation across three games to the points its absurd, and it takes you out of the game, because your brain can’t help but notice something is off.
@@SCDJMU From reached great success by doing their work a certain way. What fools would they have to be to throw out everything they've learned and start from scratch right when they're doing their most ambitious project yet? That's how we got Mass Effect: Andromeda, in case you didn't know. But think of how much money EA saved in Unreal licensing by moving to Frostbite.
I really appreciate how you dove into breaking down development milestones instead of just saying, "Don't tackle big games." Personally, I followed this awesome workflow: a four-week prototype with the first week dedicated to Diablo 2-like movement and combat, the next two weeks focusing on the gameplay loop, and the last two weeks fine-tuning abilities and overall polish. Then, I uploaded it to itch io to gauge engagement. This approach proved super productive for testing out prototypes and ideas!
The last part: "Make a tiny bit of a finished system" is very important. In order to maintain motivation to keep working on your game, it's important to know (and feel like) you *are* working on your dream game, just a little bit at a time.
TLDR: - Josh is spot on here, I know from my own gamedev journey. The solution is to game jams and learn until you actually understand your tools, the scope your dream game actually has, and actual reach you have with your skill at your current level. Build games in genres you may not care about but which are a lot easier to finish (a 2D shmup instead of an Elite Dangerous clone). - Or, start with modding games you already like (try Doom builder, mod Skyrim, write a campaign for your PnP RPG of choice). Many a great dev started out a modder - it can be a shortcut for getting a hang of how bigger games actually tick. I'm a gamedev and can say from my couple of years of experience that Josh is spot on here. Especially in gamedev this is by far the most common reason people burn out (long before they ever get the chance to get crushed by crunch). Since most gamedevs are gamers long before the start deving, they often come in with a dream game they want to make and sorta just start there. The thing is, most modern games that people play and that get them infected with the gamedev bug are made by many people and over the course of years. So when you start a project, you got to do an honest reality check. Do you want to make something like Diablo 3? Well, that game took about 10 years to make, by studio that had Blizzard money, hundreds (if not thousands) of devs, some of which were industry veterans. Is it reasonable to think that you, as a beginner/intermediate working alone and with no budget can achieve something similar? As harsh as it sound, this is coming from a good place. You either accept this truth ahead of time, or you got to take the L in months or years, when you may have sunk a lot more into the project. It hurts the ego now, it may might hurt quite a bit more in other places later down the line (money, stress, other missed learning opportunities). My dream was and still is to make a proper RTS, with base building, multiple factions, 3D graphics. I started that project way early on in my journey, when I thought I had a decent grasp on the Unity game engine and at least some Blender skills. I found out the hard way that, yeah, maybe I could in fact build many of the systems. But there were way, way more than I expected. And building them one at a time takes very, very long. Then there were a lot of systems which I knew in principle how to implement them but making them performant (which is important in an RTS), bug free, and work in conjunction with everything else was a huge task. And then there's the content gulch. If devs come from the side of gamedesign and implementation, and started their way by learning an engine, it very easy to forget that the most amount of work in making a modern game is actually in making the graphics specifically. In a game genres like RPG, RTS, FPS, ~ 70% of your dev time will be making 3D (or 2D) assets. And the asset store, even if you're very, very lucky and you happen to find basically everything you need there, will only cut this down to maybe 40%. That is because even bought assets still need a lot of time to be integrated (shaders, animations, maybe LOD and model optimization). And that's even before you went into sound, music, UI, VFX, accessibility, QA, multiplayer (usually straight up doubles your dev time). Suddenly what started out as "sure, I can implement unit selection, base building on a grid, basic pathfinding" ends up being less than 5% of what has to be done. And if you're honest with yourself in how long it took to implement even that you may begin to get a proper picture of how long things actually will take. And worse still, as people we usually start with the stuff that's easiest to us. But what about the parts of the project that we may have zero skill for yet, what about the parts that we will actually not like doing at all? For me personally, I may have strong visions about how I want my game to look. But both suck and don't enjoy working in Blender. It takes me longer than I like, and I'm not happy with my results. If my game concept requires a ton of models, then it's doomed to fail. Coming from a gamedesign and implementation side, I learned a lot from projects which I first was only lukewarm about. My 2D shmup I made of a 7 day jam is a far cry from my dream space sim. But it taught me a lot about implementing controls, timing VFX and SFX - and most importantly, it got done! People played it, gave feedback, encouragement. I made a tiny 2D golf game, but it gave me a good look into UI/menu setups and mouse controls on web and desktop. It's not glamorous, but if I ever want to actually build that RTS, this is getting me closer to there faster than crashing and burning as a beginner on a project for advanced teams.
Spot on! I'm an experienced developer, and I literally just gave this exact same advice to some younger students at a local game jam after one guy asked me for advice on how to go about making his dream game. It's evergreen advice.
This advice is useful in other industries as well. Wanna make a character design? Make a face first, then build up to the hair, then the torso, then the arms, hands, legs, feet, clothes etc. Wanna compose music? play a note, then a scale, then add more notes and scales, then add accompaniments, instruments, counterpoint etc. It's always good to build projects small then gradually get bigger than start off big but never finishing the project.
His point was less "build gradually from small" and more "train your arsenal separately in smaller bits" so it'd be more like practice drawing faces, practice drawing limbs, practice drawing clothes, practice drawing different types of hair. Then when you wanna design a new character you already have practice making the components to put it all together quickly and in a way that looks really nice Not sure what the equivalent for music would be but for writing it would be like "write a bunch of short stories to practice character dialogue" then "write a bunch of short stories to practice fight scenes" then "practicing writing descriptions for things" etc ect then when you wanna write your big book you already will know how to have engaging dialogue, cool fight scenes and great descriptors among other things
This is great advice *because* it's so broadly applicable. Want to write a book? Start with small sections, write lots, see if they can be grouped (chapters), do the same for the chapters (the book). Want to paint better? Practice lighting, practice composition, practice color mixing; put them together. Programming? Learn essentials (logic blocks, loops, error handling), put them together. Every big thing is a composite of littler things. Keep breaking down until you can digest a thing. Excellent advice 👏
I started to learn game design by myself about a year ago and what I can honesty recommend is to start by following some basic tutorials and then as you finish them start to add more and more flair to each one, stray off the path they guide you on to add your own things, then eventually you’ll be able to give your own original thing a go Game jams are a great thing as well, force you out of your comfort zone and into something new, and the time crunch makes you really think about how to make what you know work, or learn fast
This is how we got Lethal Company Zeekerss has a ton of smaller horror experiences and games under his belt, and Lo, it culminated in the wonderful AI, gameplay loop, and quirkiness of Lethal Company
The funniest thing, Josh, is that I am working on something small... since bloody November, and yes, it was meant to be a one month at most... and mind you, I didn't overscope, but I've never made all the systems in a game myself, and the issues of architecture and lots of other stuff... kinda took a toll. But I've learned so much it was like having a course for a few months with practical assignments :)
This is precisely why you start small. The simple VN I challenged myself to make in 2020, the one I intended to work no more then 1-1.5 months, took almost 5 months to complete. It was a liner story, single end with no more then five inconsequential choices but even for its small size there was so much I didn't know and way more to learn and do then I thought ( like how 5 characters don't seem like a lot until you start factoring stuff like alt poses and expressions). I shudder to I think how things would have ended, if I would've even completed the project if it was even slightly bigger then planned.
Oh yeah, first time starting small I failed because I just didn't understand what I was tackling. However! That was a learning experience that's given me perspective. Learn from the process, get better at it :)
As a gamedev absolutely doing their dream game as their first game, you are truly right in the idea of "making little parts at a time", the amount of work ive done this past month seems insane to me, and I feel like i could finish the game in the next 4 months, but that wasn't because I was constantly looking forward and caressing the idea of the finished product, I was constantly focusing on the "first level" thing. That has helped me so much to focus my efforts into making systems that help me into developing future proof ideas and things that will be far easier in the future, but "If I don't need it right now, I wont do it." mindset has made me save a lot of headaches and time.
lol - I tried doing it as I am supposed to, but now find myself indeed working on that big project I actually wanna do. But I'm really still looking at the different tools I'll be using and am a noob to all of them. And I must say, I take a great deal of enjoyment from that and how it sparks all kinds of ideas about how I am going to manage said project in a way that works for me - both technically and mentally. Like you seem to reference - one can do work in many ways that will make things you do useful one way or another somewhere down the line. I hope to learn a lot about that way of thinking and working. Cause at the end of the day I guess it comes down to accepting how much work it will be (plus side: always something to do) and how much a solid preparation and grasp on what you want to achieve will at some point save your life. Already looking forward to kissing my own feet for navigating around some major pitfall. Surely by that time I will deserve some self-love.
I agree with this advice for the most part, but you can do this and still work on a big project. Just break up all the parts of your game into small tasks, and plan what you're going to finish in 2 week sprints. At the end of each sprint, release what you have completed as an early build of your game. Make it free at first, until there is enough content and/or interest to start trying to monetize it, either by creating a kickstarter or releasing in early access. This approach is sometimes called 'agile', and pretty much every tech company is doing some variation of it these days, but for some reason I never really hear people speak about it in the game dev space.
I really appreciate this! I've known this as a wannabe game dev, and I've done my tiny games. Recently moved on to my first small game, one mansion big. Not my dream game or anything, but was feeling full of doubt. I forgot that this project isn't my dream game and that it's just practice. Thanks for the reminder!
Yup, this is also the first piece of advice that I give to people. Another couple of important things are to learn how to create a GDD and to learn how to use project management software such as Asana, to set yourself or members of your team, if you're not a one man band, tasks and deadlines. Also, develop a prototype with basic shapes FIRST, and let people try it out and provide feedback. You need to make sure that people find your basic game loop FUN before you do any serious work on it. This is known in the trade as Focus Testing, and for Focus Testing, you need to give a wide range of people with varying levels of experience a chance to play your game. Focus Testing needs to be done at every stage of development: your prototype (AKA pre-Alpha), Alpha, Beta, and finally, your Release Candidate (RC1) before you release your game. Doing this at regular intervals will ensure that your game isn't too easy or too difficult by the time that you release it, but this means that each testing group needs to be new players. Hope this extra info helps people out! 👍
An important thing to consider before you start as well: for whatever mechanics you want to put into your game, think about what theyll require of the rest of your game as well. For a personal example: I have been fiddling with a little flight game project off and on for a good while now. And I am quite happy at this point with how my airplane controls, however, when your player is able to fly, how do you ensure they stay inside your level? How large does your level need to be for them to be able to properly play inside of it? Are you able to build and decorate a level of that scale? And if not, what can you do to avoid those problems?
I'm in the same boat. We are a duo developer-programmer and artist-so reducing the scale was the best thing we ever did. It's actually doable, we get to track how much work each stage takes us, and if we are missing a skill we can learn on the go, and we can arrange the scopes for our eventual main game. Excellent advice!
Wish I'd heard this advice when I started my own dev journey. But Hell, I learned it the hard way anyhow, so I'm just glad to see Josh sharing this with other folks who might need to hear it and hope some folks get to take the (slightly?) less painful route as a result. Wise words, Mr. Hayes.
This is really good advice. I often return to my old, even unfinished projects, to see how I did or implemented something in them. Combined with all the knowledge, you will eventually be able to create something greater and you will have confidence in what you are doing.
legit good advice, i've been on and off game deving since i was in high school and wouldn't you know, each small unimpressive projects that i never finished as a highschooler gave me knowledge that lasts. imagine yourself making that fireball game, it might seem insignificant. but you could learn something from it, maybe now you realize that "oh this piece of code is for finding an actor's position" or "oh this material is good for making fire effects" or "oh so i can i use this line to check for hits" etc and all of that knowledge is applicable to a lot of things that aren't just fireballs
That is also true for software development in general. Even the most experienced devs tend to overestimate their ability and capacity and underestimate the time and effort needed. Thats why everything is always being pushed back and even then nothing releases in the intended finished state. In the old java lectures the first lesson was always "divide and conquer". If the problem is too complex, divide them in simpler problems, until you can handle the individual tasks. Start small, finish each small task 1 by 1. That also helps tracking progress and get a sense of achievement. Otherwise motivation will dwindle quickly.
I'm a solo dev making my first game. Just like any other dev, I have a folder of a dozen or so different game ideas. When deciding what to make, I noticed most of my game ideas were too ambitious as a first game, so I made a completely fresh new idea, and battled hard to keep it as simple as possible. Now as the development is taking shape, I am extremely happy I made the decision to scale down to a simple idea. I advise any other first-timers to do the same.
He's correct. Look at the Ultimate General series. Small dev that has been slowly building up his to a dream game over the course of the series. Rumor is he is looking to make Ultimate General Victoria. He started with just a battle...Ultimate General Gettysburg and then Civil War and did some Ultimate Admiral spin offs (to mixed reception) and is now making Ultimate General Revolutionary War which is the largest so far. Again...this is why rumor is he's building up to VICTORIA. Gotta build up man. Can't make a lego tower without a solid base.
Nice little game that was, have them both. I loved the inventory management aspect in Civil War. Definitely interested to see those concepts get even more fleshed out. And I guess that is indeed the surefire way to ultimately build the game one could build, rather than the game constrictions allowed one to build.
Thanks so much for this Josh! I've been working on a project for a while and I was getting disillusioned because I was trying to implement too many systems at once, even though the core product is sound. This is also a great tip for people making a homebrew campaign for a ttrpg setting. You don't need to have every hamlet and enemy encounter in the world developed and ready to go on session zero. You only need to have a good core based on the areas you can reasonably expect the players to experience set, and can work on the nitty gritty stuff as the players move about your world.
This is such good advice!! I’m teaching myself how to code and it’s painful and slow going. But the progress is there! I’ve pulled back my goals like 6 or 7 times now and I’m finally starting to feel like I’m progressing after months of work.
This is great advice, either for gaming or for business. My biggest problem with starting a business is thinking big and providing something bigger outside my scale. Hearing this helped me reevaluate myself. Thank you Josh.
As you said it, it really applies to most things in our lives. As you were explaining, i immediatelly remember how i paced my achademic production through my graduation. By the end of it, it felt so organic to talk and explain my work.
One of the first "games" I made drew random pipe characters on a grid, then made them all connect together to form a maze. Not hard, but I learned how to work arrays quite well, AND detect when I was at the edges. Then I made the edges wrap. New skill. To this day, arrays are trivial for me.
been a "game developer" for about 7 years, this has always been the type of advice Ive gotten online. but my problem is, I never have any passion for small projects. Ive made lots of different projects but never really "finished" anything, theyre either so big that I cant finish them or small enough that I lose interest. for me, Im more interested in creating a whole experience than just something to play, so with my latest project Ive been spending so long on the worldbuilding, detailed assets and storytelling, and luckily the gameplay is relatively simple
Very good advice. That is how I am doing it and how I did it back in high school. My friends and I created a game based on a comic my brother and I created as kids. I'm currently in the process of remaking everything. First, a short digital manga series, which introduces people to the lore of the world and characters. The game looks amazing, but it is nice, simple and most of all fun is the focus.
What I've learned after months of learning game dev now, you take what you want to do, you pick just a couple aspects of it, and you make it into a simple game. You learn what worked, what didn't and now you have more experience as well as ready to go assets and scripts for your next attempt. Just keep doing this again and again with things you see that inspire you and quickly enough you'll notice a big change in quality, in fun of your games, and most of all "imo most important as a solo project" a huge change in the speed and efficiency of your work flow. You won't nessesarily make each little game faster, but you will find yourself spend about the same time, making a whole lot more.
These are straight facts. I don't work in gaming, but I have a background in Silicon Valley, as a product manager, and recently as a VC backed founder. My work has generated tens of millions in revenue for several startups. The lesson I learned from my startup failing is exactly what you're saying here. The advice scales. I now keep a post-it note on my desk to see every day that says "Dream Big, Build Small."
Actually this monologue only earned you fellow subscriber man. That is actually a legit advice showcasing that you are actually worthy to follow. Thanks and keep up.
title: RUN THE LOOT. ARPG game focused just on 1 mechanic: dodging. - a system focused JUST on moving around dungeons, and you cant ever attack. - you have walk, crouching, running, dashing, double jumping, kicking objects, sliding, teleporting, rewinding time, pick-pocketing. - later, if scope creeping: items you hold affect: skill cooldown, magic find, gold find, light radius, sound radius, dash distance, etc. By removing all of the combat spells and attacks, you free the controller's buttons for a fresh new set of actions.
As a person who's currently trying to make a videogame, I am glad that I discovered this. Development is so a daunting task and I have just a Google doc with most of the mechanics written down (7000+ words currently), my friends also keep saying that i need to make a demo first and this has driven that point home. It won't be easy, but I'll keep going and build Kamikin brick by simple brick until it resembles what I want it to. I just hope I can get it mostly done before I hit 30 and I'm turning 23 this year.
Best part was the cooking "analogy". If you ever tried to cook or learn how to cook, that's literally it. You don't just go and try to make a lasagna as your first objective, you may try a salad or something simple like cook an egg. I even programmed some games but never realized that game making is almost the same as cooking, you don't just go and make things as you like. You need to do as many projects as you can till you achieve way more complex and sharp skills to use in your next project; I did complex projects before but it costed so much more time and gave me way less experience than by doing a lot of "easier" and simple projects trying to master game make. As a programmer, try to remember the basic principles of "Keep it simple" and "Don't repeat yourself", it's useful in many more things than just programming. Keep it simple and explore doing things, it's way better than wasting your time with complex but unknown projects trying to achieve some proficiency at skills that you've never trained before.
People often say "Just start small" but I appreciate Josh explaining why, for more reasons than "It's easier and you aren't good enough to make Minecraft GTA yet" because it's important to explain how it's beneficial to start small rather than just bashing people down for dreaming big. In wanting to make an RPG myself, I broke down all of my ideas to the absolute barebones of what I *need* with as little flavour as possible for the core gameplay loop to be fun. Then for about six months I revised that core idea over and over, trying to iterate as much as I can to simplify every bit, but add accessible depth for people interested in that. I left wiggle room for building outwards but I set hard limits on just about everything so I can never get too overzealous. The goal for me is just to make a modest little portfolio piece to say I did it, and I don't waste energy fantasising past that. Only when the small, rigorously tested sandbox area is polished clean will I worry about adding races, lore, new enemies, weapons, zones etc. Besides, if no one enjoys looting 5 rat asses, whose to say they'd stick around to see what else you have to offer?
Solid advice for literally anything, but especially creative works. Drawing also works like this too. This is why they say to work on fundamentals, because you're building the core of any art work.
This is what I'm doing for my series, especially since it's going to be a multimedia thing. But what I do is focus on what is necessary now and not later, so I don't overwhelm myself and get burnt out, and like you said, one step at a time. Once I'm finished with one aspect of something I know needs to be done but isn't super huge, I move on to the next thing I want done. And I make sure I'm having fun doing it, which I feel is super important.
While studying CS in university, I took a very challenging graduate class on distributed algorithms. When the first midterm rolled around, I focused ALL of my studying on the basics. The fundamentals. I figured if I did bad on the exam, at least I'd have gotten all the easy stuff right. I barely looked over the harder algorithms we had studied. The uncurved class average on that exam was 48%, but I got the second highest score at 73%. I still have that exam today. Because I had studied (and practiced!) the "easy" stuff thoroughly, I was able to figure out the answers to many of the bigger, harder exam questions, even though I did not study for them specifically. If I had studied the hard stuff and just assumed that I knew the easy stuff well enough, I know I would not have done so well.
The best thing I ever did was take on the Minimum Viable Product video from Extra Credits. They rank ten genres from the easiest to hardest to complete a prototype for in three weeks. I decided to make a prototype for each genre limiting myself to three weeks each (ten genres, three weeks each, just over half a year). It was super enlightening to just build game mechanics and really focus on making the mechanics fun, nothing else. In the end you will have a good approach to making a prototype quickly while focusing on the "fun" aspect of the game loop only, AND you'll have all the projects with all the code ironed out to slap into your main project (camera controller, movement, basic actions, et al). My favorite was a top down zombie shooter I made. I even as a bonus made the zombie capsules ragdoll and blast away when they died, it was comical.
The way Josh bumps the mic at the very end is so cute. You know he's super passionate about something when he moves enough to bump the mic. It made me smile :)
This is perfect advice. I've been working on my "magnum opus" of sorts for the past 8 years. Spent an extreme amount of time and money on it that I will very likely not see a tangible return on. I have made a lot of smaller games in the past, but absolutely nothing that even comes close to this scale. Development has been brutal. I would highly recommend that any aspiring devs start small.
What an awesome yet simple suggestion. Start really small, polish it and then make something slightly bigger and better. I’ll take this advice to heart.
This is exactly how i ended up with a very complex excel sheet that calculated the stat increases in FFTA2 so i could maximize character stats. Now i use those same skills to make really complex sheets at work and i can whip up new game related sheet within an hour instead of the days it originally took me
This makes so many senses in so many contexts. Sometimes is difficult to convince other people working with us that maybe stepping down and trimming a few things coulde be the best choice
Actually legit advice. It works for programming as well. Learn all the features on their own, and how to use them in various ways, and then integrate the parts into a new whole.
Extremely good advice! I got into a programming college so I could make a game some day. Getting there opened my eyes on what a mountain of a task is to actually make any application, let alone a game. I graduated college and I am now working on my master's degree. I worked on many applications since then. All are quite small, but each one has thought me something new. While I still don't think I am ready to develop a game yet (home made game engine, be damned!), I still code whatever random application comes to my mind to improve my overall skills as a programmer.
You know, a lot of these streamers don't actually know how development works Josh is different. This is great advice. Start with something simple like an asteroid shooter.
Needed this reminder. And Josh made good points about it too. For a long time, I heard, "dont do the big game, do many small games. They'll all gonna suck, but thats fine." Well, I never really saw the use of small games if I wasn't interested in them. I'm a perfectionist too, all my games got to at least look decent. Whats a game if no one played it? Josh says its about learning one thing at a time... and I can respect that. I have too many things going on and its probably something I should've started doing one by one xD
With the cooking advice, I'd add a piece. Learn to cook each item, like he said, but then learn to do two at a time. Learning to manage two items at once in cooking is a change to the skill set. Then do three. See how the timing changes so you can have all three done to plate. Then put it all together. It really stinks when your waiting for your side dishes to finish as your main course is slowly getting cold.
Constraints are GOOD. Limits HELP you. If you only have 5 days, or even a weekend, to produce somehting, it allows you to quickly scope out the work and decide what you can do in that time. It also means you don't spend a ton of time in analysis-paralysis. If you only have a weekend to finish some kind of hackathon, that means you need to limit your planning to just a few hours. So you need to figure out the broad strokes of what you're going to accomplish in that time, and a rough idea of the path to take. You can also brutally discard any ideas that will push you beyond your preset limit. My favourite example of limits helping is Monty Python and the Holy Grail. In that case, the limit was the budget. They didn't have enough money for horses, so they came up with the coconut thing, which became one of the funniest running gags ever. The movie is BETTER because they couldn't afford horses. There are other examples of this too - where limits ended up helping. For this I love commercials. You have 30 seconds to tell a story - to make an impression. To make someone laugh. Remember vines? You had only 6 SECONDS to do something, and there were tons of hilarious videos in those 6 seconds.
I struggle a lot with putting massive expectations on myself, but something I've found helpful is to try to remember that any contribution is a contribution. Anything you make with genuine love is going to make the world a better place, even if it's only by a little bit. By creating something- of any level of quality- and putting it out into the world, you are giving the world a gift. It might be really bad. Maybe only a few random people see it, maybe only your closest friends, maybe just one of your parents or a sibling. Maybe it's just something for you. But by creating it, you have contributed something valuable, something only you can contribute.
This also goes for Writing, visual art, or dancing, any other art form really. You can write an outline or sketch notes for your big project, and maybe even work on it a little, but you will improve more doing small things, that you can learn from in the process, and your big project will benefit from your experience.
1: Come up with an idea. 2: Scope lower to the absolute basics. 3: Make a vertical slice of it. 4: Make it publicly available and see if people like it.
Pragmatically speaking: Use an ECS architecture. It allows you to compose features much more easily than other architectures. Still make one small thing after the other, but if you do keep an eye on keeping your systems up to date with your data model, you will, after a bunch of small things, have a bunch of functionalities that you can weave into one big thing easily.
When it comes to learning concepts (especially spending time learning the engine and coding) I find it hard to be motivated to make things that may or may not have any relevance to the main thing I want to do, just like you’d look at a math problem and think ‘well, that’s not something I’ll ever use’. But the great thing about this field is that you can learn by necessity. It’s actually better to not try and memorize everything all at once all the time. I build a small thing, build it up, and then make another small related system/class and add it in, problem solve, and add more and more pieces to build the whole. It’s fun and feels meaningful. This isn’t advice but I feel like it’s helped me grow from nothing
Good advice. Take a look at the first game created by companies making triple A games now. Blizzard's first game was RPM racing. id's first game was Commander Keen. Activision started with Atari 2600 games. EA made Ultima 1. There are a lot of other example's like this. They all started with games a single developer could replicate and improved from there in less than a single person's lifetime.
Worth pointing out that EA didn't have anything to do with Ultima until way later and Ultima wasn't even the first game that Richard Garriot made. Akalabeth was the first retail release he did and even that wasn't the first game he made. It's also worth making a greater distinction between the publisher and the developer of games as EA (as implied by the name Electronic Arts) has always positioned itself as the video game equivalent of a record label. EA's first games were put out on the PC and Mega Drive, so would have been considerably more advanced than Ultima 1, but they were made by experienced programmers who had demonstrated their skills. The most important innovation they did in house was reverse engineering the cartridges for the Mega Drive and using that as leverage to get better licensing agreements from Sega
I've started making a game 2 months ago and I've had some decent progress. My dream goal is pretty ambitious but all I'm doing right now is just a tiny slice of that. This advice is what gets you to do anything creative/technically demanding
Absolutely great advice! I'd add to this; (which is basically what you're saying) spend more time learning before you try to make something. You wouldn't try to create and album without learning to play guitar for a few years, so why do so many people think they can just jump in and start making games without any experience?
I'm approaching my game like this, I want to learn how to make a game, so I am taking a methodical approach, trying to understand all of the systems I will need to make at the most fundamental level, and document that in a notebook. It's really rewarding when you start with the most basic, ugly, get it done programming, and end it with an elegant, refined, and efficient system at the end. I can look at my notebook and see where I started and where I ended, and it motivates me to move on to the next step, one piece at a time. I have a good job, I make enough money, I don't NEED to finish my game in a week, a month, or a year. If I never finish the game, I will have at least enjoyed the learning experience of it all.
As a video game programmer by profession, this is a very legit advice for any aspiring developer. Video game production is one of the most complex production pipeline out there right now. Going all in with a big project when you have little actual legit professional experience is project suicide. Instead follow what Josh said: 1 - Build small. 2 - Build reusable things where it make sense to have them as such (especially if you code) in, and I can't stress that enough, a legit way. Don't throw things together and hope it's going to works out. It most likely won't for long. Design patterns and guidelines exists for a reason. 3 - Be thoughtful and thorough. 4 - Build slightly bigger stuff faster with the reusable things you've built. 5 - Enjoy a progressively more enjoyable and fast paced production pipeline when starting new projects or working on your current project.
This is true for everything. If you are faced with a large task that seems daunting. Divide it into three parts. Then look at each part and consider it. Then divide those parts into three and continue until each task seems so easy to do!
Started doing a simple space shooter game with gamemaker, did this every year for the past 2 years and set myself a deadline for 1 month. First game was very simple, very bad gameplay. Next years i used a lot of the old code to save some time, built a new UI, and used the rest of the time to adjust the gameplay. This year i want to try and see if i maybe can add a bossbattle to it, and go in small steps. Helped me a lot to overcome the frustration. You can do it too!
best part is that this is actual legit advice
People always tend to overestimate their scope. It's been the death of countless early access games.
@@247BrettzleAnd I can tell you, as a game developer myself, that the Early Access graveyard is maybe about 1% the size of the collective wasteland of abandoned projects on countless hard disks.
@@swishfish8858And those are just the Blizzard games abandoned or dropped
Was that not the point of him answering? To give actual advice?
Doesn't apply to just video games, but everything else in life when learning a new skill. You start off sucking at something before you become decent at it.
If you ask seasoned devs, be it for games, software, web or whatever, they say the same thing. It's actual good advice there.
It's true for literally everything in human existence. The fact this isn't the baseline approach for some people is what's wrong. Overconfidence is a heck of a drug.
It's not so much overconfidence. I have spent 30 years thinking I lacked any ambition or drive.
Turned out I was being a perfectionist, holding myself to absurd standards I could never dream to meet - and not being aware of it.@@GruppeSechs
"What can you make in a week?" That's why the 7 Day Roguelike (7DRL) challenge exists. If you only have a week, it means you need to have a compact and focused design. Build a core thing that's fun. Once you're done, you can choose to add to it if you want, but at least you have a core that you can build upon.
and anyone doing that challenge (I would assume) has already done at least many "small games" before, meaning that this is a challenge mainly about time constraints, not knowledge/experience. As you say, great for focusing the mind on a "key mechanic".
@@paulmdevenney it's not just good for people who have done many small games before, it still applies to these new people, cause the hardest part about making games is keeping the scope small without constantly wanting to add things. So having a time constraint forces you to keep it small within your means.
@@TwoWayOrbitalStation however, early projects will be subject to learning the tools which cannot be done in a very short time and will obscure the purpose of designing the game
@@MagicGonads Exactly. I mean it is fair to say that you could get all the assets from the free market places and that you can make it as simple as possible so that an average joe could learn a lot on the way.
This challenge is otherwise as you state for people with an already established rather intermediate skill-level. But OP is right, that this would be a good example to learn to focus and organize themselves.
With a good tutorial working with accessible and easily set up framework/engine/pipeline at hand you can follow through several times it might be possible to get someone ready within weeks to tackle the challenge.
With an established pipeline or even a fundamental understanding of Code or Design you can make a lot. This is why game jam exists.
I would also add "What can you do in 6 Months?" or "What can you learn in one year?".
You mean spend 6 days trying to do something and then realise your scope is for 7 months, not days, only have 1 day left and you can't turn it into anything playable?
As a former Senior Software Engineer (22+ years), I can attest that this is exactly how I approached large projects. Both when on my own and when with a team. The deliverable was broken down into many small parts and those were each fully developed and debugged before integration into the system. Then whatever additional issues that would crop up would be resolved before adding in anything new. Works a charm and results in some pretty robust software. :)
Learning new system is exactly the same. New languages traditionally start with the ubiquitous "Hello World" application. And then continue with small, incremental additions to the new programmer's toolkit. A superior way of learning compared to the 'throw them into the deep end of the pool' methodology.
That is the next hurdle, make sure those tiny pieces actually fit together.
I find the game industry have no clue what balancing is. They just want to keep adding ideas at any cost.
It's pretty cool to look at the deep end though. So much to see and dream.
For experience I can tell you, as cool as it is looking at the more advance stuff, you will never be able to properly understand it without good fundamentals of anything before that
Just learn the small pieces and try to enjoy the process and you will be able to do more advance stuff before you can even realize it
Thanks, Gru.
I definitely agree, but I also think jumping into the deep end can be a good way to figure out what you should learn next, how the stuff you're currently learning will interact with things, etc. It's not the main thing you should be doing, but it can help a lot once in a while.
main moniter content
Multi tasking isn't good for your brain.
@@ghostlandered It ISS good for you brain, but it's bad for your mental health yeah
@@ghostlandered
I wouldn't call a multi monitor set-up multi tasking...
You primarily focus on your main monitor, the second one is used to play stuff in the background like a twitch stream or yt video, which isn't active but passive.
Or you open up a wiki or map for a game, this is the multitasking needed if you just play a game with a map inside. so not really multi tasking at all.
@@ghostlandered Multi tasking made me the Fortune 500 Senior Enterprise Architect that I am today xd
@user-ol9zd1zy4x you're right that was a lot of bullshit to say at once.
I did this writing. I wrote a bunch of short stories. Wrote a bunch of stupid little things for a small forum. Started slowly working my way up. Got some feedback from a big name author, and kept going.
Then it kinda just happened.
I wrote a small simple thing for reddit. I started three years ago. I'm finishing the fifth novel in the series and working on planning for the next two.
What are they about?
Alright, where's the title? You can't just leave me hanging!
i wanna read
My man succeeded at writing but failed marketing - free self promotion
I just wanna know what they're called. :(
This is the best advice for any creative process, not just video games. People always tend to want to make their masterpiece before learning how to start their first draft, before they even know the fundamentals.
Applies to training as well. You don't have to be a master in a day. It's just general good life advice.
some very good words of wisdom i once heard was "the difference between a master and student is the master has failed more times then the student has tried".
Everyone's brain works differently, though. While people here say it's mentally taxing to work on something for x months, I enjoy it. The important part is that 1. You are doing thing 2. You are taking notes on how to get better and attempting to do so. The process you use to ensure those two things doesn't matter as long as it works for you.
Often times me and my friends underestimate just how much work goes into some of our projects and art.
It’s fun even when we mess up, but learning how is much better than figuring it out after it fails spectacularly😂
yup, it is how i am currently approaching learning computer programming. finally made my first basic project in C++ which was a random number generator to pick a game from a list at random to choose what i should play next. i am still trying to learn the basics and get them hammered in though. i had to use chatgpt fpr quite a lot of the code so i plan on recreating it without using chatgpt
"Start small" is the best advice for any artist just dipping their toes into a craft
0:55 many people may not notice, but this is exactly how Elden Ring was made
The basic mechanics were done with Kings Field
Demons Souls added more to combat and experimental features
Some features were added and removed in Dark Souls 1 while older ones were further improved.
Dark Souls 2 did a lot of experimentation while giving other members more experience (the best worked on Bloodborne)
Bloodborne used new mechanics and tried designing the core gameplay around hyper aggression and moveset versatility.
Dark Souls 3 went back to the older combat formula while using some of the features and experience from BloodBorne
Sekiro played around with a new combat system and mechanics too.
Elden Ring took bits and pieces from all of the above while also trying something new (open world)
If you look at inspired works most didn't do a wonderful job with the exception of Lies of P. Although derivative people were able to overlook that fact and still enjoy it for how good it is because it used the Fromsoft formula and simply tried to refine it.
Same thing with Palworlds for Ark: Survival, LoZ: BotW and Pokemon. It took the best pieces from them and tried to make something fun.
^ it's good to do your own thing but if you want to also take inspiration from others try to not make the same mistakes they made in the past. It's good to take time and understand what you are doing and to have a goal.
I think a lot of people did notice. Hence all the (imo silly) complaints about reused assets and such.
Silly? FromSoft is not a small company anymore, DS3 sold millions and millions, I think it’s fair to expect new models and animations for their biggest and most hyped game. Instead, thet reuse every damn enemy and animation across three games to the points its absurd, and it takes you out of the game, because your brain can’t help but notice something is off.
Well From have been making iterations on roughly the same concept for literal decades... and only half of them were ever released outside of Japan.
@@SCDJMU From reached great success by doing their work a certain way. What fools would they have to be to throw out everything they've learned and start from scratch right when they're doing their most ambitious project yet?
That's how we got Mass Effect: Andromeda, in case you didn't know. But think of how much money EA saved in Unreal licensing by moving to Frostbite.
I really appreciate how you dove into breaking down development milestones instead of just saying, "Don't tackle big games." Personally, I followed this awesome workflow: a four-week prototype with the first week dedicated to Diablo 2-like movement and combat, the next two weeks focusing on the gameplay loop, and the last two weeks fine-tuning abilities and overall polish. Then, I uploaded it to itch io to gauge engagement. This approach proved super productive for testing out prototypes and ideas!
The last part: "Make a tiny bit of a finished system" is very important. In order to maintain motivation to keep working on your game, it's important to know (and feel like) you *are* working on your dream game, just a little bit at a time.
TLDR:
- Josh is spot on here, I know from my own gamedev journey. The solution is to game jams and learn until you actually understand your tools, the scope your dream game actually has, and actual reach you have with your skill at your current level. Build games in genres you may not care about but which are a lot easier to finish (a 2D shmup instead of an Elite Dangerous clone).
- Or, start with modding games you already like (try Doom builder, mod Skyrim, write a campaign for your PnP RPG of choice). Many a great dev started out a modder - it can be a shortcut for getting a hang of how bigger games actually tick.
I'm a gamedev and can say from my couple of years of experience that Josh is spot on here. Especially in gamedev this is by far the most common reason people burn out (long before they ever get the chance to get crushed by crunch).
Since most gamedevs are gamers long before the start deving, they often come in with a dream game they want to make and sorta just start there. The thing is, most modern games that people play and that get them infected with the gamedev bug are made by many people and over the course of years. So when you start a project, you got to do an honest reality check. Do you want to make something like Diablo 3? Well, that game took about 10 years to make, by studio that had Blizzard money, hundreds (if not thousands) of devs, some of which were industry veterans. Is it reasonable to think that you, as a beginner/intermediate working alone and with no budget can achieve something similar?
As harsh as it sound, this is coming from a good place. You either accept this truth ahead of time, or you got to take the L in months or years, when you may have sunk a lot more into the project. It hurts the ego now, it may might hurt quite a bit more in other places later down the line (money, stress, other missed learning opportunities).
My dream was and still is to make a proper RTS, with base building, multiple factions, 3D graphics. I started that project way early on in my journey, when I thought I had a decent grasp on the Unity game engine and at least some Blender skills. I found out the hard way that, yeah, maybe I could in fact build many of the systems. But there were way, way more than I expected. And building them one at a time takes very, very long. Then there were a lot of systems which I knew in principle how to implement them but making them performant (which is important in an RTS), bug free, and work in conjunction with everything else was a huge task.
And then there's the content gulch. If devs come from the side of gamedesign and implementation, and started their way by learning an engine, it very easy to forget that the most amount of work in making a modern game is actually in making the graphics specifically. In a game genres like RPG, RTS, FPS, ~ 70% of your dev time will be making 3D (or 2D) assets. And the asset store, even if you're very, very lucky and you happen to find basically everything you need there, will only cut this down to maybe 40%. That is because even bought assets still need a lot of time to be integrated (shaders, animations, maybe LOD and model optimization). And that's even before you went into sound, music, UI, VFX, accessibility, QA, multiplayer (usually straight up doubles your dev time).
Suddenly what started out as "sure, I can implement unit selection, base building on a grid, basic pathfinding" ends up being less than 5% of what has to be done. And if you're honest with yourself in how long it took to implement even that you may begin to get a proper picture of how long things actually will take. And worse still, as people we usually start with the stuff that's easiest to us. But what about the parts of the project that we may have zero skill for yet, what about the parts that we will actually not like doing at all? For me personally, I may have strong visions about how I want my game to look. But both suck and don't enjoy working in Blender. It takes me longer than I like, and I'm not happy with my results. If my game concept requires a ton of models, then it's doomed to fail.
Coming from a gamedesign and implementation side, I learned a lot from projects which I first was only lukewarm about. My 2D shmup I made of a 7 day jam is a far cry from my dream space sim. But it taught me a lot about implementing controls, timing VFX and SFX - and most importantly, it got done! People played it, gave feedback, encouragement.
I made a tiny 2D golf game, but it gave me a good look into UI/menu setups and mouse controls on web and desktop. It's not glamorous, but if I ever want to actually build that RTS, this is getting me closer to there faster than crashing and burning as a beginner on a project for advanced teams.
Spot on!
I'm an experienced developer, and I literally just gave this exact same advice to some younger students at a local game jam after one guy asked me for advice on how to go about making his dream game. It's evergreen advice.
This advice is useful in other industries as well. Wanna make a character design? Make a face first, then build up to the hair, then the torso, then the arms, hands, legs, feet, clothes etc. Wanna compose music? play a note, then a scale, then add more notes and scales, then add accompaniments, instruments, counterpoint etc. It's always good to build projects small then gradually get bigger than start off big but never finishing the project.
His point was less "build gradually from small" and more "train your arsenal separately in smaller bits"
so it'd be more like
practice drawing faces, practice drawing limbs, practice drawing clothes, practice drawing different types of hair. Then when you wanna design a new character you already have practice making the components to put it all together quickly and in a way that looks really nice
Not sure what the equivalent for music would be but for writing it would be like "write a bunch of short stories to practice character dialogue" then "write a bunch of short stories to practice fight scenes" then "practicing writing descriptions for things" etc ect
then when you wanna write your big book you already will know how to have engaging dialogue, cool fight scenes and great descriptors among other things
Pretty much, yeah@@Xenomorthian
This is great advice *because* it's so broadly applicable. Want to write a book? Start with small sections, write lots, see if they can be grouped (chapters), do the same for the chapters (the book). Want to paint better? Practice lighting, practice composition, practice color mixing; put them together. Programming? Learn essentials (logic blocks, loops, error handling), put them together. Every big thing is a composite of littler things. Keep breaking down until you can digest a thing.
Excellent advice 👏
I'm actually really glad that from my small donate not only did Josh gave me advice but also to many others
I started to learn game design by myself about a year ago and what I can honesty recommend is to start by following some basic tutorials and then as you finish them start to add more and more flair to each one, stray off the path they guide you on to add your own things, then eventually you’ll be able to give your own original thing a go
Game jams are a great thing as well, force you out of your comfort zone and into something new, and the time crunch makes you really think about how to make what you know work, or learn fast
This is how we got Lethal Company
Zeekerss has a ton of smaller horror experiences and games under his belt, and Lo, it culminated in the wonderful AI, gameplay loop, and quirkiness of Lethal Company
The funniest thing, Josh, is that I am working on something small... since bloody November, and yes, it was meant to be a one month at most... and mind you, I didn't overscope, but I've never made all the systems in a game myself, and the issues of architecture and lots of other stuff... kinda took a toll. But I've learned so much it was like having a course for a few months with practical assignments :)
This is precisely why you start small.
The simple VN I challenged myself to make in 2020, the one I intended to work no more then 1-1.5 months, took almost 5 months to complete. It was a liner story, single end with no more then five inconsequential choices but even for its small size there was so much I didn't know and way more to learn and do then I thought ( like how 5 characters don't seem like a lot until you start factoring stuff like alt poses and expressions). I shudder to I think how things would have ended, if I would've even completed the project if it was even slightly bigger then planned.
Did you enjoy it?
@@fatalblue
Oh yeah, first time starting small I failed because I just didn't understand what I was tackling. However! That was a learning experience that's given me perspective. Learn from the process, get better at it :)
As a gamedev absolutely doing their dream game as their first game, you are truly right in the idea of "making little parts at a time", the amount of work ive done this past month seems insane to me, and I feel like i could finish the game in the next 4 months, but that wasn't because I was constantly looking forward and caressing the idea of the finished product, I was constantly focusing on the "first level" thing. That has helped me so much to focus my efforts into making systems that help me into developing future proof ideas and things that will be far easier in the future, but "If I don't need it right now, I wont do it." mindset has made me save a lot of headaches and time.
lol - I tried doing it as I am supposed to, but now find myself indeed working on that big project I actually wanna do.
But I'm really still looking at the different tools I'll be using and am a noob to all of them. And I must say, I take a great deal of enjoyment from that and how it sparks all kinds of ideas about how I am going to manage said project in a way that works for me - both technically and mentally. Like you seem to reference - one can do work in many ways that will make things you do useful one way or another somewhere down the line. I hope to learn a lot about that way of thinking and working.
Cause at the end of the day I guess it comes down to accepting how much work it will be (plus side: always something to do) and how much a solid preparation and grasp on what you want to achieve will at some point save your life.
Already looking forward to kissing my own feet for navigating around some major pitfall. Surely by that time I will deserve some self-love.
I agree with this advice for the most part, but you can do this and still work on a big project. Just break up all the parts of your game into small tasks, and plan what you're going to finish in 2 week sprints. At the end of each sprint, release what you have completed as an early build of your game. Make it free at first, until there is enough content and/or interest to start trying to monetize it, either by creating a kickstarter or releasing in early access. This approach is sometimes called 'agile', and pretty much every tech company is doing some variation of it these days, but for some reason I never really hear people speak about it in the game dev space.
I really appreciate this! I've known this as a wannabe game dev, and I've done my tiny games. Recently moved on to my first small game, one mansion big. Not my dream game or anything, but was feeling full of doubt. I forgot that this project isn't my dream game and that it's just practice. Thanks for the reminder!
Simple advice, yet I needed to hear that. Thank you.
genuinely some of the best advice for a beginner dev
Yup, this is also the first piece of advice that I give to people.
Another couple of important things are to learn how to create a GDD and to learn how to use project management software such as Asana, to set yourself or members of your team, if you're not a one man band, tasks and deadlines.
Also, develop a prototype with basic shapes FIRST, and let people try it out and provide feedback. You need to make sure that people find your basic game loop FUN before you do any serious work on it.
This is known in the trade as Focus Testing, and for Focus Testing, you need to give a wide range of people with varying levels of experience a chance to play your game.
Focus Testing needs to be done at every stage of development: your prototype (AKA pre-Alpha), Alpha, Beta, and finally, your Release Candidate (RC1) before you release your game.
Doing this at regular intervals will ensure that your game isn't too easy or too difficult by the time that you release it, but this means that each testing group needs to be new players.
Hope this extra info helps people out! 👍
Another great advice that i lear ned over the years, don't be afraid to scrap projects and don't be afraid to reuse assets that you scrapped.
From a solo dev who's been making games for 13 years now: great advice!
An important thing to consider before you start as well: for whatever mechanics you want to put into your game, think about what theyll require of the rest of your game as well.
For a personal example: I have been fiddling with a little flight game project off and on for a good while now.
And I am quite happy at this point with how my airplane controls, however, when your player is able to fly, how do you ensure they stay inside your level?
How large does your level need to be for them to be able to properly play inside of it?
Are you able to build and decorate a level of that scale?
And if not, what can you do to avoid those problems?
I'm in the same boat. We are a duo developer-programmer and artist-so reducing the scale was the best thing we ever did. It's actually doable, we get to track how much work each stage takes us, and if we are missing a skill we can learn on the go, and we can arrange the scopes for our eventual main game.
Excellent advice!
Wish I'd heard this advice when I started my own dev journey. But Hell, I learned it the hard way anyhow, so I'm just glad to see Josh sharing this with other folks who might need to hear it and hope some folks get to take the (slightly?) less painful route as a result. Wise words, Mr. Hayes.
This is really good advice. I often return to my old, even unfinished projects, to see how I did or implemented something in them. Combined with all the knowledge, you will eventually be able to create something greater and you will have confidence in what you are doing.
legit good advice, i've been on and off game deving since i was in high school and wouldn't you know, each small unimpressive projects that i never finished as a highschooler gave me knowledge that lasts.
imagine yourself making that fireball game, it might seem insignificant. but you could learn something from it, maybe now you realize that "oh this piece of code is for finding an actor's position" or "oh this material is good for making fire effects" or "oh so i can i use this line to check for hits" etc
and all of that knowledge is applicable to a lot of things that aren't just fireballs
That is also true for software development in general. Even the most experienced devs tend to overestimate their ability and capacity and underestimate the time and effort needed. Thats why everything is always being pushed back and even then nothing releases in the intended finished state.
In the old java lectures the first lesson was always "divide and conquer". If the problem is too complex, divide them in simpler problems, until you can handle the individual tasks. Start small, finish each small task 1 by 1. That also helps tracking progress and get a sense of achievement. Otherwise motivation will dwindle quickly.
I'm a solo dev making my first game.
Just like any other dev, I have a folder of a dozen or so different game ideas.
When deciding what to make, I noticed most of my game ideas were too ambitious as a first game, so I made a completely fresh new idea, and battled hard to keep it as simple as possible.
Now as the development is taking shape, I am extremely happy I made the decision to scale down to a simple idea. I advise any other first-timers to do the same.
This is awesome advice for DMs. Always new DMs try to build a whole world when they can't build a two-three room dungeon
He's correct. Look at the Ultimate General series. Small dev that has been slowly building up his to a dream game over the course of the series. Rumor is he is looking to make Ultimate General Victoria.
He started with just a battle...Ultimate General Gettysburg and then Civil War and did some Ultimate Admiral spin offs (to mixed reception) and is now making Ultimate General Revolutionary War which is the largest so far. Again...this is why rumor is he's building up to VICTORIA.
Gotta build up man. Can't make a lego tower without a solid base.
Nice little game that was, have them both.
I loved the inventory management aspect in Civil War. Definitely interested to see those concepts get even more fleshed out. And I guess that is indeed the surefire way to ultimately build the game one could build, rather than the game constrictions allowed one to build.
Thanks so much for this Josh! I've been working on a project for a while and I was getting disillusioned because I was trying to implement too many systems at once, even though the core product is sound.
This is also a great tip for people making a homebrew campaign for a ttrpg setting.
You don't need to have every hamlet and enemy encounter in the world developed and ready to go on session zero.
You only need to have a good core based on the areas you can reasonably expect the players to experience set, and can work on the nitty gritty stuff as the players move about your world.
This is such good advice!!
I’m teaching myself how to code and it’s painful and slow going. But the progress is there! I’ve pulled back my goals like 6 or 7 times now and I’m finally starting to feel like I’m progressing after months of work.
This is great advice, either for gaming or for business. My biggest problem with starting a business is thinking big and providing something bigger outside my scale. Hearing this helped me reevaluate myself. Thank you Josh.
As you said it, it really applies to most things in our lives. As you were explaining, i immediatelly remember how i paced my achademic production through my graduation. By the end of it, it felt so organic to talk and explain my work.
One of the first "games" I made drew random pipe characters on a grid, then made them all connect together to form a maze. Not hard, but I learned how to work arrays quite well, AND detect when I was at the edges. Then I made the edges wrap. New skill. To this day, arrays are trivial for me.
been a "game developer" for about 7 years, this has always been the type of advice Ive gotten online. but my problem is, I never have any passion for small projects. Ive made lots of different projects but never really "finished" anything, theyre either so big that I cant finish them or small enough that I lose interest. for me, Im more interested in creating a whole experience than just something to play, so with my latest project Ive been spending so long on the worldbuilding, detailed assets and storytelling, and luckily the gameplay is relatively simple
Growth come by actually finishing something. It builds momentum. It's hard, but it helps.
id say dont listen to ppl like in this video. I dont think they realize how disheartening their advise actually sounds to new devs......
Very good advice. That is how I am doing it and how I did it back in high school. My friends and I created a game based on a comic my brother and I created as kids. I'm currently in the process of remaking everything. First, a short digital manga series, which introduces people to the lore of the world and characters. The game looks amazing, but it is nice, simple and most of all fun is the focus.
What I've learned after months of learning game dev now, you take what you want to do, you pick just a couple aspects of it, and you make it into a simple game.
You learn what worked, what didn't and now you have more experience as well as ready to go assets and scripts for your next attempt.
Just keep doing this again and again with things you see that inspire you and quickly enough you'll notice a big change in quality, in fun of your games, and most of all "imo most important as a solo project" a huge change in the speed and efficiency of your work flow. You won't nessesarily make each little game faster, but you will find yourself spend about the same time, making a whole lot more.
These are straight facts. I don't work in gaming, but I have a background in Silicon Valley, as a product manager, and recently as a VC backed founder.
My work has generated tens of millions in revenue for several startups.
The lesson I learned from my startup failing is exactly what you're saying here. The advice scales.
I now keep a post-it note on my desk to see every day that says "Dream Big, Build Small."
Actually this monologue only earned you fellow subscriber man. That is actually a legit advice showcasing that you are actually worthy to follow. Thanks and keep up.
title: RUN THE LOOT.
ARPG game focused just on 1 mechanic: dodging.
- a system focused JUST on moving around dungeons, and you cant ever attack.
- you have walk, crouching, running, dashing, double jumping, kicking objects, sliding, teleporting, rewinding time, pick-pocketing.
- later, if scope creeping: items you hold affect: skill cooldown, magic find, gold find, light radius, sound radius, dash distance, etc.
By removing all of the combat spells and attacks, you free the controller's buttons for a fresh new set of actions.
This actually sounds like fun lol
sounds like a great game! and i would suck at it as i have the reflexes of a dead sloth!
As a person who's currently trying to make a videogame, I am glad that I discovered this. Development is so a daunting task and I have just a Google doc with most of the mechanics written down (7000+ words currently), my friends also keep saying that i need to make a demo first and this has driven that point home. It won't be easy, but I'll keep going and build Kamikin brick by simple brick until it resembles what I want it to. I just hope I can get it mostly done before I hit 30 and I'm turning 23 this year.
Best part was the cooking "analogy". If you ever tried to cook or learn how to cook, that's literally it. You don't just go and try to make a lasagna as your first objective, you may try a salad or something simple like cook an egg.
I even programmed some games but never realized that game making is almost the same as cooking, you don't just go and make things as you like. You need to do as many projects as you can till you achieve way more complex and sharp skills to use in your next project; I did complex projects before but it costed so much more time and gave me way less experience than by doing a lot of "easier" and simple projects trying to master game make.
As a programmer, try to remember the basic principles of "Keep it simple" and "Don't repeat yourself", it's useful in many more things than just programming. Keep it simple and explore doing things, it's way better than wasting your time with complex but unknown projects trying to achieve some proficiency at skills that you've never trained before.
Thank you Josh, this advice resonates with me. I'm not making a game, but writing a novel, and it applies there too.
People often say "Just start small" but I appreciate Josh explaining why, for more reasons than "It's easier and you aren't good enough to make Minecraft GTA yet" because it's important to explain how it's beneficial to start small rather than just bashing people down for dreaming big.
In wanting to make an RPG myself, I broke down all of my ideas to the absolute barebones of what I *need* with as little flavour as possible for the core gameplay loop to be fun. Then for about six months I revised that core idea over and over, trying to iterate as much as I can to simplify every bit, but add accessible depth for people interested in that. I left wiggle room for building outwards but I set hard limits on just about everything so I can never get too overzealous.
The goal for me is just to make a modest little portfolio piece to say I did it, and I don't waste energy fantasising past that. Only when the small, rigorously tested sandbox area is polished clean will I worry about adding races, lore, new enemies, weapons, zones etc. Besides, if no one enjoys looting 5 rat asses, whose to say they'd stick around to see what else you have to offer?
Solid advice for literally anything, but especially creative works. Drawing also works like this too. This is why they say to work on fundamentals, because you're building the core of any art work.
This is what I'm doing for my series, especially since it's going to be a multimedia thing. But what I do is focus on what is necessary now and not later, so I don't overwhelm myself and get burnt out, and like you said, one step at a time. Once I'm finished with one aspect of something I know needs to be done but isn't super huge, I move on to the next thing I want done. And I make sure I'm having fun doing it, which I feel is super important.
Have a design doc with your "must haves" and the "would be nice". Focus on the former.
While studying CS in university, I took a very challenging graduate class on distributed algorithms. When the first midterm rolled around, I focused ALL of my studying on the basics. The fundamentals. I figured if I did bad on the exam, at least I'd have gotten all the easy stuff right. I barely looked over the harder algorithms we had studied.
The uncurved class average on that exam was 48%, but I got the second highest score at 73%. I still have that exam today.
Because I had studied (and practiced!) the "easy" stuff thoroughly, I was able to figure out the answers to many of the bigger, harder exam questions, even though I did not study for them specifically. If I had studied the hard stuff and just assumed that I knew the easy stuff well enough, I know I would not have done so well.
100% legit advice for anyone starting out with game dev. This is exactly how you should do it.
This is great advice. The cooking analogy is accurate too - some recipes scared me in the past and now are ezpz (like beef Wellington).
The best thing I ever did was take on the Minimum Viable Product video from Extra Credits. They rank ten genres from the easiest to hardest to complete a prototype for in three weeks. I decided to make a prototype for each genre limiting myself to three weeks each (ten genres, three weeks each, just over half a year). It was super enlightening to just build game mechanics and really focus on making the mechanics fun, nothing else. In the end you will have a good approach to making a prototype quickly while focusing on the "fun" aspect of the game loop only, AND you'll have all the projects with all the code ironed out to slap into your main project (camera controller, movement, basic actions, et al). My favorite was a top down zombie shooter I made. I even as a bonus made the zombie capsules ragdoll and blast away when they died, it was comical.
The way Josh bumps the mic at the very end is so cute.
You know he's super passionate about something when he moves enough to bump the mic.
It made me smile :)
This is perfect advice. I've been working on my "magnum opus" of sorts for the past 8 years. Spent an extreme amount of time and money on it that I will very likely not see a tangible return on. I have made a lot of smaller games in the past, but absolutely nothing that even comes close to this scale. Development has been brutal. I would highly recommend that any aspiring devs start small.
What an awesome yet simple suggestion.
Start really small, polish it and then make something slightly bigger and better.
I’ll take this advice to heart.
00:17 "Destroying things - Super easy". Sure. For the destroyer of Tera it's barely an inconvenience.
Im in the same boat, and while I know my graphics will never compete with big-studio ARPGs, I'm focusing on the combat and small things I can manage.
Josh Strife Based
My heart sank in the most positive way possible hearing you mention Adam Bohn and the games that made up my childhood.
This is exactly how i ended up with a very complex excel sheet that calculated the stat increases in FFTA2 so i could maximize character stats. Now i use those same skills to make really complex sheets at work and i can whip up new game related sheet within an hour instead of the days it originally took me
Working as a solodev, keeping scale relatively small and avoiding feature creep is important
This makes so many senses in so many contexts. Sometimes is difficult to convince other people working with us that maybe stepping down and trimming a few things coulde be the best choice
Very good advice and short video. Straight to the point.
Yeah, it could actually be shorter, but it's an edit from stream, not prerecorded.
One of the best Bits of Advice I've ever heard...
Thank you for this! I'll definitely apply it :)
I got this same advice from my tutor at trade school, focus on small wins. This one piece of advice is golden.
Last year, I made a 200-word tabletop roleplaying game every month. This advice works.
Thank you for this amazing advice Josh!
legit good advice, career programmers say this as well
Actually legit advice. It works for programming as well. Learn all the features on their own, and how to use them in various ways, and then integrate the parts into a new whole.
Josh with the big brother energy and solid advice, thanks man
Extremely good advice! I got into a programming college so I could make a game some day. Getting there opened my eyes on what a mountain of a task is to actually make any application, let alone a game. I graduated college and I am now working on my master's degree. I worked on many applications since then. All are quite small, but each one has thought me something new. While I still don't think I am ready to develop a game yet (home made game engine, be damned!), I still code whatever random application comes to my mind to improve my overall skills as a programmer.
You know, a lot of these streamers don't actually know how development works
Josh is different. This is great advice. Start with something simple like an asteroid shooter.
Needed this reminder. And Josh made good points about it too. For a long time, I heard, "dont do the big game, do many small games. They'll all gonna suck, but thats fine."
Well, I never really saw the use of small games if I wasn't interested in them. I'm a perfectionist too, all my games got to at least look decent. Whats a game if no one played it?
Josh says its about learning one thing at a time... and I can respect that. I have too many things going on and its probably something I should've started doing one by one xD
I'm just starting my game development journey and this is really good advice, so thanks.
A journey of a thousand miles begins with a single step.
- Lao Tzu
With the cooking advice, I'd add a piece. Learn to cook each item, like he said, but then learn to do two at a time. Learning to manage two items at once in cooking is a change to the skill set. Then do three. See how the timing changes so you can have all three done to plate. Then put it all together. It really stinks when your waiting for your side dishes to finish as your main course is slowly getting cold.
Constraints are GOOD. Limits HELP you. If you only have 5 days, or even a weekend, to produce somehting, it allows you to quickly scope out the work and decide what you can do in that time. It also means you don't spend a ton of time in analysis-paralysis. If you only have a weekend to finish some kind of hackathon, that means you need to limit your planning to just a few hours. So you need to figure out the broad strokes of what you're going to accomplish in that time, and a rough idea of the path to take. You can also brutally discard any ideas that will push you beyond your preset limit.
My favourite example of limits helping is Monty Python and the Holy Grail. In that case, the limit was the budget. They didn't have enough money for horses, so they came up with the coconut thing, which became one of the funniest running gags ever. The movie is BETTER because they couldn't afford horses. There are other examples of this too - where limits ended up helping.
For this I love commercials. You have 30 seconds to tell a story - to make an impression. To make someone laugh. Remember vines? You had only 6 SECONDS to do something, and there were tons of hilarious videos in those 6 seconds.
Solid advice indeed, walking a mile one step at a time.
I struggle a lot with putting massive expectations on myself, but something I've found helpful is to try to remember that any contribution is a contribution. Anything you make with genuine love is going to make the world a better place, even if it's only by a little bit. By creating something- of any level of quality- and putting it out into the world, you are giving the world a gift. It might be really bad. Maybe only a few random people see it, maybe only your closest friends, maybe just one of your parents or a sibling. Maybe it's just something for you. But by creating it, you have contributed something valuable, something only you can contribute.
This also goes for Writing, visual art, or dancing, any other art form really. You can write an outline or sketch notes for your big project, and maybe even work on it a little, but you will improve more doing small things, that you can learn from in the process, and your big project will benefit from your experience.
1: Come up with an idea.
2: Scope lower to the absolute basics.
3: Make a vertical slice of it.
4: Make it publicly available and see if people like it.
Best advice ever. The key concept of making something is to iterate.
Pragmatically speaking: Use an ECS architecture. It allows you to compose features much more easily than other architectures. Still make one small thing after the other, but if you do keep an eye on keeping your systems up to date with your data model, you will, after a bunch of small things, have a bunch of functionalities that you can weave into one big thing easily.
When it comes to learning concepts (especially spending time learning the engine and coding) I find it hard to be motivated to make things that may or may not have any relevance to the main thing I want to do, just like you’d look at a math problem and think ‘well, that’s not something I’ll ever use’. But the great thing about this field is that you can learn by necessity. It’s actually better to not try and memorize everything all at once all the time. I build a small thing, build it up, and then make another small related system/class and add it in, problem solve, and add more and more pieces to build the whole. It’s fun and feels meaningful. This isn’t advice but I feel like it’s helped me grow from nothing
Good advice. Take a look at the first game created by companies making triple A games now. Blizzard's first game was RPM racing. id's first game was Commander Keen. Activision started with Atari 2600 games. EA made Ultima 1. There are a lot of other example's like this. They all started with games a single developer could replicate and improved from there in less than a single person's lifetime.
Worth pointing out that EA didn't have anything to do with Ultima until way later and Ultima wasn't even the first game that Richard Garriot made.
Akalabeth was the first retail release he did and even that wasn't the first game he made.
It's also worth making a greater distinction between the publisher and the developer of games as EA (as implied by the name Electronic Arts) has always positioned itself as the video game equivalent of a record label. EA's first games were put out on the PC and Mega Drive, so would have been considerably more advanced than Ultima 1, but they were made by experienced programmers who had demonstrated their skills. The most important innovation they did in house was reverse engineering the cartridges for the Mega Drive and using that as leverage to get better licensing agreements from Sega
@@casanovafunkenstein5090 They're half publisher half developer and they outsource on a good bit of their developing.
I've started making a game 2 months ago and I've had some decent progress. My dream goal is pretty ambitious but all I'm doing right now is just a tiny slice of that. This advice is what gets you to do anything creative/technically demanding
Absolutely great advice! I'd add to this; (which is basically what you're saying) spend more time learning before you try to make something. You wouldn't try to create and album without learning to play guitar for a few years, so why do so many people think they can just jump in and start making games without any experience?
I'm approaching my game like this, I want to learn how to make a game, so I am taking a methodical approach, trying to understand all of the systems I will need to make at the most fundamental level, and document that in a notebook. It's really rewarding when you start with the most basic, ugly, get it done programming, and end it with an elegant, refined, and efficient system at the end. I can look at my notebook and see where I started and where I ended, and it motivates me to move on to the next step, one piece at a time. I have a good job, I make enough money, I don't NEED to finish my game in a week, a month, or a year. If I never finish the game, I will have at least enjoyed the learning experience of it all.
As a video game programmer by profession, this is a very legit advice for any aspiring developer.
Video game production is one of the most complex production pipeline out there right now. Going all in with a big project when you have little actual legit professional experience is project suicide.
Instead follow what Josh said:
1 - Build small.
2 - Build reusable things where it make sense to have them as such (especially if you code) in, and I can't stress that enough, a legit way. Don't throw things together and hope it's going to works out. It most likely won't for long. Design patterns and guidelines exists for a reason.
3 - Be thoughtful and thorough.
4 - Build slightly bigger stuff faster with the reusable things you've built.
5 - Enjoy a progressively more enjoyable and fast paced production pipeline when starting new projects or working on your current project.
Great advice. Thank you Josh.
This is true for everything. If you are faced with a large task that seems daunting. Divide it into three parts.
Then look at each part and consider it. Then divide those parts into three and continue until each task seems so easy to do!
Solid advice.
Start small.
Only rework/implement a single new system/mechanic at a time.
Started doing a simple space shooter game with gamemaker, did this every year for the past 2 years and set myself a deadline for 1 month. First game was very simple, very bad gameplay. Next years i used a lot of the old code to save some time, built a new UI, and used the rest of the time to adjust the gameplay. This year i want to try and see if i maybe can add a bossbattle to it, and go in small steps. Helped me a lot to overcome the frustration. You can do it too!
yes i was waiting a couple of years before starting now that this video is out i can finaly begin.
Definitely agree with making a few small things first. If nothing else, you learn a few skills and find what you shouldn't spend forever working on.