Yeah that's right, I said it. I hate programming. It's such a pain in the @ss. I don't think I've ever enjoyed programming which is ironic considering I'm a computer science major. Programming is the skill I need but not the skill I want. I've forced myself to learn it just like I've forced myself to practice pixel art because the real goal of it all is to make games.
Games are what I love, not programming or drawing. I love to design games and to sketch up huge documents and plans for a game. I get all deep into the mechanics and progression of a game's design, that is pure joy for me. Best of all, I love seeing it all come to life when a project is finally starting to feel like a game.But damn if the process isn't tedious as hell. I can spend whole days trying to fix simple bugs only to end up punching myself when it was so obvious. Or worse, when I decide my programming sucks and I need to start all over again to get something right. It's usually better to build a newer better machine than to patch up a faulty one isn't it? It's this process that makes me feel like I'm going no where with a project. I spend more time redoing the things I already did than I do adding new content to the game.This explains why it takes me forever to make any progress on my projects and why I'm terrible at game jams. I'm plain and simple, not a good programmer. I'm just somebody that forces myself into creating something fully functional before I call it complete and this is a really long process for me due to my lack of skill. I refuse to release something I would call complete and not have it be to the best it can be. (this obviously excludes WIPs)well wasn't that a nice rant? I just get pretty frustrated with programming and even more frustrated with Game Maker Studio. That damn program seems to always work in the opposite way than I expect it to. Currently working on an old project of mine, Land of Death, which should be a simple platformer, really simple actually. Just jump and slash at stuff. 1 color sprites and 2 color tiles is all I'm working with. Trying to keep the enemies simple but programming challenging AI and basic physics that work with it seems to be something I apparently suck at. Over 6 years of programming and developing games and I still can't get smooth collisions for a platformer. WTF am I doing!?
Awesome mega man music in that video lol. He's funny but his ultimate tip was, simplify some things into functions that are easier to read. Helpful but obvious and probably not going to make bugs go away. Though I probably could use some programming books written by experts. Even after all the years of practice I still have never really read much text when it comes to programming, I just kinda struggle along on my own, figuring things out. Not the most efficient way that's for sure.
For the most part, I never have any problems reading my code or keeping it clean. I understand my code at a glance but it takes me a while to understand how GM (or the machine) interprets the code and runs it. Some of the biggest conflicts I notice are due to timing, trying to perform too many things at once and the order of those functions conflict with one another.
Here's some code I wrote a few hours ago. It's for a zombie enemy and I just added in the higher difficulty differences. It works but the zombie seems to float up walls instead of colliding with them. The odd thing is the code is nearly identical to the Rat enemy and the Rat collides normally.I feel pretty much the same way.
The only time I ever really enjoyed programming was when I was working on a RuneScape private server. Everything was already there for me to use, and I just had to make some things work how I intended and then rewrite some code to make it more efficient. It was fun and probably the longest time I ever spent on a project.1. When you say it's too long, how exactly can it be shortened? You show examples of putting things in functions but that doesn't shorten the code, it just moves it somewhere else. Honestly I think it's absurd to create a function for extremely simple things that already have built in functions or require 1-3 lines of code at the most. Setting 3 variables does not need it's own function/script. That would just result in a huge amount of scripts that I can't easily sort within GM.
I do get the tip though and shortening/simplifying is something I'm working on but it doesn't come easily when you add more stuff into the game and it's functionality has to be added into already existing code. 2. I do indent. How do you not see that? Did the format get broken? Looks fine on my end. I follow my own rule for indenting and it works fine for me. I always indent the same way in every script or piece of code so this isn't really an issue for me. It's a common argument I hear amongst programmers, the "proper" way to indent. I don't care for that, as long as I stay consistent and understand it myself I don't see why I would have to change that.3. How are comments a bad thing? I simply use it to break up the font color and segregate different mechanics within the same piece of code. Easier to find a section when scrolling through a page of text. I don't mind if it's obvious, the color and change in font style helps make it stick out to me.4. LOL okay that I agree with. I fall into this issue but I really do feel it's GM's fault for not being able to set up classes. I may have different types of ground blocks that characters need to react to differently but than there are times when they are treated the same, thus I end up with a long condition like that. There really is no way around that, I have blocks you can pass through and blocks that you cannot and I need to check for both of them. When I try to simplify things though, it usually ends up looking nice but not functioning at all. I end up adding a lot of conditions to each process, maybe more than necessary but it's the only way I can make sure to include all the different scenarios an object can come across in the vast landscape of a game world.Also handle_jump() ? really? You don't think that's a bit annoying to even see? How simple is handling a jump? Set the gravity, direction and speed? That's 3 vars that can be set right on the spot. If I wanted to change the jump, I'd have to leave the script I'm in, go find the jump script, open it, edit it, close it, go back to the previous script and than continue. Seems more convoluted to me.5. Yeah I want to move away from GM, it can really infuriate me. The problem is I don't want to commit the time to learning a whole new language or way of programming. I've already invested so much time into GM that I want to at least release something, anything at this point. I've even put money into GM. Some day I will stop using GM, hopefully not too far off from now but in this moment, all my projects are within GM and I at least want to finish what I started.Hmm well I try my best to not copy and paste, since I hate doing that but it DOES happen more often than I would like. I suppose I should give using more scripts a try. Usually I'd say that a project as small as this doesn't really require it but it wouldn't hurt to try. It's still early in development (sorta) so now would be the best time.
My larger 3D project I do use scripts for just about everything in that game but that's mostly because I wasn't really using the GM interface much for that project. With Land of Death though, I was trying to stay completely in GM and it's my first and only main project in Studio. I usually use 8.1.I'm really not used to the concept of using scripts for things like moving, colliding or jumping but I suppose it could be helpful when it comes to programming all the different enemies.Many of the situations you describe Death have happened to many of us. Personally, I think it's a matter of finding your own style. Which by reading your blog I gather your still doing somewhat. As SpectreNectar and others have stated there are good practices one can adhere too.
As far as GM:STUDIO programming: I tend to agree with old school ideology(presented by Mark Overmars) with GM. Since GM started multi-plateforming code it's interface has changed dramatically(as you already now). And it's GUI and other internal issues aren't always your fault. So, I wouldn't be so hard on yourself in that area. When executing idea's into code I have learned to execute code into a 'one-step fashion' when adding or changing my statements(essentially tracing). This is especially true during long coding sessions or when I get tired. I've also have learned not to bite of more than I can chew and to leave foot notes for the next programming cycle. When I start again I read the foot note(s). Think about it. Then start from where I left off. Since, many things change in us as we get older these idea's help me out considerably. Especially, in the memory department. —->Which is 10 out 10 times the cause of many bugs in programming.@eagly: from what I've heard it's actually pretty damn rare to get hired as a Game Designer. It's not impossible but it tends to only happen for those with a lot experience and a good reputation.
@mrpete: yeah the memory thing is a big deal, that's why I comment a lot and when i'm done working for the day, I write some stuff down in a text file describing the last changes that were made, what's currently being worked on and what needs to be done next. It's been working well for me in my FPS project so I might start doing that in every project.My number one problem is having to learn libraries, especially when they have poor documentation.
Re-inventing the wheel makes game development hard, but it is also hard to not, without easy libraries. Thus, Unity is a very popular tool in this regard.Once you find the right libraries though, it does make things easier. Otherwise I just ask people on 64digits to do it for me :)Yeah I don't like relearning to do the same things in a different language or engine. That's probably why I haven't really branched out from GM much lately. That will change when I get back in school though. It's only been a year since I last went >_>