Let’s Make a Game: The Right Tools for the Job March 27, 2014Posted by eric22222 in Game Development, General.
I’m working with the Scrolling Game Development Kit. It has a special place in my heart, as it’s where I first started learning Visual Basic in 2006. The SGDK community put up with a lot of stupid questions from younger me, and I’m grateful for their patience. SGDK has built-in tools for drawing some basic graphics, creating tiles and maps, and linking them all together with some game logic.
Version 1 supported some custom code, but it was a bit tricky to work with (or maybe it was just tricky for someone with no programming experience). Version 2, however, gives the user easy access to the source code that runs the game, allowing for much more complex behavior. Perhaps not much more complex, but it makes anything beyond basic logic MUCH more manageable.
The API for the SGDK is fantastic. The functions are all clearly defined, documented, and organized. That makes working in the raw code much easier, so I can focus on making the game rather than on getting the code to cooperate. Some of the function names are a little unintuitive, but since I have access to the source, I can just make any changes I want.
I’m going to be using TileStudio to churn out some of the graphics. SGDK has some nice tools for pixel art (like editing multiple tiles at once), but I really like TileStudio’s lighten and darken tools. I’ll probably use Paint.NET for bulk editing.
If I make it far enough for adding music and sound, Anvil Studio is a nice midi editor. I’m not a huge fan of the interface, but it’s stable and gets the job done. For sound effects, Audacity will probably do the trick.
Let’s talk a bit about SGDK. It’s an open-source project that started back in 2000. My late freshman/early sophomore year of college, Adam, a friend of mine, introduced me to SGDK, probably after some conversation regarding game development. I downloaded it, followed the tutorial, and wound up with one of the worst-looking, eye-piercing, bright-red-on-cyan messes imaginable. But it ran, and it was fun to do. Most of the fun was in finding things I wanted to do that didn’t have cut-and-dry walkthroughs. I had to get a bit creative to make it work, and I usually bumped into some other ideas along the way.
One example I remember pretty clearly: I had made a world map to connect the levels. Sets of 3 – 4 levels were grouped together by arbitrary borders (thick forest, river, mountains, etc), and the player could free roam the world map to select levels. I had big locked doors blocking off each new section of levels, so you’d have to collect enough [insert whatever collectible it was] from the previous sets of levels to proceed. So the “lock” tile counted as solid, but it would be removed if you met the criteria. To show how many items you needed, the door’s image cycled between two tiles: the picture of a lock and a number representing how many items you needed. I didn’t add the “number” tile to the solid category, so you could walk through the tile sometimes, but not others. As a result, I had uncovered the secret to easy disappearing blocks in this engine.
My first year of using SGDK was that, over and over: a constant sense of discovery, and finding that I always had more to learn. I would occasionally start new projects, but as soon as I learned enough new and better techniques, I decided I’d be better off starting over from scratch. This still kind of plagues me in my current projects. Adam and I started collaborating on a project, but I kept finding that the out-of-the-box engine wasn’t able to do everything we wanted. That’s when I started experimenting with the scripting support. At the time, the only programming experience I had was on a TI-83+ calculator, and the idea of a function with parameters was still a new and terrifying prospect. Interestingly, those hours of searching through forum posts and building tiny proofs of concepts were slowly preparing me for professional programming.
Next time: actually starting the project!