Devlog 6 - Occam's Razer

My sketchbook and design/writing notebook for the game. I like to be a little fancy!

An interesting week this week, friends. Well, every week is interesting at this end of a game, where every problem is a brand new problem, you're still working everything out and you haven't hit those mid-game doldrums of "I like being creative but this week all I am doing is things I already know how to do". Don't get me wrong, I am looking forward to most of the problems being solved and the process of building my ideas not being a matter of solving 3 different problems every time, but there's also the fact that problem solving is satisfying and it feels good to walk away from a problem that you weren't sure how to solve.

Design

The first thing I did on Monday morning this week was patch up a few little issues that I knew about, and then compiled the project and asked Kelsey to take a look at it. Over the weekend I reached the conclusion that I wasn't going to be able to continue making improvements to my systems until I got an external pair of eyes on things to see how an actual player would interact with them. She's a perfect candidate for early playtesting because she is well versed in the genre, but won't approach the project like a designer, and is also both attentive to systems and not particularly interested in slogging through clunkily designed interfaces.

So, with a very limited build but with all systems working in the way I had planned them up until that point, I sat quietly and watched while she played, reminding myself that it's always awful to watch people play your projects, that it's normal for things to not be communicated well and for this to be frustrating to see, and that there were going to be bugs and that I could fix them. And... much to my delight, the systems all worked. There were a few little bugs which I could talk her through, and she asked some questions (some of which I answered, and some I remained quiet to see if she'd figure out the answer by playing), and I noticed some things that needed to be implement more clearly, but overall I was so pleased to see that everything worked more or less as expected, and that I think I have a good foundation for a game here. Oh, thank goodness. What a relief. That wonderful feeling of hey, this might be a solid idea after all. 

We had a discussion after she had accomplished both of the small goals in the build, I made some notes on things I can fix and improvements I could make and then I thought it would be fun to show her the system I liked the most, so I told her what to do and then sat back to watch my cool project at work. Of course, that immediately broke something. "Well," I thought, "it'll make for a funny end to this part of the week's blog post."

Troubleshooting

In the process of trying to get the project in a worthy state for someone else to take a look at it, I had written out a list of issues that I thought should be cleared up first at the end of last week. One of the harder to find ones was a strange bug in which sometimes my mouse handling code wasn't processing clicks. I have quite a few lines of code handling all of the mouse and interface stuff (somewhere between 500-600) and so it wasn't too surprising to me that I might have made a strange mistake, and I spent a good hour or two going through and cleaning all this up, making it nicer to read, and replacing some of the repetitive bits with for loops. No luck finding that bug. The next day I was playing some Skyrim (it makes sense, I like old RPGs, and old computers, and keyboards and mice without these glowy lights on by default - my mouse has started doing this fancy pulsing glow lately that just seems completely unnecessary) and also getting a little frustrated at some of the bugs in that game. Weird pathfinding, the mousewheel handling through menus is very strange, sometimes I'll be underwater and suddenly fall to the ground as though I'm in the air. Oh and sometimes when I go to cast a spell nothing happens.

This was particularly frustrating when I was clearing out a cave of tough bandits. Stupid game. I'm clicking the button but nothing is happening. Oh, wait a minute. I know where I've seen this issue before. Hang on, maybe there's a reason my mouse has started doing a fancy pulsing glow lately.

No, reader, I am not proud of how long it took me to make this connection. But I am pleased at the fact that unplugging my mouse and plugging it back in again seems to have fixed the issue. Occam's Razer, right? (Actually it's a Keychron but you know I had to). 

Programming

All that said, after Monday morning's playtest session I had a new feature I wanted to implement which immediately filled me with dread. I knew the logic behind doing this task, but I figured the implementation of such logic would be overwhelming in a very draining way. Reader, I'm happy to report that I got it working in about 15 minutes, and the delight I felt as I watched this feature triggering all of my test flags was so great that I let out an audible sigh of relief. It's like solving the best puzzle.

After that, I set about doing what I knew I had to do - I stripped out most of the hard coded functionality for the prototype I had sent and started rebuilding my systems to be more modular. This has been kind of a theme for this project, but it's an important one. One of my goals is to work with what I think of as "Attribute based design". Rather than each interaction being completely hand-coded, my aim is to give the player a handful of abilities, and then have the attributes of the items in that world inform how the world reacts to those abilities. Imagine if you were playing Loom, and got the draft that allows you to turn things green, and rather than only being useful in a handful of places, you can now turn basically anything green - it's just that this only has a "puzzle solved" effect in the appropriate places. This is more like the approach I'm trying to take, but I don't want to write this code individually for each individual hotspot in the world. Hence the constant refactoring.

One nice thing I learned about AGS in the process of setting this up is that extender functions can be passed with identical function names as long as the type changes. I vaguely suspected that this might be true due to the fact that we can call things like Character.Scaling(); and Object.Scaling(); despite the types being different, but I was still very suspicious on Wednesday morning when I typed my duplicate functions in and it just... worked. I had this explained to me nicely here when I posted about it, and what a wonderful feature this is. I then mentioned how wonderful this is to Dan G and he gave me a name for it - "Function overloading". That's the best thing about relearning programming by actually making a project - I immediately find an application for everything I learn. In any case, now when I put a new hotspot or object in my game, the default handling for trying to use your abilities on it is not "I can't do that" or no response. The character walks to the coordinate specified in the properties (not using the built in walk to coordinates because it won't work with my systems), faces the direction specified in the properties, and then checks the objects other properties and applies the ability or gives the response according to those properties. I think of it a little like The Incredible Machine but in an adventure game, except my machine is a lot more limited and much more credible. Or is it...?

Writing

Writing an adventure game is interesting. It takes a while to get to know the character and most of the lines require you to know your character reasonably well. So I'm not stressing too much about getting things correct just yet. I know my character's backstory and his goal, I know the setting and the plot, but the little things will take time. It's fine, I have time. It is interesting going through hotspot descriptions and interaction responses and seeing if I can give more details about the world and character through those, though. It's a little bit like setting all the design elements in place and then playing the game and allowing it to tell you what it is. 

This sounds kind of like nonsense but it's the same with any form of improvisation. Play a few chords on guitar and listen for what is good, what is bad. Make a few marks on a page and look at what looks good, what looks bad. Eventually if you keep carving all the things that aren't the head from the block of marble, the block of marble is a head. The quality of that head does depend on your actual skills to find the good and the bad, though, sorry, the first one at least will probably be a bit crap. At least I can erase my crap lines. Stone is a bit less forgiving. I once had someone try to get me to come and do tattoos for their backyard tattooing business after they saw my artwork. The ultimate form of "no undo"!

Summary

Okay, so I've proven that the system works, the interface has potential, and I've rebuilt it all to be flexible. My next steps are to build a small chunk of game and get a small group of people playing it, and seeing what they think. With all my heart I yearn to do cool animations, a detailed and animated interface and polish up the scenery, but there's no point perfecting something untested. So that's my next goal, I'm building a section of game with just a few small but diverse and reasonably intricate chunks of gameplay that will get the player to use all of their abilities (and hopefully teach them how they can work in unison) and then we'll find out if I have a worthy enough design on my hands to start building a proper game from this, or if I need to go back to the drawing board and rethink some things. I'm going to get people to do some regular playtesting - I've got another one lined up with Kelsey on Monday just to see how she interacts with the new things I added, how everything is working together. From there I need to write out a big todo list and then just get building.