SOLVED I'm new in GameMaker studio, what should I do to improve myself?


I'm new in GameMaker studio, what should I do to improve myself? I bought training from Udemy but i learned the basics (I really really want to make a game like "Katana Zero") : - )


I'm new in GameMaker studio, what should I do to improve myself? I bought training from Udemy but i learned the basics (I really really want to make a game like "Katana Zero") : - )
I always (shamelessly) recommend my own series for the basics of coding: Coding Fundamentals in GML. And I recommend the space rocks tutorial by YoYo for putting those things into practice. With the new caveat that this tutorial was done before 2.3 and there's been a couple things that don't work right after the transition - but this is true of pretty much every tutorial right now since the transition was recent and there aren't many issues and you can find answers to most of them on this forum. I also have a link in my signature line for exactly this question.

For Katana Zero (made in GM as you probably know) watching a couple different platformer tutorials to get an idea of the different ways to code that could be a good idea and there is also this free asset on the marketplace as well as some not free assets as well. I would say though don't start with this unless you have some programming experience already. You'll need to know the basics of how coding works and how GameMaker works to get any real value out of them (in my opinion).
Last edited:


I'm new in GameMaker studio, what should I do to improve myself? I bought training from Udemy but i learned the basics (I really really want to make a game like "Katana Zero") : - )
Do any tutorial for game maker. Even if it is not relevant to the game you intend to make. You need to learn to think like a programmer when coding and why you code things a certain way. If the tutorial is good enough it will have a great explanation of why. Also, not matter the type of tutorial you can use and adapt the code you learnt into what you want.

Last thing and possibly the main thing: code and fail. Learn. Fail again. Repeat.


Katana zero looks beautiful.

kind of a snes platformer thatā€™s story driven.

you could break that game into little pieces and learn as you go. Like samspade has said.

have fun!!


Take ideas, unique little games. Break them down to their simplest possible form. "Platformer but you only move by leaping", "a shooter where the aim is to get hit as much as possible" that kind of thing. Make the scope of the project as small and simple as possible, and then make it. Do a game in a day or a week. But avoid stuff that snowballs into something humongous. The more projects you've got under your belt, the more confident you'll be and keeping the projects completeable is gonna give you the mental benefit of having finished a game. Then do tutorials and read the manual in the mean time, explore ways of using features you've never used before (i.e. particles, the physics system, surfaces). Again just doing simple proof-of-concept games even if they're only one room long. As your familiarity grows, you'll be able to branch out further and further and get more ambitious. Learning to draw/sprite or make simple bits of music (plenty of free software and tutorials for those) is also a great skill to have, then you're not dependant on finding art and music each time you make a game. But it's not so much about making something 'good' to begin with, it's just about making something at all. You practice and experiment, a little at a time, and that's how you gain any skills in life.


šŸ§ *penguin noises*
GMC Elder
For learning purposes, it's better to make a lot of small games where you experiment with one thing than to make one huge project - GM is built so that it's easy to get a prototype up and running quickly, but it's also really easy to make a large project so messy that it's impossible to keep working in it (happened to me more than once šŸ¦ˆ ). So it's good to get some mastery over how things work before you start working on anything too large. Ideally, things should be so self-contained you can just copypaste your old projects into your new projects later, so you can experiment with the more tricky systems (e.g. reversing time) in small jam games and just throw them away if they don't work and import them into your magnum opus once they're good enough.

Tony Brice

There's some really good advice here. All the pitfalls described have happened to me at some point and it took me a fair while to get up and running because I had some experience coding and just did it my way, without really reading a lot of the tutorials and advice first. I can't offer much more than what's been said here but as I'm about to release my 8th GMS2 completed game in the last 2 years, I think I'm a good example of showing that listening and learning does help a lot.

Start simple. Prototype simple game ideas and see what you think works. You learn about stuff like sprites movement, input handling, collision detection and actually creating something gamey.

Drop something that you're doing if you aren't that interested in actually playing it afterwards, or you're losing interest in the game itself. Motivation is a huge issue in game development, and one I struggle with a fair bit after working on a game for a while.

Set yourself a deadline, or have one set for you. Game jams or competitions are brilliant. Six of my games on were competition entries. Even if you don't want public scrutiny on your efforts just yet then set yourself a target to have the game done and aim for it. Don't dismiss it near the end because you aren't motivated to code today and nobody is monitoring you. This is how you end up with multiple unfinished efforts because you get bored of something and want to move onto something new.

Have a reasonable understanding of what you want to make before just hitting the keyboard. Set boundaries so you don't go crazy with throwing in new ideas instead of getting the shell of the game done first.

In game development plagiarism is often more flattering than anything else. Most of the early computer games took influence from the arcades. You should be starting simple so once you have a basic understanding on the essential coding concepts for stuff I mentioned early then look at some of these (Space invaders, Pacman and Asteroids are great examples) and break down the game elements into how you think they would work with Gamemaker. You can also find loads of tutorials on you tube for people who have done the same thing and you can compare how you would do this to how they do. Then by all means follow them and type in the code they are writing by pausing the video every so often to keep up. Don't just download their project files as you'll learn a lot less from doing that. While they are doing bits they are running the game inbetween so you can see what that code you just typed in does and learn/modify it.

Ask questions. People here really don't mind answering them, but you should do it the right way. Posting a question about your code without showing it is a big no-no. Also asking how to do something without showing how you've attempted it is another issue. People won't write your game for you. I've seen responses here when people have asked in a polite manner and explained their issue thoroughly with their code, and it's obvious the person trying to help has put a fair bit of time into trying to assist because of that.

If you're a lone-wolf with nobody to help you with stuff like graphics then coder art is your friends. While you're creating space invaders just use circles for aliens and a block for the player ship. Fancy graphics can be done later on when you have a game to add them to. Otherwise you could spend hours creating images for something that's never going to be shown off as it's a prototype or a learning exersize.

F1 for help is your friend. While coding click on a function name and press f1 to remind yourself how to use it. Often, if you're like me, then you'll often forget the difference between place_meeting and position_meeting, for example.

Show your work to friends if you can. If they're good friends then they won't care if it's block invaders rather than the next AAA epic game and will give you some feedback. If you have buddies who also code then that's even better. I've got a good friend who makes games as well. We're always bouncing ideas and testing for each other. You might find you can make a friend from people who see your games, once you're getting them out there. I've got a guy who's done music for the last couple of games I've made as a result of him contacting me about one of my early games he liked.


I'd say go wild and make whatever game you want to make. Your first game is going to be a disaster, if it's not copy pasting a tutorial or something, but you'll learn a lot! :)


I'd say go wild and make whatever game you want to make. Your first game is going to be a disaster, if it's not copy pasting a tutorial or something, but you'll learn a lot! :)
This is very important to understand. During the process of learning to make games, many of them will not be very good but they are proof of concepts that feel game-y. After doing a couple of projects, you should feel more comfortable tackling larger challenges. Like @Tony Brice mentioned, game jams are an effective motivator on finishing a project especially if you are working with someone else.

Also as the more experienced users have already mentioned, be sure to comb over the manual several times and really try and understand what is happening with your code.

Joe Ellis

To elaborate on this subject, I recommend not using any tutorials at all and gradually learn and teach your self how to do everything.
I've actually done this and it turned out great for me.

But it's important to have goals, that go towards what you want the end product to be like.

I do like sam spade's tutorials though, and matharoo's cus they're teaching very fundamental parts of the language, so they don't influence the game you're working on, I really don't like a lot of the tutorials that show you how to make a certain type of game, cus they just influence beginners into this crap that some crap guy is doing, but tutorials on understanding the language and basic mechanics of the engine are great, just like reading the manual but more in depth and better cus there's a person telling it to you so it's easier to understand than reading it.
Last edited:


Getting Started
Specifically for GML in 2020. I'd go through the whole program and make sure I can code their little game (
They take you by the hand from A to Z giving you all the key concepts and their names.

For Beginners it's a great source.
For more Advances it show you the limit (or the mind spirit) behind the engine.

Allow room for improvment
Then go nuts... Start your Game!

For each "Game" I create, I like to have 5-10 "Proof of Concepts" projects.
Those are usually 1 roomer GML projects. Or Few class c++ dlls. Or Inspiration deck in Illustrator. etc.
Over the years you will probably pill a bunch of those PoC in your tool box and it's always a good idea to keep them at hand (or on github)

That's your training area. Setting small goal in small PoC allow you to avoid Scattering. You can focus on a single concept and nail it down.
Remember. Devil's in the details.
That's true for success. That's also true for failure. If you stick too much about the details, only your PoC will fails, not the whole game.

When ready cherry pick from your PoC and back into your Main Game.
Don't be shy to cherry pick from other Community member's PoC pool. (within legal rights of-course) As there's fat chances you won't be able to nail every single aspected of a game on your own for the first couple of years of your journey.