I think this is a very good plan. It is good to make simple games (or merely demos of the concept) first, because the distance between no game and a simple game is probably greater than between a simple game and a complex game. So if you make a simple game, you solve the problems on simple instances, and then you are ready to deal with them in more complex situations, because the core ideas are now clear.
For example, even very simple games usually contain a lot of the following: loading bitmaps from files, displaying bitmaps, loading music from files, playing music, reading user input, calculating coordinates, calculating movement, calculating collisions, timing and animations, keeping values in variables, switching between introductory screen and game screen and victory/defeat screen. -- Which is a lot of things, especially if you are doing it for the first time. And each of those things can become a separate problem, with subproblems, such as: “what to display on the screen while the bitmaps are loading, and what to do if the loading fails”. Also, the language and libraries may create additional problems, for example to make animations in Java you have to understand the thread model and synchonization, otherwise mysterious bugs can happen. And I am still speaking about a Pong-like game.
Then a complex game contains more of the previous things, plus: reading configuration files, saving and loading a game, AI opponents, perhaps an installation program. (And nicer graphics and music, but that is outside of the programming scope.)
So doing the simple game properly—not just on the “it works (most of the time)” level, but having a clear design and understanding how and why the parts cooperate—is a very good start for making a complex game.
(Here is a trick you may find useful: After making the algorithm, you can hugely improve the impression of the game by adding nice graphics, even when some parts of graphics are completely irrelevant to the algorithm. For examples if different levels have different background images; or if the level contains pictures that don’t interact with anything; or if the same thing is represented by different bitmaps in different levels, like trees with different shapes and colors, a level with things covered by snow, etc. A textbook example is the game Knytt. Also, nice screenshots create a good halo effect.)
Huh. After reading that, I’m thinking it might be more impressive to switch to something less ridiculously simple than Python.
More importantly though, you made a great point about the halo effect. I had completely forgotten to take that into account. On further reflection, I realized that I consistently forget to account for the halo effect, and that it may be in part because I wish to believe it does not exist. This could use some work.
it might be more impressive to switch to something less ridiculously simple than Python.
Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.
(I am not familiar enough with Python, so this is not a comment endorsing Python, just a reaction to the “less ridiculously simple” part. If two programs do the same thing, what’s wrong with the simpler one?)
I consistently forget to account for the halo effect, and that it may be in part because I wish to believe it does not exist.
Yeah. We programmers are proud of our ability to write complex code, so we wish complex code was the most admired thing about computer programs. Unfortunately, most people are impressed by nice screenshots. (At the first moment. When they use the program for some time, they start caring also about things like working properly, not crashing, etc. But to get them there, you need a nice screenshot first.)
“Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.”
I don’t know what potential employers are looking for (and now I realize that I haven’t even tried to find out), but I would expect them to be more impressed with a thing if I were to do it in a more ‘difficult’ language than if I did the same thing in a language that needed only two lines of code for the job. My focus is on signaling my skill, rather than completing the program itself.
Then again, I’m thinking it would be even more impressive to learn Python’s deepest secrets and exploit them to the max.
Data point, possibly completely irrelevant: When I am looking for a Java programmer job in Slovakia, pretty much the only thing employers care about is how many years did I program in Java and which frameworks did I use. -- Which in my opinion is completely stupid, because I consider the ability to write and understand algorithms much more important; and a new framework is just something you can learn in a month or two, if your algorithmic skills are solid. I guess the problem is with the fact that the employers who make the decision are not coders themselves, so speaking about algorithms is simply too abstract for them, but asking questions like “how many years?” and “are you familiar with XYZ, yes or no?” gives them a false sense of understanding.
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years. So another good question is: what kind of projects are the employers in your target group typically doing? (For Java programmer in Slovakia it is: a database application with a web interface, most likely in finance.) Then do a simple demo, using the “right” framework; which is the one most frequently mentioned in online job searches.
Note: In my case, programming games would be almost completely irrelevant to a real job experience. Although there would be some transferrable skills, such as commenting the code, maintaining a large program, understanding threads, etc. But I would completely miss communicating with the database and creating HTML pages, and knowing hundred specific details (and dozen bugs) of the relevant frameworks, which make most of my daily work.
But the problem is that there will be dozen frameworks doing pretty much the same thing, and new ones are still invented, and the old ones are redesigned. You just won’t have time to keep up with all of them. So the framework-based knowledge is prone to obsolescence, which drives some programmers into despair. You need to be more meta, and instead of “knowledge of framework X” focus on “ability to understand new frameworks”. (But you also need a deeper experience with one or two of them, just to learn what the painful parts are.)
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years.
Thank you, especially for this. I’ve been contemplating “looking good to potential future employers” type things, and it hadn’t occurred to me until just now to frame it as “consider exactly what it is said employer wants, minimise the distance between that and me (as presented by resume / portfolio / etc)”
Just to make sure, by “building portfolio” you mean making computer programs, or what? What kind of programs?
My current plan is to focus on simplistic games such as Pong and Caterpillar, as well as programs designed to play said games
I think this is a very good plan. It is good to make simple games (or merely demos of the concept) first, because the distance between no game and a simple game is probably greater than between a simple game and a complex game. So if you make a simple game, you solve the problems on simple instances, and then you are ready to deal with them in more complex situations, because the core ideas are now clear.
For example, even very simple games usually contain a lot of the following: loading bitmaps from files, displaying bitmaps, loading music from files, playing music, reading user input, calculating coordinates, calculating movement, calculating collisions, timing and animations, keeping values in variables, switching between introductory screen and game screen and victory/defeat screen. -- Which is a lot of things, especially if you are doing it for the first time. And each of those things can become a separate problem, with subproblems, such as: “what to display on the screen while the bitmaps are loading, and what to do if the loading fails”. Also, the language and libraries may create additional problems, for example to make animations in Java you have to understand the thread model and synchonization, otherwise mysterious bugs can happen. And I am still speaking about a Pong-like game.
Then a complex game contains more of the previous things, plus: reading configuration files, saving and loading a game, AI opponents, perhaps an installation program. (And nicer graphics and music, but that is outside of the programming scope.)
So doing the simple game properly—not just on the “it works (most of the time)” level, but having a clear design and understanding how and why the parts cooperate—is a very good start for making a complex game.
(Here is a trick you may find useful: After making the algorithm, you can hugely improve the impression of the game by adding nice graphics, even when some parts of graphics are completely irrelevant to the algorithm. For examples if different levels have different background images; or if the level contains pictures that don’t interact with anything; or if the same thing is represented by different bitmaps in different levels, like trees with different shapes and colors, a level with things covered by snow, etc. A textbook example is the game Knytt. Also, nice screenshots create a good halo effect.)
Huh. After reading that, I’m thinking it might be more impressive to switch to something less ridiculously simple than Python.
More importantly though, you made a great point about the halo effect. I had completely forgotten to take that into account. On further reflection, I realized that I consistently forget to account for the halo effect, and that it may be in part because I wish to believe it does not exist. This could use some work.
Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.
(I am not familiar enough with Python, so this is not a comment endorsing Python, just a reaction to the “less ridiculously simple” part. If two programs do the same thing, what’s wrong with the simpler one?)
Yeah. We programmers are proud of our ability to write complex code, so we wish complex code was the most admired thing about computer programs. Unfortunately, most people are impressed by nice screenshots. (At the first moment. When they use the program for some time, they start caring also about things like working properly, not crashing, etc. But to get them there, you need a nice screenshot first.)
“Why? Do you get extra points for doing things the hard way? As opposed to: choosing the right tool for the job.”
I don’t know what potential employers are looking for (and now I realize that I haven’t even tried to find out), but I would expect them to be more impressed with a thing if I were to do it in a more ‘difficult’ language than if I did the same thing in a language that needed only two lines of code for the job. My focus is on signaling my skill, rather than completing the program itself.
Then again, I’m thinking it would be even more impressive to learn Python’s deepest secrets and exploit them to the max.
Data point, possibly completely irrelevant: When I am looking for a Java programmer job in Slovakia, pretty much the only thing employers care about is how many years did I program in Java and which frameworks did I use. -- Which in my opinion is completely stupid, because I consider the ability to write and understand algorithms much more important; and a new framework is just something you can learn in a month or two, if your algorithmic skills are solid. I guess the problem is with the fact that the employers who make the decision are not coders themselves, so speaking about algorithms is simply too abstract for them, but asking questions like “how many years?” and “are you familiar with XYZ, yes or no?” gives them a false sense of understanding.
More generally, you are a perfect employee if you did something extremely similar to what your new employers wants to do, for the last ten years. So another good question is: what kind of projects are the employers in your target group typically doing? (For Java programmer in Slovakia it is: a database application with a web interface, most likely in finance.) Then do a simple demo, using the “right” framework; which is the one most frequently mentioned in online job searches.
Note: In my case, programming games would be almost completely irrelevant to a real job experience. Although there would be some transferrable skills, such as commenting the code, maintaining a large program, understanding threads, etc. But I would completely miss communicating with the database and creating HTML pages, and knowing hundred specific details (and dozen bugs) of the relevant frameworks, which make most of my daily work.
But the problem is that there will be dozen frameworks doing pretty much the same thing, and new ones are still invented, and the old ones are redesigned. You just won’t have time to keep up with all of them. So the framework-based knowledge is prone to obsolescence, which drives some programmers into despair. You need to be more meta, and instead of “knowledge of framework X” focus on “ability to understand new frameworks”. (But you also need a deeper experience with one or two of them, just to learn what the painful parts are.)
Thank you, especially for this. I’ve been contemplating “looking good to potential future employers” type things, and it hadn’t occurred to me until just now to frame it as “consider exactly what it is said employer wants, minimise the distance between that and me (as presented by resume / portfolio / etc)”