Any advice on a list of simple games to make for practice?

Hi all

So I recently downloaded Construct 2, GameMaker and Unity, and decided to start this whole "learning to make games" thing. Knowing nothing, I started with the Construct 2 tutorial shooter game. Then on another MGSA member's prompting, I tried making Pong (success! after a mere 5 hours...). I'd like to set out a bit of a "games-to-make" syllabus to work through, like a kind of curated tutorial set - one that will give me the widest exposure to the most relevant programming terms and concepts. I'd also like to get an idea when it would be appropriate to move from one design tool to another (i.e. I've only used Construct 2 for a few hours now, so I know I'm not ready yet to start messing around in Unity).

So far, I've sketched out:
- Basic tutorial in Construct 2 (to get an idea for how the tool works) (done)
- Pong in Construct 2 (to test new features of the tool; on/off events; multiplayer controls; see if the previous info stuck) (done)
- Single level of Donkey Kong in Construct 2 (to test jumping; gravity; rolling sprites; animated sprites)
- Tetris in Construct 2 (to test random generation; moving all sprites down upon line-clearing; other stuff?)
- Pong in GameMaker (to test how to get old knowledge into a new tool)
- Donkey Kong in GameMaker (as above)

Can anyone offer some advice on whether this list sounds decent, and what I should add/change/reorder? I don't have any intention of entering the 3D game world any time soon - my "dream" games are generally 2D platformers, RPGs or adventure games. As far as I understand it, Construct 2 and GameMaker would be sufficient for most of those types, and Unity is for more advanced programming?

I also understand that "Foundation Game Design with html5 and JavaScript" is a recommended reading. Would this apply solely to Unity, or to all programming knowledge (even in Construct 2 or GameMaker)?

(for e.g., a problem I was having with Pong could only be solved by the term "player.count" - a term that I didn't know existed because my programming vocabulary is non-existent; that's what I want to grow, and I want to find the best resources and experiments to help it grow).

Thanks in advance!
Thanked by 1pieter


  • Hello! :)

    I think that's a strong way to work: work through a few tutorials in the game engine to be familiar with the interface and how it expects you to work; then re-create a few existing games, getting you a feel for what sorts of numbers create what sorts of interactions and develop an intuition for "game feel", and how several systems combine together for even a simple game.

    In terms of not knowing what sorts of variables and functions are available to you, this is something that is helped a huge amount by having a good dev environment and solid, searchable documentation, or a strong community that has a giant database that's likely to have similar questions answered by people in the past. Something like "player.count" is likely to have a different implementation in different game engines, and sometimes you'd be creating that variable yourself. If Construct has a "player" class (I can't tell by a quick look through their documentation), it's probably worth scanning through a list of what's in it that you can manipulate.

    I think that the main reason some folks think of Unity as being more advanced is that (unless you're using 3rd-party plugins that change this, like PlayMaker), you pretty much have to learn to script if you want to use it. In contrast, GameMaker and Construct allow you to set up events and interactions using a visual interface, delaying the point at which you need to learn to script, and letting you focus a bit more on the kind of interactions you want to create (until you want to do something that their interface doesn't support, at which point you're back to scripting it anyway).

    I personally wouldn't recommend making a game in HTML and JavaScript, unless you have an interest or background in web technologies. It gives you very little to work off of, so that you're effectively writing large systems all from scratch -- which can be powerful, or unnecessary, depending on your goals and the sorts of skills you want to cultivate for making games. (And even then, I feel that using HTML/js wouldn't be strong in the long term either, as it's a platform that was meant for interactive web pages, not video games, so that some things that are trivial to do in a dedicated game engine, like playing several channels of audio simultaneously, or accessing files on a computer, are tricky to do on a web page where you're stuck in a browser's sandbox.) I can't speak for the book itself. It seems quite practical, which is good, but the language it uses really seems to exaggerate what it can teach you ("everything you need to know to design games!").

    I'm not sure what Construct 2 does for you (so I could be wrong, maybe it already has some sort of character controller built in), but my gut feel is that Tetris may be easier to create than Donkey Kong, in case you want to swap those around.

    I think it's also worth spending some time on the games you're doing as copies, and seeing what sorts of small variations you can put in (both as practise for implementing something, but also in terms of experimenting with the design space). For example, with Pong, maybe your original implementation just has things bouncing; but a variation on it might allow you to make the ball "spin" depending on how you hit the ball with your paddle. Maybe your paddle gets smaller and smaller the more successful hits you make. etc. There are many, many interesting Pong variations that I've seen!

    Good luck!
    Thanked by 3Jay pieter FanieG
  • hey kevinh Im assuming you are a programmer, Im a programmer too but still an amateur so here is my advice, instead of making a full game I suggest you practice on making specific things for example focus on collision detection and after you have a solid idea of it move on to physics e.g gravity,acceleration e.t.c and then make a game on those things you have mastered it will be so much fun making a game on something you already know..
  • Hey @kevinh Welcome and it's great that your are looking to learn.
    I don't know exactly how good these examples are or if it is what you are looking for, but I had this bookmarked and thought I will post it. Maybe you see something you would like to try.
    So you can take a look at those and maybe something interests you. I only quickly scanned through it all, but if there's something specific just ask and I'll take a closer look.
  • The book you have there is great on teaching you game programming principles. After that pick up a useful engine and start converting those principle into a game. You can use the games in the book as a guide to making your own game. What's more important is the principles, once you picked up the basic you can pick others while building the game. But my advise is practice, practice, practice, prototype, read books, read tutorials, learn from csdn, practice, practice, practice.
  • Hey @kevinh.

    After Pong, an Arkanoid or Space Invaders clone is a great thing to practice on.

    One thing I would suggest here is to take one of these small game ideas and actually finish it. Not just get a working prototype, build it and polish it to the best of your ability before moving on.

    Add different difficulty levels and enemy types. Add powerups and juice.

    Fix all the bugs, add menus and sound effects and high score boards. Don't be afraid to rip assets from commercial games to test with (although there are lots of free assets out there too), as this isn't for commercial release, it's for you to learn the ropes.

    Too many indies go from prototype to prototype, never practicing the hardest part of game development - finishing something at a high level of quality. It's like wanting to be a novelist, but only ever practicing writing 2 page draft outlines.

    Prototyping is an important skill and a valuable tool, but if you always flit from prototype to prototype, there's a range of important skills you'll never practice. And those skills, you'll find, apply across all game types you may want to build.
    Thanked by 1mattbenic
  • I'd have to disagree with @garethf there because prototyping is an actual skill of training just like an athlete will go to the field everyday and do training exercises and also going to the gym to get fit on daily bases. So aiming to finish a game with 0 knowledge of game development will get you nowhere, its actually like taking farmers to war and bringing seals to the farm fields. So don't follow the "first game" trendy thing, rather practice first for months or fail hard with an empty folder named "_myfirstgame"... Learn from the experts, they have written 100's of prototypes and only few commercial titles, mostly one title e.g. Jonathan Blow has two titles but +20 years experience. Also watch " Indie movie the movie" to see how even industry veterans struggle to finish their game and this people started programming when they were in diaper's. So I'll will only take you seriously if you say: this is my 100th beautiful looking prototype that rushing to release a super ugly glitchi buggy stupid looking "first game" that will only flood the app stores. So my advise is train first until the principles start to feel automated then prototype, rince repeat and think.
  • edited
    SkinnyBoy said:
    Learn from the experts << That's @garethf. I'd say someone who actually got through the process of shipping something of that quality (after knowing when to drop something he realized he wouldn't be able to finish with his resources), absolutely qualifies as an expert. @kevinh take every bit of advice this man has to give.
  • edited
    Heh, thanks @mattbenic.

    Look, I'm really not against prototyping at all. Prototype as much as you want, it's a great thing to practice.

    But at some point, when you feel really to kick it up a level, pick a really small project and finish it. I emphasize "really small" because it'll take more time to finish than you think. What takes a day to prototype will take months to really finish. Don't pick an idea like Braid, choose something like Space Invaders or Arkanoid.

    It's important to learn the skills involved in finishing a project. Indies as a whole are pretty good at prototyping. But they're not so great at finishing, IMO.

    I would love to see a "pick one of your prototypes and finish it, dammit" game jam. XD
    Thanked by 2mattbenic AngryMoose
  • I would suggest you make something that can reward you beyond just implementation knowledge, the methodological approach is logical, but you can burn out. If you are comfortable with the tech, work on an idea of your own, share it here and release it, that whole process is worth a lot.
  • Hey @kevinh, I can relate to your post and what has helped me is actually getting started doing something - as @Jay said practice on specific things, and by doing that, you'll be a bit more comfortable with the interface, I'd then move to either dev an existing (small) game like pong etc or work on a small idea of yours and finish it.

    In the beginning, I made the mistake of reading/researching too much and not just getting into it, not walking the talk - I also have to thank a few Members on the Make Games forum for their great advise - it all counts.

    There's always time, just make the time and watch less YouTube videos ;)
  • Download Mame 32 if you dont have. Play every single game in there and see if you can clone it. That is how i learned game development in unity.
Sign In or Register to comment.