Though in some circumstances I'd disagree with point 1. For the following reasons:
1. Finishing games can take a long time and the end is usually the part of the project where one gets to exercise the least creativity (and so you're also likely to learn the least from this part of the process).
2. Perseverance is easy when you're working on a good game, learning to persevere through finishing a bad game is impressive, but not actually a particularly useful skill (as releasing bad games isn't the goal most of us set for ourselves).
3. Learning to make good games is a far better goal than finishing every game you start, and because you have limited time, and these goals are in competition for your time, so it's more productive to start with learning to develop good games (and then try finish one when it actually is worth finishing).
So I'd much rather phrase Point 1 as: Don't stop developing your games as soon as you've revealed them, rather use the feedback you'll receive to improve the game (as using feedback to improve games is a SUPER useful skill and if you ignore this part of the process you'll miss a lot of opportunities to better understand players of your games).
Of course there are problems that occur only towards the end of significant games projects, but if you can't start a game project that is worth finishing then I'd suggest knowing the solutions to those problems is somewhat moot.
And obviously knowing where to spend your time on which projects and when to drop a project and start something new is a very difficult problem and there's no one size fits all strategy. My rule of thumb is work on the things that motivate me and appear to have a path towards something sustainable, and to try maximize learning, until some project looks like it'll be worth finishing (and sacrificing all that time doing end of project grunt work will be repayed with some kind of currency, be it money or something else I can use, upon completion).
Programming games is hard, extremely hard... I wish there was a book that showed you how to do everything or had patterns that showed how to complete a game... But the thing is that information is scattered, and as a game programmer you must figure out how to put it together. Time is always pressuring you and people always think you write strange symbols that will never work. You want to write a projectile class that will hit the enemies at some Bezier curve movement then it misses bcoz you decided to use skeletal animation and you are using a JavaScript tutorial you just converted to c++ using different engines when that JavaScript tutorial was using simple aabb collision and you realize you must switch physics based collisions, but the problem now is that your entire game has not been integrated with physics engine and the only knowledge you have of box2d is when you were learning actionscript and you now have to intergrate that into 50+ classes that took you 6 months to write and now you must learn extra software like Rube which was not on the list in the initial design.
So making games is not only hard, it is extremely crazy and depressing ... Especially when you are poor and things keep on crashing
@MoonPanda Yeah, I do think there are times when finishing something is better than dropping it, like for instance if you are working on something and you haven't shown anyone yet. And there are going to be times when dropping a project is a better course than seeing it to completion. I think choosing what to work on is one of the trickiest problems one faces in game development (and it doesn't help that most of us get so emotionally involved in our work).
@EvanGreenwood, I wouldn't say dropping it but taking a break from it, as requirements at that moment do not allow you to continue, so you move to the next project. Once you get stuck on this one, you might have an idea of what to add on the previous one. This is the approach I use to keep out of stress. At first I was criticizing myself for being stupid not realizing that even industry veterans do get stuck too... And not having funding too can be detrimental to getting stuck as you don't have enough motivation to keep you going and other pressures from outside world can demoralize you very bad, as you see your friends who do louzy jobs, make a lot of money from it, family pressure, lot of expectations from friends of friends. You end up feeling like if you fail you would have failed everybody else and you were better of with 9-5 job but you can't do it because you love games so much.
Regardless of all the pressures we get, we keep on going and one day there will be a reaping day.
@SkinnyBoy Yeah! Jumping between projects can be a good way to stay motivated (and motivation is the most precious resource we all have).
I've seen this work on a micro-level as well, like within one project there's sometimes a task that is really daunting and hard to get stuck into, so a good trick is to start the day with doing something relatively small and easy, and if you accomplish that then often you'll feel more able to do the difficult thing. It feels like having a recent win behind you is really good for motivation in general.
Rami Ismail gave a talk at Wits University once where his main point was motivation is your most precious resource. Like you can have all the money, and have all the talent, but if you're not motivated you still can't make a game. It's easy to find yourself in a position where you get stuck due to a crippling lack of motivation, so you've got to be very wary of the choices you make, the projects you choose,, the people you collaborate with, the environment you work in, even how you talk about the projects you're working on.
I could go into a lot more detail... I'm not sure how useful this information is (and I'm not exactly an expert, I do struggle with motivation myself). If this is something people want to here more about I could do a talk about it at a Make Games meetup?
@EvanGreenwood is 100% on motivation being the most important factors and I think its a very valid point to add to this discussion, I personally fight with motivation on a daily basis, here's my 2c:
When we started out, we didn't have much money but our passion and drive of what we were building gave us the fuel to go on, and the motivation pulled us through the tough times, because every project is a roller coaster of ups and downs.
"...you've got to be very wary of the choices you make, the projects you choose.." that is the most important point here - it's all about effort vs reward, are you working on a project that is worth your time, ROI etc etc so to find the project(s) that motivates you is the real trick.
I remember watching an interview once where Pixar animation studios were worried if they would fall into a "Second product syndrome" when they produced the first Toy Story, they had massive success, but could they do it again with the next feature and would they have the motivation to go on like they did at first.
2. Perseverance is easy when you're working on a good game, learning to persevere through finishing a bad game is impressive, but not actually a particularly useful skill (as releasing bad games isn't the goal most of us set for ourselves).
I fully agree that releasing bad games is not an ideal end goal. However, in my experience, it is an incredibly useful skill to learn what is involved in actually seeing a game through to completion. Having the patience and focus to overcome the monotony of the dreaded Final Ten Percent is something that I want to have engrained into every single member of any team that I may be a part of!
Working on a game that is fresh and new and exciting is easy. Probably the single easiest part of game development. Like any relationship, this honeymoon period is full of energy and excitement and great sex. I don't want to be working with people who are ready to throw the baby out with the bath water as soon as the road starts to become bumpy. Commitment is a thing that needs training and practice. You have to work at it. It is a skill.
That said, on the flip side, you also don't want to ignore irreconcilable differences and end up in a situation where you are getting married for the wrong reasons, so yes, caution comes into play, but to say that "finishing a bad game doesn't generate useful skills" isn't something that rings true with me :)
@AngryMoose Agreed. I think I may have phrased that a bit too strongly. I've watched several South African developers cause themselves a lot of unhappiness do a lot of damage to their lives because of, what I see as, being determined to finish games they shouldn't (and to use your metaphor, ending up in an unhappy marriage).
So I'm very cautious about this and very afraid that developers who aren't cautious will hear advice stating that perseverance is important and use it to justify their potentially calamitous choices. I don't want that on my conscience, so I think I overstated the point.
I think I'd much rather talk about good work ethic, even in the face of tiring thankless tasks, like you mention, as being important rather than finishing games as being important (when it comes to blanket advice like in the original post).
Also, I think my advice might apply more to artists and game designers than to programmers, who more than other roles need to see how a long term project evolves to understand the importance of how their code is set up at the start (and other insights that aren't apparent at the start of projects like where to optimize etc).
so what should i try and concentrate on at the start? I am busy with Godot Game Engine , will be doing Blender to make some nice assets. idea was to create a very simple blob roles in half circle and you can add thrust or push so it can land in a bowl or fall into nothingness ... just to get the game making concept going. tips for a bro?
@tinzo What you should concentrate on does depend somewhat on what you want to achieve. It sounds like you're giving a go at making games by yourself (which is a great way to get experience, even if you don't eventually want to be a one person development team).
I'd say the first thing you should focus on is getting a build of what you describe working and to show some people here on the forums. Upload a build for people to try out, but consider also making a gif of it (or a Youtube video). You can't learn much from talking about a game, but you can learn a lot from hearing/seeing how people interact with the thing you've made.
Especially if you're trying to learn game design, your goal should be to make lots of games an get as many people playing them as you can (in order to get feedback and so to learn). You should try make games that you definitely can achieve, but also where each game forces you to learn something new.
It sounds like you're already experimenting with making relatively simple experiences, which is a great start. If you can get your blob rolling in a half-circle, you should definitely post it in a thread, and then try experiment with adding onto it and to try figure out how to make the experience more enjoyable or more engaging. Whether that be adding in additional goals or achievements (like a scoring system) or changing the art to better capture peoples' attention (like making the blob a little skateboarder).
The first step is posting it somewhere where the community can engage with it and then asking questions. Did they enjoy it, if not, why not? What would improve the game? What are the things players want to do with the game? Are there things that players want to do that would be easy to add?
I guess my tip is to try get it working ASAP and then to try posting it and getting feedback (so that you can make your next decisions with better information).
Of course, if we all want to learn from each other we need to be all giving feedback (not just expecting feedback). So it's beneficial for us all if for every person who plays your game you try play someone else's game.
Comments
Though in some circumstances I'd disagree with point 1. For the following reasons:
1. Finishing games can take a long time and the end is usually the part of the project where one gets to exercise the least creativity (and so you're also likely to learn the least from this part of the process).
2. Perseverance is easy when you're working on a good game, learning to persevere through finishing a bad game is impressive, but not actually a particularly useful skill (as releasing bad games isn't the goal most of us set for ourselves).
3. Learning to make good games is a far better goal than finishing every game you start, and because you have limited time, and these goals are in competition for your time, so it's more productive to start with learning to develop good games (and then try finish one when it actually is worth finishing).
So I'd much rather phrase Point 1 as: Don't stop developing your games as soon as you've revealed them, rather use the feedback you'll receive to improve the game (as using feedback to improve games is a SUPER useful skill and if you ignore this part of the process you'll miss a lot of opportunities to better understand players of your games).
Of course there are problems that occur only towards the end of significant games projects, but if you can't start a game project that is worth finishing then I'd suggest knowing the solutions to those problems is somewhat moot.
And obviously knowing where to spend your time on which projects and when to drop a project and start something new is a very difficult problem and there's no one size fits all strategy. My rule of thumb is work on the things that motivate me and appear to have a path towards something sustainable, and to try maximize learning, until some project looks like it'll be worth finishing (and sacrificing all that time doing end of project grunt work will be repayed with some kind of currency, be it money or something else I can use, upon completion).
So making games is not only hard, it is extremely crazy and depressing ... Especially when you are poor and things keep on crashing
Regardless of all the pressures we get, we keep on going and one day there will be a reaping day.
I've seen this work on a micro-level as well, like within one project there's sometimes a task that is really daunting and hard to get stuck into, so a good trick is to start the day with doing something relatively small and easy, and if you accomplish that then often you'll feel more able to do the difficult thing. It feels like having a recent win behind you is really good for motivation in general.
Rami Ismail gave a talk at Wits University once where his main point was motivation is your most precious resource. Like you can have all the money, and have all the talent, but if you're not motivated you still can't make a game. It's easy to find yourself in a position where you get stuck due to a crippling lack of motivation, so you've got to be very wary of the choices you make, the projects you choose,, the people you collaborate with, the environment you work in, even how you talk about the projects you're working on.
I could go into a lot more detail... I'm not sure how useful this information is (and I'm not exactly an expert, I do struggle with motivation myself). If this is something people want to here more about I could do a talk about it at a Make Games meetup?
When we started out, we didn't have much money but our passion and drive of what we were building gave us the fuel to go on, and the motivation pulled us through the tough times, because every project is a roller coaster of ups and downs.
"...you've got to be very wary of the choices you make, the projects you choose.." that is the most important point here - it's all about effort vs reward, are you working on a project that is worth your time, ROI etc etc so to find the project(s) that motivates you is the real trick.
I remember watching an interview once where Pixar animation studios were worried if they would fall into a "Second product syndrome" when they produced the first Toy Story, they had massive success, but could they do it again with the next feature and would they have the motivation to go on like they did at first.
Working on a game that is fresh and new and exciting is easy. Probably the single easiest part of game development. Like any relationship, this honeymoon period is full of energy and excitement and great sex. I don't want to be working with people who are ready to throw the baby out with the bath water as soon as the road starts to become bumpy. Commitment is a thing that needs training and practice. You have to work at it. It is a skill.
That said, on the flip side, you also don't want to ignore irreconcilable differences and end up in a situation where you are getting married for the wrong reasons, so yes, caution comes into play, but to say that "finishing a bad game doesn't generate useful skills" isn't something that rings true with me :)
So I'm very cautious about this and very afraid that developers who aren't cautious will hear advice stating that perseverance is important and use it to justify their potentially calamitous choices. I don't want that on my conscience, so I think I overstated the point.
I think I'd much rather talk about good work ethic, even in the face of tiring thankless tasks, like you mention, as being important rather than finishing games as being important (when it comes to blanket advice like in the original post).
Also, I think my advice might apply more to artists and game designers than to programmers, who more than other roles need to see how a long term project evolves to understand the importance of how their code is set up at the start (and other insights that aren't apparent at the start of projects like where to optimize etc).
I'd say the first thing you should focus on is getting a build of what you describe working and to show some people here on the forums. Upload a build for people to try out, but consider also making a gif of it (or a Youtube video). You can't learn much from talking about a game, but you can learn a lot from hearing/seeing how people interact with the thing you've made.
Especially if you're trying to learn game design, your goal should be to make lots of games an get as many people playing them as you can (in order to get feedback and so to learn). You should try make games that you definitely can achieve, but also where each game forces you to learn something new.
It sounds like you're already experimenting with making relatively simple experiences, which is a great start. If you can get your blob rolling in a half-circle, you should definitely post it in a thread, and then try experiment with adding onto it and to try figure out how to make the experience more enjoyable or more engaging. Whether that be adding in additional goals or achievements (like a scoring system) or changing the art to better capture peoples' attention (like making the blob a little skateboarder).
The first step is posting it somewhere where the community can engage with it and then asking questions. Did they enjoy it, if not, why not? What would improve the game? What are the things players want to do with the game? Are there things that players want to do that would be easy to add?
I guess my tip is to try get it working ASAP and then to try posting it and getting feedback (so that you can make your next decisions with better information).
Of course, if we all want to learn from each other we need to be all giving feedback (not just expecting feedback). So it's beneficial for us all if for every person who plays your game you try play someone else's game.