The Runthrough has been in development for a long, long time.
A number of events made me break up with development from time to time, and those break ups transpired in a lack of motivation, and a lack of time due to my education.
The main reason for the lack of motivation was because of two things:
- The Engine: I was using Game Maker to develop The Runthrough. Since development started, some 4 years ago, I’ve been struggling with the engine’s flaws.
There’s a whole bunch of constraints, bugs, glitches, problems and other things wrong with it, but my biggest issue was the attitude of its developers towards professional customers. Don’t get me wrong, the support team is pretty good. You can hit up the developers on Twitter, ask them a question, and they’ll probably reply within a day.
The issue becomes clear when you look at certain questions, like for instance: “How can I play videos (such as logo intro’s) in my game?”. You can’t. This was asked on Game Maker Community some time ago, and I was baffled by the developers’ answer. According to them, the feature could be misused, resulting in games with huge filesizes due to improperly compressed videos. To be honest, I find that an insult towards all professional developers. Game Maker is on sale for up to $800, so they obviously want to target more experienced developers. The excuse of not allowing advanced features because they could be misused is the stupidest thing I’ve ever heard.
The same excuse came up when I asked about the filesystem. Game Maker saves files to a certain directory, and reads files from a certain directory, based on the function that’s reading or writing the file. I wanted to read an .ogg file from a directory that the user could place their levels in. I can’t. Apparently the file path needs to be whitelisted before the filesystem allows you to access it. Not only is this stupid, because you can’t use the open file dialog on anything else but Windows, it’s because of the same excuse as earlier. When I asked about manually whitelisting file paths, the answer was, of course, no, because I could potentially add “windows.exe” to overwrite.
At this point, I was completely done with Game Maker. </rant over>
- The gameplay: Everyone knows The Runthrough originally started as a clone of the popular The Impossible Game. It wasn’t meant to be much more than a recreation of the game for my own educational purposes. But, a lot of people started making videos of it, and so The Runthrough gained its popularity. But now that I’m making the game to be much more than just a clone, with a dedicated level creator, ports to almost any platform out there and licensed songs, I wanted it to be more than just jumping on blocks. Unfortunately, due to way I made the “engine” in Game Maker, adding much more was practically impossible. But now, due to the fact that I’m rewriting the code in a new engine, I can, and I will add new gameplay elements.
About that, as I mentioned in the Facebook-announcement, I am rewriting The Runthrough’s code, and revising some designs. For this I’m using my own, custom asset pipeline, as well as the one provided by the new engine I’m using: Paradox. It’s free, it’s open source, it’s multi-platform, it’s .NET, it gives you access to most of the native graphics API, it has an awesome team of developers that are easy to reach and respond quickly, its community isn’t too crowded (yet), bugs are quickly fixed, and it all just makes sense.
If you’re looking to get into game development, I strongly recommend you check out Paradox, and NOT Game Maker.
Now for the development blog itself, what did I do the past week (plus some more)?
First of all, I created a custom “package” system that easily allows me to include custom content such as fonts, localization, collision data, etc.
I made a font-sheet definition editor, so that I could easily transfer the custom font from “Game Maker-style” to “Paradox-style”:
Aside from the font-editor, I also made a “packer” that exports the files to a native format, a converter that exports files retrieved from a physics-shapes editor to a binary format, and a format for the localization.
For collisions, I’ll be using Box2D with polygonal collision checking.
Another thing that I can take advantage of now is Shaders. The first thing I’m applying shaders to is the fading of objects on the left/right sides of the screen.
This allows larger objects to be faded out properly as well, since previously objects would be faded as a whole, now it’s per-pixel:
Which has the following result:
Please note that that screenshot isn’t at all representative of the final, or even alpha version… in any shape or form.
So there you have it! I’m keeping the new gameplay elements a secret for now, but I can assure you, you won’t be disappointed!
Hope you all enjoyed this first development blog, I might make this weekly… depending on how much stuff I have to show 😛
Thanks for reading!