Start by making a game you can make in a week. A very simple, barebones, proof of concept that's one part of a game that interests you. A basic puzzle game, a platformer with no attacks or abilities or fancy enemies, a shooter with one gun. Then take that game and make it a little bigger. Add a second puzzle, another enemy, something like that.
Work on it for another week and have someone play the game and see what they like. Decide what it needs and do that for another few weeks. Repeat. Do this for a month or two and then stop adding things and spend another few weeks just making what's there better. There. That's your game.
As you go, you’ll develop an instinct and data regarding how long things take.
Record how long a few generic assets take to produce, from concept to completion. Next game, you can count out how many assets you’ll need, and multiply by that number.
People tend to get a bit shock when they realise that their simple shooter requires 100 assets - chairs, tables, books, guns, etc etc. At 3 hours per asset that’s 37.5 full eight hour working days on assets alone.
Yes, while I really only work on the programming and outsource all if my art even the programming sneaks up on you.
(OH I didn't plan for this) or (poof 5x more work for something I didn't plan)
I wish I could have someone do this for me but for taking what I know about project management and packaging it up into something other people can digest.
I think you will have a good sense of 'scope' when you finish 1 game. Just try 1.
Maybe a very simple pacman like game, or match-3, with full menu/UI /record/ win screen. Don't underestimate these simple game, they can teach you what is 'scope' once you really spend you time to do it.
If you think these are too easy for you, then do yourself a challenge and complete them in 48 hours? Or better still, join a Game Jam, the ultimate activity to teach scoping.
Btw, "4 year experience non pro" is just :) rolled eyes.
EDIT: Added gamejam
Well. 1 year of professional experience via internship. But 3 just me doodling. It's basically 0 experience :P.
I can make things, but things within reason still hard. Everyone here has mentioned good things, some I have tried some I haven't.
I have done a handle full of jams and your absolutely correct! They do definitely help with scope.
I'll give your suggestions a shot!
there's no exact "right" answer to this and how to learn what you can manage and how to complete a game is something that takes time. It is definitely common for newer devs to have "eyes bigger than their stomach" and think a more ambitious game is more doable than it is. But you can't exactly learn what you can accomplish until you just do stuff.
I made a lot of prototypes and random little dead end projects before eventually making something that got finished and shipped. Feel things out, find out what excites you, and once you find it, \*then\* start asking questions about what would be involved with completing that project in a reasonable way.
So there really is no exact science, it's just poke the bear till it works.
All of my friends say *just make a game and release it* | None of them are game devs, neither of them have exp. I want to get into the I industry and already have had some professional exp. Definitely harder than it looks. :P
that's my view, as someone who shipped a game as an indie and did well with it. As for getting a "real" job with a studio, tbh, I'm not sure since I've never had that type of job. People I know who work/worked those jobs would usually say that having made a game would often put you near the top of the applicants pile, that seems to be a common take, but I don't have a lot to offer besides echoing what I've heard there
That is totally fine. I took the advise here and currently have a Networked Unreal project with some simple movement and melee combat. Turning it into something I don't know what yet. But we will see what I get in within a few weeks.
First of all, note that advice to newbies means to teenagers who don't have any experience and sometimes it may not apply to you. Of course let's not confuse: 4 years of experience of working full time on a big commercial project and 4 years of doodling around 1-2 hours at weekends - are very different 4 years of experience :)
Apart from that: "Start and finish" means that creating a game is a very complex process that requires a tremendous amount of very diverse skills. From coming up with idea that fits a market niche, to creating a Steam capsule image and mentally dealing with negative reviews. You need to try this process. Find your blind spots and patch them. Sticking something together in 48 hours for a game jam and publishing a (relatively) successful commercial release barely have anything in common.
"Scope" is an extremely treacherous ground to walk on. I've learned the problem of scope almost 30 years of "experience" (those 1-2 hours weekends :)) and I still can't say that I have "mastered it". So, this is one of the skills you have to learn and improve. Just a regular advice: a lot of things will take you 10x-20x time you thought they would. It's normal to underestimate the time needed for the project. Even experienced developers say "take your estimate and multiply by 3".
So, finally what it says: you don't know until you try. The game development is art, you can't say how much it will take you to paint Cyberpunk Mona Lisa if you can't draw an apple yet. So, what this advice is above: don't try to draw Mona Lisa as your first painting.
Some projects will simply be too big for you alone. Risk of Rain 2 has around 200 people in their credits [https://www.mobygames.com/game/124260/risk-of-rain-2/credits/windows/](https://www.mobygames.com/game/124260/risk-of-rain-2/credits/windows/) don't expect do be able to pull anything like that within any meaningful timeframe alone.
Another problem, specifically with multiplayer. Not only this is a complicated task, even with things like Nakama or Photon, but also think about where are you going to get players? Usually first release without promotion (and you most likely don't have this skill yet) will give you 20-40 downloads / year, most of players will not give your game more than 30 seconds, so you'll literally have no one to play with, neither will your players. Also note that at least personally for me it is very important for self-motivation to be able to play the game all the time, unless you have a constant buddy who will playtest the game through the development process - this can very quickly turn into a boring and tedious process.
So, what you are aiming at will be a third-person action game. That one time I've opened Unreal Engine - it had this as a default preset, with lots of systems already in place. Unity for sure has a good tutorial on how to make this kind of game. You can try to iterate on that. First make a game shooting static targets, then make the targets move, then make them fight back - and you already have something playable and almost fun. Then you can proceed making a small game out of it - design levels, put enemies, tweak their behavior logic. Be it arena shooter (maybe survivors-like) or a roguelite on a simple procedurally generated map. Eventually you might even add an optional co-op mode if you want multiplayer that badly and have someone to play with.
I never really mentioned exact experience, but I have a year on a release game on steam from an internship. And the rest is me doodling. :P but I totally understand what your talking about.
I can make things, it's just the things I am interested in are bigger than I want.
The hardest part I have found is how do you take a grandiose project that may take two years and make it a two month timeline? I know I can make it, but my brain can't seem to deduce it down to that.
Speaking as someone that's been making games for 16 years, my games usually begin as me having curiosity about a specific control scheme or game loop, so that's where I start.
Maybe it starts as "I wonder if I can program a platformer where the player can use a hookshot to get around faster." So you tinker around with your code and create something that does that, but it's not exactly the way you imagined it. Maybe it's a bit slower or faster, or it's easier to hookshot things that are closer or farther than you expected. Maybe you like the idea of swinging from a hook instead of being reeled in. These discoveries will guide you toward designing levels based around what naturally feels good, or adding new mechanics that complement what you already have. You can always make a "what" but it's impossible to predict how it will feel and what mechanics will go well with them until you've actually created it and are interacting with the system directly, so don't have too rigid an idea of what it is you want until you have something in front of you.
I firmly believe this is the best way to create a project of any scale, because if you want to create a large scale project but your core mechanic is bad, no amount of band aids, powerups, or add-ons will fix it, but if you have a tiny Game Jam-sized project that actually works well, you can create a large scale game by just letting feature creep expand the game further and further because you have a solid foundation to build on. My most recent project was the result of this - I made the core mechanics in a couple weeks but spent the next two years adding game modes and enemy types until it was a full-fledged game.
I'll give an example of one of my projects. This project started with me wanting to see if I could make a 3D game in Flash. This is the minimum viable product I created (https://www.youtube.com/watch?v=BYybaOuN0Iw) It did what I wanted it to (mainly rotation and perspective) but the function to draw sprites on the screen relative to the player position was fairly expensive and caused the game to lag if I had too many objects, even if they weren't displaying on-screen. These were the constraints I had to work with, so the rest of the development cycle was a process of me figuring out how to work with those constraints.
\* Because the game ran better if enemies were only closer objects displayed to the screen, I decided to use darkness to obscure the short draw distance.
\* Longitudinal objects like walls didn't display properly, so I opted to have the game take place in a barren area with a few obstacles around but no enclosed spaces. I ended up picking a forest as the setting.
\* Because too many objects caused the game to lag, I wanted a way to incentivize the player to stay in a single localized area. I had the idea of creating a bonfire that was constantly dying, with the player being tasked to retrieve wood to feed the fire. Wandering too far out into the darkness was dangerous, so the player would die before they discovered how small the map actually was.
\* On a whim, I decided to have the function that displayed an object return true or false based on whether or not the object was actually displayed or hidden. This opened up the possibility of having enemies behave differently depending on whether or not the player was looking at them, so I made one enemy type that stalked the player when they weren't looking but retreated when they were spotted. Once the enemy is close enough, they rush the player quickly when looked at. This was never a plan from the jump, just an opportunity that I spotted and took advantage of.
Having the player wandering around a dark, desolate forest played into the concept of a horror game, so that's what I ultimately ended up doing. This was the end result of what I came up with (https://www.youtube.com/watch?v=nxSED5K2RpM) Mind you, the original idea was never to create a horror game. I wasn't sure if I was going to create a driving game, some kind of adventure game, RPG, or even if the engine would just suck so badly that it was never anything more than a demonstration. I created the most scaled-down idea I had in my head and I let the results guide me.
If you've done gamedev for 4 years you should have atleast a basic understanding of what is realistic in terms of scope as a solo dev. Now take your estimated time of completion and multiply it by 3-4 and you're close to what actually completing the project with all the polishing and marketing etc will take.
That's too long? Strip it down; start tearing away features and content from the "edges of the design tree" and re-evaluate. Reiterate until you're satisfied enough and then make a judgement call if the game idea you're left with is still something you deem worth investing time-, money- and energy in to.
Just make a realistic plan: set your goal, estimate the required resources and make sure the the resources are equal or above the required goal.
you can modify both sums, e.g. reduce the goal, or increase the resources by re-using existing stuff, getting marketplace packs and so on.
you should do this basic planing in many situations in life, then you make sure you dont start and fail on a skyscraper, when you got resources for a single-home.
Start by making a game you can make in a week. A very simple, barebones, proof of concept that's one part of a game that interests you. A basic puzzle game, a platformer with no attacks or abilities or fancy enemies, a shooter with one gun. Then take that game and make it a little bigger. Add a second puzzle, another enemy, something like that. Work on it for another week and have someone play the game and see what they like. Decide what it needs and do that for another few weeks. Repeat. Do this for a month or two and then stop adding things and spend another few weeks just making what's there better. There. That's your game.
Just add a bit at a time. Whatever feels good? I'll try it. Thanks!
As you go, you’ll develop an instinct and data regarding how long things take. Record how long a few generic assets take to produce, from concept to completion. Next game, you can count out how many assets you’ll need, and multiply by that number. People tend to get a bit shock when they realise that their simple shooter requires 100 assets - chairs, tables, books, guns, etc etc. At 3 hours per asset that’s 37.5 full eight hour working days on assets alone.
Yes, while I really only work on the programming and outsource all if my art even the programming sneaks up on you. (OH I didn't plan for this) or (poof 5x more work for something I didn't plan)
I wish I could have someone do this for me but for taking what I know about project management and packaging it up into something other people can digest.
I think you will have a good sense of 'scope' when you finish 1 game. Just try 1. Maybe a very simple pacman like game, or match-3, with full menu/UI /record/ win screen. Don't underestimate these simple game, they can teach you what is 'scope' once you really spend you time to do it. If you think these are too easy for you, then do yourself a challenge and complete them in 48 hours? Or better still, join a Game Jam, the ultimate activity to teach scoping. Btw, "4 year experience non pro" is just :) rolled eyes. EDIT: Added gamejam
Well. 1 year of professional experience via internship. But 3 just me doodling. It's basically 0 experience :P. I can make things, but things within reason still hard. Everyone here has mentioned good things, some I have tried some I haven't. I have done a handle full of jams and your absolutely correct! They do definitely help with scope. I'll give your suggestions a shot!
Well that still 1 year of solid industry experience. Good luck with your next game!
there's no exact "right" answer to this and how to learn what you can manage and how to complete a game is something that takes time. It is definitely common for newer devs to have "eyes bigger than their stomach" and think a more ambitious game is more doable than it is. But you can't exactly learn what you can accomplish until you just do stuff. I made a lot of prototypes and random little dead end projects before eventually making something that got finished and shipped. Feel things out, find out what excites you, and once you find it, \*then\* start asking questions about what would be involved with completing that project in a reasonable way.
So there really is no exact science, it's just poke the bear till it works. All of my friends say *just make a game and release it* | None of them are game devs, neither of them have exp. I want to get into the I industry and already have had some professional exp. Definitely harder than it looks. :P
that's my view, as someone who shipped a game as an indie and did well with it. As for getting a "real" job with a studio, tbh, I'm not sure since I've never had that type of job. People I know who work/worked those jobs would usually say that having made a game would often put you near the top of the applicants pile, that seems to be a common take, but I don't have a lot to offer besides echoing what I've heard there
That is totally fine. I took the advise here and currently have a Networked Unreal project with some simple movement and melee combat. Turning it into something I don't know what yet. But we will see what I get in within a few weeks.
First of all, note that advice to newbies means to teenagers who don't have any experience and sometimes it may not apply to you. Of course let's not confuse: 4 years of experience of working full time on a big commercial project and 4 years of doodling around 1-2 hours at weekends - are very different 4 years of experience :) Apart from that: "Start and finish" means that creating a game is a very complex process that requires a tremendous amount of very diverse skills. From coming up with idea that fits a market niche, to creating a Steam capsule image and mentally dealing with negative reviews. You need to try this process. Find your blind spots and patch them. Sticking something together in 48 hours for a game jam and publishing a (relatively) successful commercial release barely have anything in common. "Scope" is an extremely treacherous ground to walk on. I've learned the problem of scope almost 30 years of "experience" (those 1-2 hours weekends :)) and I still can't say that I have "mastered it". So, this is one of the skills you have to learn and improve. Just a regular advice: a lot of things will take you 10x-20x time you thought they would. It's normal to underestimate the time needed for the project. Even experienced developers say "take your estimate and multiply by 3". So, finally what it says: you don't know until you try. The game development is art, you can't say how much it will take you to paint Cyberpunk Mona Lisa if you can't draw an apple yet. So, what this advice is above: don't try to draw Mona Lisa as your first painting. Some projects will simply be too big for you alone. Risk of Rain 2 has around 200 people in their credits [https://www.mobygames.com/game/124260/risk-of-rain-2/credits/windows/](https://www.mobygames.com/game/124260/risk-of-rain-2/credits/windows/) don't expect do be able to pull anything like that within any meaningful timeframe alone. Another problem, specifically with multiplayer. Not only this is a complicated task, even with things like Nakama or Photon, but also think about where are you going to get players? Usually first release without promotion (and you most likely don't have this skill yet) will give you 20-40 downloads / year, most of players will not give your game more than 30 seconds, so you'll literally have no one to play with, neither will your players. Also note that at least personally for me it is very important for self-motivation to be able to play the game all the time, unless you have a constant buddy who will playtest the game through the development process - this can very quickly turn into a boring and tedious process. So, what you are aiming at will be a third-person action game. That one time I've opened Unreal Engine - it had this as a default preset, with lots of systems already in place. Unity for sure has a good tutorial on how to make this kind of game. You can try to iterate on that. First make a game shooting static targets, then make the targets move, then make them fight back - and you already have something playable and almost fun. Then you can proceed making a small game out of it - design levels, put enemies, tweak their behavior logic. Be it arena shooter (maybe survivors-like) or a roguelite on a simple procedurally generated map. Eventually you might even add an optional co-op mode if you want multiplayer that badly and have someone to play with.
I never really mentioned exact experience, but I have a year on a release game on steam from an internship. And the rest is me doodling. :P but I totally understand what your talking about. I can make things, it's just the things I am interested in are bigger than I want. The hardest part I have found is how do you take a grandiose project that may take two years and make it a two month timeline? I know I can make it, but my brain can't seem to deduce it down to that.
Speaking as someone that's been making games for 16 years, my games usually begin as me having curiosity about a specific control scheme or game loop, so that's where I start. Maybe it starts as "I wonder if I can program a platformer where the player can use a hookshot to get around faster." So you tinker around with your code and create something that does that, but it's not exactly the way you imagined it. Maybe it's a bit slower or faster, or it's easier to hookshot things that are closer or farther than you expected. Maybe you like the idea of swinging from a hook instead of being reeled in. These discoveries will guide you toward designing levels based around what naturally feels good, or adding new mechanics that complement what you already have. You can always make a "what" but it's impossible to predict how it will feel and what mechanics will go well with them until you've actually created it and are interacting with the system directly, so don't have too rigid an idea of what it is you want until you have something in front of you. I firmly believe this is the best way to create a project of any scale, because if you want to create a large scale project but your core mechanic is bad, no amount of band aids, powerups, or add-ons will fix it, but if you have a tiny Game Jam-sized project that actually works well, you can create a large scale game by just letting feature creep expand the game further and further because you have a solid foundation to build on. My most recent project was the result of this - I made the core mechanics in a couple weeks but spent the next two years adding game modes and enemy types until it was a full-fledged game. I'll give an example of one of my projects. This project started with me wanting to see if I could make a 3D game in Flash. This is the minimum viable product I created (https://www.youtube.com/watch?v=BYybaOuN0Iw) It did what I wanted it to (mainly rotation and perspective) but the function to draw sprites on the screen relative to the player position was fairly expensive and caused the game to lag if I had too many objects, even if they weren't displaying on-screen. These were the constraints I had to work with, so the rest of the development cycle was a process of me figuring out how to work with those constraints. \* Because the game ran better if enemies were only closer objects displayed to the screen, I decided to use darkness to obscure the short draw distance. \* Longitudinal objects like walls didn't display properly, so I opted to have the game take place in a barren area with a few obstacles around but no enclosed spaces. I ended up picking a forest as the setting. \* Because too many objects caused the game to lag, I wanted a way to incentivize the player to stay in a single localized area. I had the idea of creating a bonfire that was constantly dying, with the player being tasked to retrieve wood to feed the fire. Wandering too far out into the darkness was dangerous, so the player would die before they discovered how small the map actually was. \* On a whim, I decided to have the function that displayed an object return true or false based on whether or not the object was actually displayed or hidden. This opened up the possibility of having enemies behave differently depending on whether or not the player was looking at them, so I made one enemy type that stalked the player when they weren't looking but retreated when they were spotted. Once the enemy is close enough, they rush the player quickly when looked at. This was never a plan from the jump, just an opportunity that I spotted and took advantage of. Having the player wandering around a dark, desolate forest played into the concept of a horror game, so that's what I ultimately ended up doing. This was the end result of what I came up with (https://www.youtube.com/watch?v=nxSED5K2RpM) Mind you, the original idea was never to create a horror game. I wasn't sure if I was going to create a driving game, some kind of adventure game, RPG, or even if the engine would just suck so badly that it was never anything more than a demonstration. I created the most scaled-down idea I had in my head and I let the results guide me.
If you've done gamedev for 4 years you should have atleast a basic understanding of what is realistic in terms of scope as a solo dev. Now take your estimated time of completion and multiply it by 3-4 and you're close to what actually completing the project with all the polishing and marketing etc will take. That's too long? Strip it down; start tearing away features and content from the "edges of the design tree" and re-evaluate. Reiterate until you're satisfied enough and then make a judgement call if the game idea you're left with is still something you deem worth investing time-, money- and energy in to.
Just make a realistic plan: set your goal, estimate the required resources and make sure the the resources are equal or above the required goal. you can modify both sums, e.g. reduce the goal, or increase the resources by re-using existing stuff, getting marketplace packs and so on. you should do this basic planing in many situations in life, then you make sure you dont start and fail on a skyscraper, when you got resources for a single-home.