To be honest, 2D game development is not a very good way to go through the future. The biggest reason for this is mostly because it’s way easier to create 3D game animations and assets. You can play an animation on a 3D model and view it from multiple camera angles by doing some mathematical transforms without needing to redraw every frame of animation, whereas traditional 2D lacks this ability. It’s been one of the biggest time savings in the move to 3D. 

If you want to learn something that will actually be directly transferrable to a professional setting and stay with 2D game development, I would suggest trying to pick up Flash (and, by extension, Actionscript). Adobe began supporting Object-Oriented programming with Actionscript 3.0, which means that the sort of things you can do with it are much bigger and broader, and you can build games and applications that can easily be run and playtested with just a browser. Learning how object-oriented programming works would also help push you toward a career in software engineering, if that’s something you’re interested in. While it is sometimes looked down upon by the hardcore gamer audience, Flash is a great way to make your own games and make them interesting.

A second option I would suggest is trying to remake your game (I believe I recall you saying before that it was a Tower Defense game?) in the Starcraft 2 editor. You'd make the transition to 3D (which I assume you'd want to do eventually), and you'd have a new tool to learn and play with. I know for certain that the Starcraft 2 editor is pretty robust, and a 2D game can be built pretty easily on a 3D game - you just fix the camera at a specific height and angle, and you're good. The Starcraft 2 editor was the tool the designers used to create the campaign for the game, so it should provide a lot of options you might not have available in GameMaker.

There’s two major answers to this question, depending on the process. The first answer has to do with the design process in specific, while the content is still being developed. The second answer is actually the focus on play testing and iteration. I’ll try to go over both, since I’m not sure which you would find more useful and I think my readers might find them both interesting regardless.

So the first answer generally falls to “What sort of goals do I want and how do I reach those goals while still providing something fun and engaging?” You need to examine what the primary goal is, and build the experience around it. Here are a few things to take into account when trying to create a balanced design:

Don’t get too caught up in making things perfectly even. Even if this tower might be 5, 10, 15% more efficient/damaging/better than that tower, it’s actually ok if there are these sorts of discrepancies for a number of reasons. Being able to recognize which towers are better than others is a skill and it’s important to cultivate this for players. You want to make choosing which type of tower to use against which type of enemy interesting, and that means you need to provide options that are sometimes worse than others. By providing bad choices along with good ones, you provide texture to the experience and allow players to improve. By this token, you should also make some towers better than others in ways that aren’t just based on arithmetic. Don’t just improve damage, but show the player the additive value of things like firing rate, area of effect, speed reduction, poisoning, armor reduction, stunning, etc. 

Don’t make things clearly uneven either. It’s ok if you have some elements that are clearly inferior to others, but you should still try to make some of the weaker choices compelling too. For example, let’s say that you’ve got two towers - one that is strong out of the gate but the maximum upgrade caps out early, and another that is weak to start with, but its upgrades mid to late game can clearly outstrip the first tower. Now you provide the player a more interesting choice - does she tough it out early with weaker towers hoping to make the later game stronger, or does she put out the stronger early game towers to stabilize early, knowing that the mid to late game may be more difficult? Maybe you’ve got a third option - a really cheap, really weak tower. But the player can use a lot of the cheap towers to build a maze forcing the ground-bound monsters to run the path created by the player by laying the cheap towers out along the ground. But what happens when the flying monsters appear? And so on and so forth. You should give some of the initially weaker options a reason to be there, and you should make the decision of which tower to choose be the one the players have to primarily think about.

Beware of First Order Optimal strategies. You want to provide the player an early option that is strong, but becomes relatively weaker as the game matures. This way, you give the player the high of feeling powerful, but also train her to improve. It is imperative that you start sprinkling situations where the initially powerful option is shown to be weak in order to dissuade over-reliance on that option. It’s as important to gradually wean the player off of these as it is to provide them in the first place, otherwise the player can either feel that dreaded difficulty spike which breaks any sense of flow, or he’ll simply stick with that strategy for the rest of the game and complain that it wasn’t very fun.

Keep in mind that player concentration is a resource too. Don’t overwhelm them with too many choices, or it will spiral out of control and they’ll get burned out. Most humans have a hard time having to remember more than seven to ten things at once in short term memory. It’s why telephone numbers are seven digits with 3 digit area codes, and it’s why people use mnemonic devices like ROY G BIV to help themselves remember sequences - it reduces the number of things you have to remember. This means that you should be wary of presenting too many things to the player at once for fear of overwhelming him. Try to introduce at most one or two new elements at most with each new level or puzzle (especially during the introductory levels), and help the players internalize how the mechanics in your game work without getting mentally overloaded. I cannot emphasize this enough - as developers, we tend to take our in-depth knowledge of the systems for granted, and should constantly remind ourselves that new players don’t and won’t have any knowledge that we don’t take time to teach.

Remember the knobs that you have at your disposal as well. Not just in terms of formulas and effects, but also in the types of encounters and enemies the player can consider. Try providing a breadth of challenges to the player to encourage diversification of towers, but make sure that your challenges are intended to be beaten. Avoid making a critical path objective too hard - the game is meant to be beaten after all. It is fine to make optional objectives difficult, but you want to make sure that the player doesn’t get frustrated playing your game because of an insurmountable jump in difficulty.

Now… with all that in mind, you’ll still most likely need some serious iteration on any sort of balancing you do. As General Helmuth von Moltke was fond of saying, “No battle plan survives contact with the enemy”. Your design might be great and awesome and perfect the first time out, but if it’s anything like reality it’s probably going to have issues, holes, problems galore. So how do you catch these issues and deal with them in a timely and efficient fashion? Here are some production practices I’ve seen and used that help facilitate the iterative process.

Gather data. More data is always better than less, and it is imperative that you take in as much as you possibly can. Humans are notoriously bad at communicating exactly what it is that bothers them, and things they say do not always reflect the real reason why they disliked something. Often times, if you bring in playtesters to try your game out, they will lack the necessary terms and context to sufficiently convey what it is they mean. This makes things like surveys and interviews much less useful, because you’re losing out on a lot of the context.

If you bring in playtesters, TAKE VIDEO FOOTAGE OF THEM PLAYING. Try to get footage of their facial expressions while playing in addition to what’s going on in the game - facial expressions are a lot harder to fake, and you want to see what makes them smile, what makes them frown, and what makes them look bored, etc. You want to make this fun, so you want to minimize the frustrating elements as much as you can.

Bring in brand new players periodically. A great game will grab the player early and make it interesting. If you can’t hook them within the first few minutes, you’re in trouble. Brand new players are an invaluable resource because they remind you that you have to view things from a fresh perspective - they don’t have all the experience and knowledge you already have or preconceptions that might cloud their view of the game. Pay careful attention to them, because everyone who plays the game will be new to it at some point. You want to provide an easy and clean experience for them, so bring in new testers whenever you make big changes.

Build and playtest your tutorials first. If a player doesn’t know how to play a game and is just thrown into the deep end, I guarantee it will be a frustrating experience. Just getting a printout with a list of commands is never sufficient. The new player lacks the context to what these commands/skills/abilities/etc. do, and they desperately need that context or the game won’t make any sense or be much fun. Having good tutorials also provides an excellent way to bring new team members up to speed, because it teaches them how your game works as well. Tutorials being available also provides a good way to provide context to players for other playtests too - it (hopefully) teaches them to have fun with the game, and then they will have it much easier with the other mechanics of the game later. One of the recent games I worked on had this problem - the tutorial system was almost nonexistent. As a result, it was savaged in reviews, not because it lacked the features the reviews demanded, but because the game just didn’t teach the players how to utilize those features. The players (and reviewers) didn’t know those features existed, so they complained about their lack. Who's fault is it that they didn't learn about it? Ours. Gamers will never have the option of a developer standing by their shoulder to explain how things work, so you should always treat it as if the player will simply start the game and skip anything else.

Have your engineers build data gathering into the game. It doesn’t take a lot of memory or hard drive space to note down things like how much damage the player did, how long they played, what they spent their funds on, what they built, what their build order was, how much time they spent on a specific screen, where they were clicking, etc. Optimally, if you have the game online you can have the game periodically send you data from the players (just make sure you include the option to turn this off in the options menu somewhere… but turn it on by default). But turn it on, because you can use that data to figure out where the danger and sticking points are. The important thing to remember with telemetry data is that the data can tell you how many, but not why. The why is up to you to figure out, but knowing how many is very important. Why are 80% of players getting stuck on level 12? Why are only 5% of players using the frost tower? Why is the number of players with a specific build order spiking? Having this sort of data is important and interesting.

Separate the feedback you get into things you can address with the remaining time and resources you have, and things you can’t. Address the things you can, and then think about the things you can’t after the game ships. Most gamers don’t understand what it means to have to scope and schedule. It’s important that you can recognize the difference. You really need to beware of feature and scope creep, especially as the end of the project nears.