Dev Diary # 8, The Importance of Small Steps

It has, unfortunately, been a while since I posted a plan, going against the goal of one per week. The main reason for this is that I haven't been making much progress lately, and didn't really have anything to write about, besides trying to track down bugs.

Anyway, thats starting to change. I ran into some snags with my database approach, one was that when I picked up an item and called the script to add it to the database, there was a noticable pause in the game (a couple of frames freeze). Not good. I was a bit shocked that something so small (the tables involved aren't large) would suck so much speed. Luckily I remembered what Josh Ritter had recommended, went in and used transactions, and this got rid of the slowdown. Basically, when I start up, I begin the transaction, and when I save or shutdown I end it, which writes the data to disk.

Thats when I ran into my second bug. You see, I'd run into a "feature" that I was taking advantage of to make coding a single player game easier. Basically, I'd discovered that global variables declared on the client side are accessable from server side script (previously I'd thought they'd be scoped or something, ie the server wouldn't recognise the variable). Obviously in a multiplayer situation this doesn't work, but since I am not worrying about that, I went with it. I have only 1 sqlite object per database, which gets created in a client script on game startup, the server just references this object. Now, when I saved my game, I would close the database, free the sqlite object, copy the database somewhere else on disk, then recreate the sqlite object. But in a server side script. Except, for some reason, the recreated sqlite object couldn't be found on the client side. I tried using client commands to recreate the object on the client side, thinking the server would pick it up as it does initially, but nope, again it doesn't see it. I'm a little mystified by this, but decided to try a different route.

So I made 2 objects per database, one for the client, one for the server, and just had each side use their respective object. Worked fine, except now transactions don't want to play nice. The client sqlite object begins a transaction on the database, and locks out the server object. Gah! Back to square one.

But in the end, I realised I was just being stupid. I didn't need all that. I went back the first method, and just never free the sqlite object. I can close the database, or commit the transaction, but the sqlite object itself cannot be freed during the game or there will be problems. Its created on program startup, and hangs around until program shutdown. A bit hacky, but ah well.

But the other thing thats sapped my time, apart from the bugs, is I went off the rails slightly again. It was the database design. I'd gotten into the trap of thinking about it too much. Trying to lay it all out on paper, design it "right" before coding. Bad move. I was forgetting that the prototyping idea applies to the database as well. By trying to tackle the entire design, I was biting off to much, wrestling with a mountain. Too much theory, not enough getting my hands dirty, trying something, and adjusting it if it didn't work.

Between that and the bugs, I wasn't making much concrete progress, kinda arbing around and playing with ideas, and just generally losing time and motivation. Dammit.

The key is small steps. One at a time. So, to get myself back on track, I decided to focus last night and get race selection with all the GUIs done. The underlying database existed, but the player couldn't actually choose his race. Building GUIs is a bit of a pain, its fiddly and time consuming, but it needs to be done. I'd been putting it off as one of the small steps that I'd look at later once I'd tackled the "bigger issues". But each little issue you tackle brings you closer to your goal, and the best part is tackling them gives you a sense of accomplishment, a feeling of having checked something off your list. So I built the GUI, wrote the scripts, added the GuiObjectView resource (awesome btw), fiddled with my directories a bit to get different characters, and made sure it was all working right with the save-load code. All in all it took about 3 hours and its the most satisfying night of game dev I've had in a while.

So now you can select your race from glowy-block man, orc, or the soldier pack guy, all of which have different stats. Inventory is working, and it all can be saved or loaded. I'm getting closer to being where I was before, except with a powerful database to make use of. Small steps get you there. Focussing on one issue at a time, and chipping away at that mountain.


Besides coding, I've also been thinking about the RPG design. I've decided to go with a skills based, use-your-skills-to-level them design. There are advantages and disadvantages compared to the traditional experience system, but the thing that is most significant for me is that it encourages other types of gameplay besides killing. Now, I have nothing against violence in video games, its just that I am a huge fan of the Thief games. I loved the feeling of sneaking into places like a shadow, getting in, stealing the jewels, and getting out without anyone being the wiser. An experience system discourages that. Since opponents are worth exp, you are motivated to leave a bloody trail behind you. Now, I could make it that only quests give experience, but I want to encourage free-form gameplay, ie give people a bit of a sandbox to create their own fun with. If quests are the only things that give "advancement", you encourage players to ignore all else and just "grind" them. As an indie, I don't have massive resources, if you can create a system that lets players have fun by messing with it, it means less work for you creating tightly scripted quests. A definate bonus ;)