Var local_y = y + lengthdir_y(100, p_dir) ĭraw_sprite(sprite_index, image_index, local_x, local_y) Var local_x = x + lengthdir_x(100, p_dir) It would be far better expressed as: var p_dir = point_direction(x, y, mouse_x, mouse_y) While not completely unreadable, it is inefficient (the point_direction() function is called twice, for example) and it is messy and awkward to look at. For example: draw_sprite(sprite_index, image_index, x + lengthdir_x(100, point_direction(x, y, mouse_x, mouse_y)), y + lengthdir_y(100, point_direction(x, y, mouse_x, mouse_y)))
#WHAT LANGUAGE DOES GAME MAKER STUDIO 2 USE CODE#
This means that you can add as much whitespace around your code as required and you don't need to worry about keeping your comments short or only using them sparingly.Ĭontinuing on from the above point about programming style, one thing that a lot of beginners do is to cram as much into one line of code as possible. When writing code, you should be aware that when compiling your final game, GameMaker Studio 2 strips out comments, removes unnecessary line breaks and whitespace, substitutes in constant/macro/enum values, and generally compresses your code down as part of the process. There are many, many programming styles, and some would argue that theirs is the best one to use, but the truth is that almost any style is fine as long as you are consistent when using it and it is clear and obvious what everything is and does. The style you program in is the way you place your brackets, how you indent the lines, and how you declare and name variables, etc., and is essential to making your code clear and readable to other people (and to your future self, when you have to come back to this project after a time on something else). When it comes to writing code everyone has a style. With that said, lets move on and look at some general tips for writing good GML code that you can apply at any time. Basically, if it isn't broken, don't fix it and keep what you learn here for your next project.
You have to strike a balance between readable, flexible and modular code with the time and energy required to change things, as well as the overall gain at the end.
If your game runs fine and you are happy with things as they are, then don't rush to change everything just to squeeze a few extra FPS out. This is a guide, and not the be-all-and-end-all-definitive-100%-perfect method to write your game! The things mentioned here are generally more on the organisational and micro-optimisation scale and should be incorporated into your coding habits when you feel comfortable with GML and think that they are appropriate. In this article we are going to cover some "best practices" for when you are using GameMaker Language ( GML for short) to code your game, and at the same time explain a little bit about the inner workings of GameMaker Studio 2.īefore we continue, however, it is worth noting two very important points:
0 kommentar(er)
