Tell your variables to go home.
When you have many events in your script, it is best to send them all home whenever possible. That is, try to keep them all in the same place.
Every time you use an event, you put a piece of code inside a menu somewhere. And every time you wish to access/modify that code, you have to go find it.
It's better to build one house and have as many events living there as the house can hold. Upgrade it to an apartment building by using case switches.
Many of you have already found, that if you have a keydown>left>
xvelocity=-2;
and you do this for each key, then decide that you want the player to go faster than 2, you have to go back through EACH EVENT and change them to 3. Then what happens when you decide 3 is also to slow, and you go to change it to 4?
There are two solutions to this: One is to use a global variable 'speed', and just put that in each key event. You can then change speed and all of them are changed.
But what happens if your actor gets in an elevator, and can now only move up and down? How do you disable the keydown events for only left and right?
What's best is either to use a getkeystate() inside draw actor, or a simple variable 'dir' to hold the last arrowkey pressed in keydown. Then, you have access to all the variables from all the keydown events in one spot, in your draw actor.
You can then easily disable the left and right dirs while still allowing up and down in the elevator.
Now i don't mean to imply that the builtin ge events are not useful; quite the contrary. See, GE was built on this premise:
You can make games without any programming knowledge, or if you do have programming knowledge, you can use that too. The choice is yours. Now if you want a house, you can either buy one or build one.
If you build one, you can make it whatever you like it to be; but if you buy one, you get it how it already is. What this means in making games is, if you do not wish to learn to program, you can still make simple games, or you can buy a game from someone else. But if you want to design your own custom game of any complexity, you are going to have to learn to build it yourself.
I use mousebuttondown> events all the time, for all sorts of things. But at the same time, i control them heavily through scripting as well. If you simply click on the title screen to start the game, then click on buttons in game, you either have to disable the titlescreen>mousebuttondown event, or you have to destroy/move/move away from the title screen after clicking. And you can simply start a timer on titlescreen click and then destroy it without having any scripting knowledge whatsoever.
But if you want menus and difficulty settings and sound/graphic options screens, then you are going to have to learn to program.
People complained that you couldn't easily make a pause menu in ge, because PauseGameOn(); stops all events. But ask yourself, how does GE know which events to stop and which ones not to? Well, you gotta tell it!!! Some might suggest it should have a built-in pause menu option that operates outside of the normal game, and many other things like it, such as a text handler for dialoge, or auto-health meters.
I can't speak for everyone, and different people work best with different toolsets, but i can tell you, even in programs i've tried that had these builtin options, i rarely used them, because i am always doing something slightly different than what the creators intended. You want auto-health meters? what about auto-mana meters? what about a million other meters i might add? how many should the game creation software allow for? Unlimited? Well, with a canvas actor and some script, you can make all the health meters you want in ge.
And since its scripted, if you have many meters, you can automate the capture of the variables and the display of the variables as well. If they were built in, you'd have to go thru each one as a menu item and assign it this or that; while in script, you can simply make a loop that designates the position, variable and color of each meter. You can create a keypad of buttons with 10 lines of code, or with 70 zillion menu clicks/mouse drags. One requires you to learn and plan; the other requires you to do the same repetitive motions over and over. But wait...isn't doing repetitive actions exactly what computers are for? Why do them yourself?
My point is, if you have so many of these items that you need separate handlers for them, then you won't be able to manage them via menu options in the first place. You need to script them. 200 Rollerskates != 1 car. Not by a long shot. (Athough i would like for Ge to have a built in dialogue engine
)Regarding a pause menu option, the way its done traditionally is to control the main draw routine; and only draw (but dont' calculate or run any other functions) when the pause ==1; However, that requires you to have a completely scripted draw routine for all objects and functions in the game. Which basically means scripting from scratch, and not using a game creator at all! If that's what you want to do, there are tons of languages and editors and compilers to handle that. The concept of GE, on the other hand, is to allow you to make games without scripting everything from scratch. I'd rather have a game with no pause menu than a bunch of script i'll never finish because it's too long and complicated.
We all want it to be simple, yet flexible and also powerful. Any software you use is always some combination of those attributes. One might liken choosing a creation software to choosing a character in an rpg. What do you want, fighter, mage, healer, rogue? What options do you need the most?
I'm not saying that GE is perfect by any means, and everything in existence can use improvement (except for certain games made by nintendo). I'm just saying there are two sides to every coin, and every upside has a downside and vice versa. No game creator works perfectly just out of the box. Professional companies don't just compile a game and it works fine on every system; no, they have to constantly test, revise, and upgrade their products. It's a lot of work.
What I am saying is that GE has lived up to it's promise: Make games with no programming knowledge. Just don't expect them to standout from the rest, unless you learn to script them yourself. And if, after learning, GE still doesn't do what you want it to do, then move on to something else. Just be willing to pay the price, to make the trade-offs.
There are no free lunches.
If you are reading this from the 'view new posts' option in the forum, try reading the last post on page 3 of this thread too. They were both posted minutes from each other, and i realize the previous post will now not show up in the new posts option, because it will go directly to this page instead.
