A
Alex IE
Guest
Actually, chameleon answered my question. Your link and explanation explained "how" to do a trace, but first I wanted to understand "what" a trace even is and why you should do it. I find many tutorials do this same thing and jump a step; maybe it's just me, but I usually want to understand what a thing is and why its useful before trying to use it.I think I have a pretty good handle on why things aren't working out for you: You need to work on your reading comprehension.
One thing that frequently riles me up in the Q&A is people blatantly missing instructions laid out in the open. If you don't know what I mean by tracing code, it means you haven't read either of these from my previous post that clearly demonstrate what tracing code is:
chameleon and I don't look eye-to-eye on a lot of things, but even he got my point.
If you could miss both the external link teaching you how to trace and the example of a trace in my previous post, how many of the main points would you miss in something the length of an average tutorial or book? How many blatant problems in your code can hide in plain sight?
Hmm, ok. Are you comfortable with Drag and Drop coding, or do you just use whatever is in the tutorials? Honestly, you may just need to use Drag and Drop for a bit until you're comfortable using GM to make simple games.
Let's put it this way: With learning there are two aspects we could look at: Learning pure programming, and learning to use GM (or learning Game Design).
When you're making a game in GM, you're not just writing a simple code that stands alone: you're actually just adding a piece to an existing game engine: The GM 'game engine' is underneath your game: You've got pre-built Rooms, Objects, Sprites, and other such objects, with built-in functionality. When you create a new Object, you're creating a new piece of an existing engine: And that Object doesn't exist by itself. It has to live in a Room, it has to have a Sprite set to it. That Room itself has a framerate set (30 or 60 frames per second), so you have to make sure that the Object moves well within that, and Sprites can have different attributes, too.. Angles, and Animation Speed.
So: For purely learning 'programming'.. loops, arrays, variables: This is actually kind of a messy environment to try learn in, which makes it not ideal for learning pure programming. Because you might just want to test how an Array looks, but you've got to have Objects, and Rooms, and Events set up just to get a bit of code to look at an Array.
But for learning Game Design: It's great! Just by doing the basics, you are already learning about the process of designing a simple game. Create a Game Room, Creating a few objects in the room, add some Events (clicking/keyboard) so the player can interact with them, etc. These are all common elements in just about every Game Engine.
Creating games with Drag n Drop is fairly easy. Because it's intuitive: Sure, you can make mistakes, but you don't have to sit reading a manual, and make sure you spell everything exactly right: You can just use your mouse, check, drop, run the game to see, try again, etc. You don't really need to know what a block does before trying it. So 1 hour development is you actually playing around in GM learning, rather than 1 hour staring at a Youtube video. You'll develop a better understanding of the Events for Objects, and about setting up. When you're fairly comfortable in the GM environment, and you think you've got a fair idea of how all the pieces tie together, you might find transitioning to a pure code-based development easier.
Note: Don't be put off Dragn'Drop and think you can't make some nice designs with it because it's simple.
I started with drag and drop back when I was using the trial version of GM, but now that I think about it it may be useful to play around with it some more.