Hello there, and welcome to Sorceress’ Spell, the blog where I, Joana, will be talking about my game development woes! 
Introduction
Today I’ll talk about my first steps to making my first game as a one person team: Codename DB (until a better name can be given). Before continuing, it’s better for me to give you a little introduction on what DB is. What kind of game is it? What’s its purpose?
- DB is, in my vision, a 2D Side-Scrolling Action-Adventure game. I’d say about 75% Adventure and 25% Action (those values are liable to change – remember it’s still in a very early stage)
- The game is going to be made through the extensive use of tilesets, whose elements will be freely-transformable. That means that elements are images that are pieced together, without limiting their position through constraints. You can place an element where you want, with any rotation and size. The same goes for anything, from characters to wildlife.
- It’s aiming to be a very visual and detailed game. I want to immerse the player in through various details and living and breathing environments (common examples would be ruffling grass and wildlife). I want the world and it’s inhabitants to be highly interactive/animated, to give a big sense of liveliness.
- It’s also aiming to have an immersing and compelling story, with complex characters, memorable locations and deep dialogue, with many choices to choose from that will alter the course of the adventure, sometimes drastically. That, apart from the environments, is to be the key of the game (hence the 75% Adventure). I have thought about having multiple branches and paths to the story. I don’t know if I’ll be able to do that, as it’s too soon to tell, but the idea has struck me. As you probably guessed, adventure subsets include solving Puzzles, Platforming and Talking and taking on assignments for NPCs, just to name a few;
- The Action in this game is going to be rather limited (although I don’t know how much yet). There shall be foes to conquer, of course, but they won’t be totally random. They’ll have a pattern and a reason for being where they are. Fighting here is normally a serious affair and should not be taken lightly (hence the 25% Action). Still, I want the action to be an integral part of the game and just as good and immersing, and feel natural and fast paced (just like any combat you’d expect to have). I want it to be a complement to the Adventure part, and thus, feel that it belongs as yet another tool to tell the story.
Seems like a huge deal, right? I don’t know how many of my visions I’m going to keep, but judging from the scope of what I’m trying to do, once I get the Editors (yes, I’m very sure It’ll be more than one) working (and that seems to me like 75% of the work, if not more), it’ll be a breeze to create this and any other similar game. I’m purposely doing this so that, if I ever want to change my story or characters or props, I don’t have to change everything. I’ll just start/keep building towards that new vision. Seems like the editor is more like a game maker, right? It is, of sorts… But we’ll see just how far it’ll go.
Why an editor?
When I had my first draft idea of what DB was going to be, I imagined it being with great scope and versatility (and seeing that list, you might think there’s a lot to tackle, and you’d be right). It was then that it hit me: I wasn’t going far if I couldn’t do an editor. Now, before you ask, I’ve read many statements about editors, some saying they are game-making blessings and others they were time-wasting nuisances. I believe that an editor is a natural extension for this project. So, why an editor? When I saw how vast this project was, I saw the utter need for it. Because making maps from elements with absolute positions is quite different from fixed-sized tilesets based games. This editor will allow me to make my maps look a little more authentic and let me tweak their positions and many other aspects in order to make them that much more natural.
Not only that, but I’ll also need to do many other things, like running scripts on certain places. The editors (once done) will allow me to do that quite simply and efficiently (or so I hope 
). Although I may waste more time coding them, they’ll prove a valuable asset by letting my creativity flow later. Basically, I’m doing the editors because I believe they will shape the game to be what I want it to be. It’ll make it a breeze to create and design levels, place entities, etc. Which is to say, it’ll give more space and say in world building (one of the game’s main focuses, if you recall).
So I started making an Editor from scratch on my own. As a rather frequent modder and map-maker, I already had many ideas in my mind how I wanted the program to be. Some of the key ones include:
- Cross-platform
- Familiar and Easy to Learn
- Fast and Responsive
For cross-platforming, the first thing that occurred to me was OpenGL. I had worked with it before in a university project assignment (curiously enough, my first serious game). On it’s development me and my colleagues had to overcome many platform problems since we were using many different architectures and operative systems among us (including the big three: Windows, Linux and Mac). In the end, we managed to make them work, albeit not as well as we might have hoped (for some cases at least). Still, that was mostly due to some problems with the library we were using, our university’s eldest students creation, which is rather new but in constant development. Still, the path opened there, and we saw just a fringe of the possibilities open to us. OpenGL, with its platform independent framework, became a big favorite of mine, and as such, became my first choice for this project.
After some research, I found out that there was a library, called SDL, that was frequently used along with OpenGL, so I decided to give it a try. Main causes where:
- Abstraction for Window Creation
- Compatibility with OpenGL with SDL OpenGL
- Image Loading Capabilities (essential for this game, since the majority of the game will be a huge composition of 2D images) with SDL Image
- Raw input processing
All of which I needed, especially window creation, input and image loading. So I took on myself to try it and see what the buzz about this library was about. As I started tweaking and playing around with it I grew to like it, and ended up keeping it. I haven’t regretted it yet!
Now, as for the game and editors themselves, I wanted them to be as straight-forward as possible. Very configurable and easy to manipulate through files. A good example might be the maps and options files. I decided to do them in XML. Why? Over the past few years I’ve learned and meddled with XML and many other file types, and XML with its tight but easy syntax is perfect for these type of things. For example, maps are made in a hierarchy, where there are layers, and inside them are elements, and those elements might be groups of other elements or single elements, and the list goes on. In order to do this in XML, I only need to do something like:
<Map>
<Layer>
<Element> <!-- A Group -->
<Element />
<Element />
...
</Element>
<Element />
...
</Layer>
<Layer>
...
</Layer>
...
</Map>
As you can see, making (and subsequently loading and saving) maps becomes very easy. Also, the node attributes can be used like this:
<Element positionX="100" positionY="200">
… Which is perfect for defining stuff like (in the example) position of an element, depth of a layer and any other thing that needs to be saved relating a certain node, keeping it tidy and simple.
The advantages are many:
- I can add or remove a Layer/Element/Anything if I need to without much fuss. Just add in a new node and you’re done. The same applies to any attribute a node needs to have.
- Everything is organized and easy to understand, read and debug
- XML syntax makes the nodes in the file nested as they should, and prevents errors in their loading and saving
So what to do about XML? I also made my research and fell in love with TinyXML. Since I’m coding in that language, I decided to use its C++ counterpart, TinyXML++, which is even better and much more suited for the project, helping a lot in many areas (especially with Exceptions and Templates).
What’s done so far?
That’s what this is about right? Well, allow me to demonstrate:
This is the Editor’s window. To the top, when the editor is done, I’ll add a Toolbar and Actionbar (hence the empty space for now). Below that is the map window, where the world building and fiddling will take place. To its right are the tileset windows (there are 2 in these screenshots, the second one starting where the text is), where you’ll be able to drag and drop (once proper input is done) elements from various tilesets into the map window, to build a map.
As you can see a lot of the functionality is already there, albeit without (much) user input. For now a placeholder allows me to test some functionalities, as user input is going to be completely redone once all current tasks and ideas are done. This is going to be the next big step (and complete with a healthy dose of headaches, I imagine).
So what can we do in it so far?
- Panning through the Map
- Zoom the Map in and out
- Remove tilesets. Adding them is only available through map loading at this point (don’t be fooled by the text ).
- Save and Load Maps
As of now, and before I move on to processing input there are some things I’ll do (some of them are already on development but not fully done yet), not necessarily on this order:
- Enable the ability to make and tear apart element groups
- Enable layer specific drawing (for example the area limiters should only show on the current editing layer but, as you can see, all of them are being drawn)
- Tileset Windows need a major overhaul in graphic terms
- The text needs to take into account if it goes out of the window’s borders (the second tileset window’s text is the major offender. It should read “Click Here to Add a New Tileset!”)
So, what do you think about development so far? Do you like it? What would you keep or change for it to become better? I welcome your suggestions and criticism!
See you next time! 
)!
