Introduction: How Sorcery Story Was Made
Hi there! This Instructable shows the long and varied process that was undergone in order to develop Sorcery Story, a 2D platformer game somewhat reminiscent of Super Mario. The project was undertaken by Miles Hammond and Devon Harris for the Butwin-Elias Science and Technology Project, a yearly contest where students can show off their inventions.
Step 1: Intro
For this project, we wanted to create something that was both challenging and fun. Most of all, however, we wanted to do something unique. Many projects are merely basic high school science experiments found online, such as potato clocks and the effects of colored light on plant growth. Personally, I find these ideas very cliche and wanted to do something with at least some degree of originality. After a fair amount of research, I was still unable to find a good project to do. Tired and bored, I turned to my biggest pastime: video games. Scrolling through my Steam library, it quickly occurred to me that some of my favorite games were created by merely one person with an idea. The indie community is flourishing at the moment, and it seems like anyone with a great idea and some dedication can create a moderately successful game. Thus, the idea to create my own game was planted, and I quickly began brainstorming for my big idea. After some initial thought, I decided that doing the entire thing on my own was probably unrealistic, so I enlisted the help of a friend. Devon has many of the same interests as I do, and I figured that combining our strengths would lessen the workload and make for an overall better game.
Step 2: Ideas
Eventually, Devon and I agreed that we wanted to develop a game that was relatively simple, as it wouldn't be overly difficult to create and it could be fun. With no prior experience, we didn't want to dive right into 3D games as developing for them can be extremely difficult and time-consuming. Instead, we stuck with the classic 2D platformer style game, revolutionized by early titles such as Super Mario and Sonic Adventure. These games generally can be as simple or as complex as you want to make them, but aren't overly hard to develop for. As well, they're usually easy to get into for the average player. We wanted a theme that worked but didn't necessarily have to be original, so we based the game around magic and wizards, with the main character being a fledgling sorcerer that grows in power throughout the game and eventually defeats the powerful evil wizard. Cliche? Yes, but that doesn't mean it can't be enjoyable. Plus, storylines are generally easy to alter so if we get a brilliant idea in the future implementing it will be a cinch.
Step 3: Software Decision
In this day and age, video games are almost always made with helpful software. From the simplest internet games to large, multi-million dollar releases, every game is built on a certain engine. There are tons of both free and paid programs that are available to consumers for video game development. I decided that I didn't want to sink any money into a video game that was still in its infant state, so I narrowed down my options to free programs. I wanted something that was both easy to use and effective. After light research, I decided on GameMaker because it fit all of my criteria perfectly. It requires little knowledge of coding and makes putting everything together a real breeze. And, best of all, the free version of it provides every tool that a beginner could possibly need. Without further ado, development of Sorcery Story began.
Step 4: Main Character
Previously, we decided that we wanted the protagonist to be a fledgling sorcerer who gradually grows in power. For his character design we used a generic "wizard" with robes, a pointy hat, and a staff. Being that neither of us had any experience at all in spriting (creating sprites, which are images that will be used in the game), I took the popular Black Mage sprite from Final Fantasy and used it as a base. I altered the sprite heavily, but kept some core concepts such as the robe design and hat shadow. I don't think that most people would notice that the main character was based on the Black Mage without being told, which is a good sign. I changed the arm position, added a staff, made the character human and bent his hat. After about 5 revisions to his design (each progressively further from the original, which was basically a Black Mage recolor), we felt that we'd really nailed the design and were satisfied with the way he looked. This was the birth of our hero, who would go on to save a fictional world from evil.
Step 5: Level Design
After finishing the main character, I left much of the spriting and almost the entirety of level design up to my partner, Devon. Seeing as how Devon wants to get into game design professionally when he gets older, I figured it would be good practice for him to design the levels and would overall create a better experience for the player as I knew that I couldn't quickly draw up fun and challenging levels. For almost every level, Devon first drew it on graph paper in its entirety to get a feel for how it would work and to easily make changes. The entire game was to be based on a resolution of 1280x720, so we worked around each box being approximately 100x100 pixels and the player being able to only see approximately 13 boxes horizontally and 7 boxes vertically at one time. Using his knowledge of level design in popular platformers, Devon tried to create levels that were interesting and challenging without being overly hard and not fun. Levels were built around the main character's proposed jump height, which made design a little more difficult as we didn't want the player to be able to jump higher than around one third of the screen height. However, levels were altered to be more rewarding due to this and we were actually able to squeeze in a few cool new sections.
Step 6: Movement System
The next logical step, of course, was to create a functional movement system that would allow the player to navigate through the rooms we designed. For this, I followed a very good YouTube tutorial [ https://www.youtube.com/watch?v=IysShLIaosk ] that explained the basics of pretty much the whole game, but mainly the movement system. The GameMaker community is enormously helpful and I learned how to create my own movement system basically from the ground up in GameMaker Language (GML), which is beginner friendly while at the same time being powerful. Although I borrowed a lot of the code for movement, I was able to completely understand the logic behind the code, which is perhaps far more important as it led to me being able to start coding and figuring things out for myself. One cool thing about the movement system that I'm using is that it goes above the very basics and checks for collisions based on space around the player rather than overlapping pixels inside the player, which really makes for pixel-perfect collision detection and smoother movement. What was really great about the movement system however was the fact that it could easily be applied to enemies so the whole game could look polished.
Step 7: Animation
Now the player could move, but things looked awfully weird with him just gliding across the ground. It was time to implement animations. Using a nice tutorial [ http://www.manningkrull.com/pixel-art/walking.php... ] I decided on a 4-frame walking animation as it would work fine for the character without being too hard to create. I took the original sprite and selected the character's arm and staff, which I moved and rotated to create the next frame. The third frame was left the same as the first, and the fourth frame has the arm and staff in the opposite direction. After modifying the character's arm to attach to the hand and making it appear as if the feet move slightly, I was able to touch up the pixels and create a working walk animation. For the jump animation, I did basically the same thing but raised the character's arm a little higher, almost how someone would look when falling. For the attack animation, I used the jumping sprite's arm and made it look as if the character was holding the staff up to cast a spell. Overall, I think the animations came out looking good for a first attempt.
The hard part began when I had to figure out how to make these animations play at the right time and transition well. Although there is code readily available on the GameMaker Forums that I could have used, I tried to challenge myself and get everything to work on my own. It required a good amount of work, but eventually I got the walking and jumping animations implemented through a mix of raw code and GameMaker's built-in actions. The attack animation proved to be a much greater challenge, and even with help from dedicated forum users I am currently unable to get it to work when it should. Even a complete rework of the code did nothing, so at the moment I'm at something of an impasse. This will change in the future of course, but I didn't anticipate so many problems with bug testing and fixing in the beginning.
NOTE: The attached pictures seem to show some strange pixels that aren't supposed to be there. In game, the sprites show up fine however.
Step 8: Attacks
Now we needed to add attacks, because the player needs a way to kill enemies and what's the point of having an attack animation without them? For them, we decided to draw somewhat from the "Four Elements" concept, although we ended up using Basic, Fire, Lightning, Earth, and Dark. So far we've only sprited three and tried to implement two as the areas for the others don't exist yet, the most important thing is getting them to cast when the player wants and kill enemies. We're trying to iron out bugs in the system right now, but we're making rapid progress. At the moment you can cast rapid-fire spells and kill the enemies very quickly, which is the opposite of what we want to happen. It will take some time and effort, but a fully working attack system is currently just around the corner
Step 9: Objects
Now that we had a player that could move smoothly, it was time to move on from basic test rooms (I used a small one to get the movement system working). We figured that our first area would be a forest and that our tutorial area could use the same art, so we began spriting the grass and soil that would be used for platforms in the levels. This was relatively easy, save for the fact that we wanted the outermost 2 pixels of every object that wasn't touching another to be black for a border. Even so, we worked around this and made every type of grass and soil block that we needed, then making them into objects that could be placed into rooms. GameMaker is very useful in this respect as it can easily assign a sprite to an object so that it can be used in a room and apply the needed properties to it (such as not allowing the player to walk through it). Objects didn't only include platform blocks, though. Just about everything had to become an object to be usable, from the main character to the sounds to the portals taking you between levels. Code can be easily applied to individual objects or groups of them, making objects very versatile in their functions and easy to work with. The hardest object to work with was actually the main character, as his code for every action was included in the object.
Step 10: Creating the Rooms
Now that each room was planned out and every possible object needed had been created, it was time to actually make the rooms a reality. Should be easy, right? Unfortunately, no. Building the rooms, even with a guide, was easily the most time consuming process and it could take as many as 8 hours for one big room to be perfected. This was mostly due to the border decision with objects and the need for constant bug testing and fixing. Adding a border caused me to have to work with around 15 objects rather than 4 or 5 and place up to 3 on top of each other in one spot for the correct look. Luckily, GameMaker's interface for creating rooms is very simple and I was able to put everything together without too much trouble.
Step 11: Changing Between Rooms
Now that the player could move around and attack (to some degree), a way to change rooms would make the game really playable. I created a system of portals, each one linked to a position in a certain room. When the player was on top of this portal and pressed a key, they would be sent to that room and position, effectively making it so you could move in between rooms. At this point the game could be played as a platformer and actually worked well enough that it could warrant being used as an alpha version of the game.
Step 12: Concept Art
I'd really like to take at least one step to stress the importance of concept art. Ninety percent of the game's assets including sprites, levels, code and backgrounds were done almost completely on paper first. In addition, the entirety of the game's dialogue and story was written down on paper long before the game was even ready for it (it still isn't, but that time will come).
Step 13: Enemies
Enemies are basically the last thing that needed to be added for a full game, so Devon and I sketched up around 10 and got to work spriting them. Our enemy designs were made mostly based on basic forest monsters, which came out pretty good. We tried to add in some concepts of enemies from popular platformer games, which would create a familiar feel to the game and make it more accessible. Enemy movement was easy to program as the player's collision detection could be reused. The only thing we had to change was making the enemies move at a certain speed by default and getting them to change direction when colliding with a wall horizontally.
NOTE: The attached enemy seems to show some strange pixels for an unknown reason. Ignore the teeth, it's supposed to be a dinosaur.
Step 14: Backgrounds
For the most part, the game was almost finished. One of the major things we still needed was good backgrounds. Again, with no prior experience, Devon and I decided that it would be easier to borrow assets for the time being. I looked around for a well-designed 8 or 16-bit forest background to use and found a good one relatively quickly. One of our levels was designed vertically, so I took a section of the forest background and modified it so that it would tile vertically rather than horizontally. As well, I wanted to make it appear as if you were going deeper into a forest throughout the levels so I made it darker and gave it a "ghostly" feel. I'm happy with the way the backgrounds look at the moment but will be modifying them if we ever try for an actual release as I'd want all of our assets to be truly original. For now, however, they give insight into what I hope the final game would look like.
Step 15: Sounds
Now we had a real, functional game! However, it was still missing something. It felt empty with no sound effects at all. Neither me nor Devon have any experience in sound design (and it's not something that you can get into in a day) so we decided to borrow our music and sound effects from the time being. Our game draws a good amount of influence from the cartoon-style MMORPG MapleStory, so we figured we'd use a few of its beautifully designed tracks and simplistic sound effects. I downloaded a few sounds ripped from the game, including four background music tracks from forest areas and three sound effects that I'd use for jumping, entering portals, and using potions to restore health. These sounds work very well with the game's theme, and I figure that they'd be more enjoyable to listen to than poorly designed sound effects thrown together by amateurs. These sounds are, of course, temporary as a game should always aim for originality and I could run into copyright issues by releasing this as my own work.
Step 16: Menu
One of the things that the game really needed to feel polished was a nice menu. Using GameMaker's built-in tutorials I was able to arrange a working menu with a title, music, buttons, and a nice scrolling background. I guess it's nothing really stellar, but it works well for the game and its style. With the addition of a working menu, the game reached its first true alpha build and was ready to play to some extent.
Step 17: Closing Remarks
Overall, I found making Sorcery Story to be a fun experience. It taught me the basics of coding and the logic behind it and gave me good practice designing sprites and backgrounds. Should I decide to make another game somewhere down the road, the process will be far easier and faster. Sorcery Story is not finished (nowhere near it, in fact) but I'm happy with the progress that has been made. Originally, we planned to have five full themed areas but had to cut it down to one unfinished area for the project as we realized that we were in way over our heads. Game design takes forever in some cases and I finally understand why the best creations can take such a long time to make. The game took $0 total to create, but close to 75 hours between 2 people.
If I were to restart the project, I would first of all set my goals more realistically. Designing and implementing everything takes a lot longer than I originally thought. For a full, working game with everything I originally planned for I'd be looking at three to four hundred total hours of work, mostly because I have zero experience in the field and everything takes much longer. Other things that could be improved include the visuals of the game (Simple respriting, but would involve an idea of how to make things look better) and the overall originality (We looked to other games for inspiration in some areas. Nothing too major, but ideally the game would be completely original). It wouldn't be too hard to do either of those things, mostly just involving creative inspiration.
In the future, I'd like to complete Sorcery Story for real. A full five areas, twenty to thirty enemy types, four or five working spells, and a coherent storyline are the main things I'd need to implement. At the moment we're working on getting spells and enemies to function right, but after that we can go all out with more spells, levels, and enemies. Devon and I are planning to finish the game as a summer project and aim for maybe a Steam, Android, or iOS release. Should you wish to try the latest alpha version, you can email me at TehAstro@gmail.com or check this Instructable for a download link (I'll update it as often as I can).
Step 18: Links
This step is a reference page for any links that I found helpful and a link to the game download should you wish to try it.
Shaun Spalding's YouTube page:
http://www.youtube.com/user/999Greyfox
(He makes great tutorials on using GameMaker)
YoYo Games GameMaker Forum
(Official GameMaker forums, with numerous helpful resources)
Game Download
https://www.dropbox.com/s/xzgoj6xs64y9un5/Sorcery%...
(Version 0.1, includes most of the Forest area and tutorial. Can be played as a platformer with no enemies. No death or saving/loading, if you die press R to load the game from the menu. Portal at the end of Forest 3 currently does not lead anywhere.)
