Devlog 13 - Nobody will ever grasp exactly how much effort I have put into getting the tiniest things feeling good.

It's so nice to know what I'm making now. Having actual solid direction on what I need to do is great, although it means that my todo list has gotten both longer and more filled with stuff that takes me way too long. Sometimes I think how much simpler things would be if I would allow myself to just design a straightforward AGS game, with inventory and dialog and that's it. But I know my heart wouldn't be in the project, it would scratch my urge to experiment with gameplay, and I feel like I've made enough of those already to do something different. It's just that everything takes so long now and while I can feel my skill at working with AGS script improving literally every single day, I also spent 3 hours yesterday fighting with room overlays and I still haven't solved all my problems there and I don't know how much more time I can justify spending on learning how to use them right now while the rest of my todo list looms.

This week I want to shout out vga256's EXiGY project, which was announced last week. I've been hearing about this for around a year, and we've spent many hours talking about design ideas, development woes, and the usual things that two people working in similar fields always talk about. There's some blogging about the process going on over there, too, so if you like reading these, you will probably like reading those.

Graphics

The build I sent out had the scenes roughly painted up, but being unsure about the solidity of the gameplay I didn't spend too much time polishing them, so I've quietly been seething at myself for these half finished, amateur looking scenes while I try to remember how to make computers do what I want. Anyhow, with things working better I started painting the scenery up properly this week, and found solutions to some of the problems* with the scenes ended up being a bit simpler than I thought. 

Of course, nothing in the scenery has changed at all. In essence they're exactly the same scenes, just now I've worked three times as long on them and am less dissatisfied with them. I expect some testers will struggle to notice even one difference between the 'bad' version and the 'fixed' version. But that's the way of the illustrator, I'm used to this. See the title of this blog post.

Coding

After my efforts last week, the last thing I needed to learn was performing a modulo operation in AGS. I know this is probably considered very easy but for some reason I have a hard time visualising how this works and so my three different effects that require this took me far too long to put together. At one stage I actually had an effect indexing through an array backwards. I'm a graphics person, right, I haven't done utility maths in years, so some of these operations I had to write out with a pencil, stare at them with my head in my hands for a while and then go "Oh, it's that easy? *sigh*". At one point James Spanos gave me some information on what will make the engine run slow that helped me understand the issues with something I had written which allowed me to refactor it, which was immensely helpful. Prior to that it was one of those problems where the issue was that I didn't even know what the issue was.

I have everything working more or less how I want it to at this stage, in terms of how it feels to operate your character's abilities in the world (with the exception of every single edge case that I *know* will crop up) and so after some more tweaking and adjusting I'm going to send out another build with the clarification that there's no more gameplay, I just need feedback on what's annoying and what's fun in my UX. 

I have no doubts that some stuff that I think is really cool will be horribly annoying to some people. There's one detail that I know is inaccurate, but feels so nice to use to me that I hope nobody cares. I had thoughts on how to fix it but it involves another two modulo operations and I don't even know how well the fix would work and I need a break from maths. I also have no doubts that some of the fine details will not be noticeable at all. See the title of this blog post.

Design

There's a fun thing in illustration where you make a change to an image and you can't decide, so you turn the layer on and then off again. Slide the opacity up and down. Maybe it's somewhere in the middle, but 47% opacity feels like too much, 46% opacity feels like too little. It's a kind of ensnaring vacuum that eats hours of your time. I'm finding the same with design - I move an element to the bottom of the screen, I move it to the top. Not sure. Let's make a hardcoded element a variable now so I can experiment more. Every script in the game has an expanding list of things that were once hardcoded and are now variables while I tweak and test and repeat.

It's amazing the things that I've found myself doing in the background because a mouse mode didn't feel right, or something felt too static, or things just felt wrong. Sometimes I find the solution very quickly. Other times it's the sad understanding that all the endless tweaking isn't fixing anything, you have to throw everything out and start over. Some things that seemed like a solution to something not feeling good ended up making it feel even less good. I want the player to always know what power they're using, intuitively. I want the act of using that power to feel good, like you're dragging that power around the screen as you move your cursor. Some nights I have stayed up until 3am trying to accomplish this. See the title of this blog post.

Summary

Sorry for the long post this week folks, I was out singing and playing guitar for 3 hours tonight and so my usual editing process was skipped over. These are the ramblings of a tired man who is trying to do illustration, animation, programming, music and various other things all at once and I know everybody reading this will think "Yes, Ben, that's ALWAYS the way it is". I know. I know the person making pizza crusts has attention to details doing that I will never even conceive of, as is the person painting lines on the road, the person writing a book about moths, etc. It all takes way too much effort and time and it's not fair that making good things takes a silly amount of work. But I'm enjoying the process so much, despite all my moaning.

I'm also still playing loads of Jagged Alliance 2 because it's the time of year I always get sentimental about long sessions in strategy & RPG games over summer holidays. It's probably how I ended up here in the first place. And Jagged Alliance 3 is really good and I enjoyed it so much, but Jagged Alliance 2 is Jagged Alliance 2, you know?

Thanks for reading :)

*the problems, in general, being variations on "this looks bad and I want it to not look bad"

Devlog 12 - Dynamics

This week was off to a good start, with the feedback from all testers being very positive (except when Windows Defender accused my project of being a virus and deleted it - searching the forums shows that this is a reasonably common issue and I'm guessing that until builds are distributed by something like Steam it will continue, unfortunately) and the general consensus was that with a few little tweaks, everything is in a very solid place. It's very clear to me now, looking back at the build I sent out a few weeks ago, where all of my design mistakes were but play isn't something you can taste yourself, like a soup. It's hard to know if a crossword clue is good or bad if you set the clue, because you already know the answer. And so it's thanks to the extremely valuable feedback from my testers that the game's foundation is solid, and I'm now ready to start building an actual game with it.

I'm also giving a shout out to Amberspire which was announced this week. Nic has been a great source of feedback for this project I've been blogging about (the source of the note "I wouldn't want the game to feel like it has a systemic core underneath it, but in fact the solutions be very linear." I highlighted a few weeks ago), and they let me play an early build of this game and it's very frustrating to come across what is very much a "just one more turn" game when you already have lots to do, especially one with such a lovely aesthetic.

Coding

Following on from the wonderful range of suggestions given to me last week by a number of people looking at the code in my last post, I spent a good amount of this week taking my functions and cleaning things up. There were a number of very helpful suggestions that showed me how to make things more readable and aid trouble-free adjustments, and a few that solved a number of tiny issues that had been things I accepted because I didn't know of the alternatives. After the push of rapid changing and prototyping in the last few weeks I knew I would need some time to clean things up, and so had allocated this week to be time for renaming things properly, addressing new feedback, and refactoring code where necessary. I've still some work to do here but in general everything is much nicer to look at and navigate, so thanks again to everybody who gave me suggestions!

I initially suspected that this would be incredibly distracting, but actually it doesn't seem to be at all while in game. It also makes it extremely clear which ability you're using while this mode is selected, which is very helpful!

I also wanted to allocate a little bit of time this week to re-learning how to use dynamic sprites in AGS, which turned out to be reasonably nice and simple for the most part. One thing I was struggling with myself when testing the build was knowing which ability I had active, even with GUI buttons highlighted and the literal ability icons following the cursor around, so one UX thing I wanted to improve was making the currently selected ability immediately intuitive. Diving back into my poor, messy test room I made a simple dynamic sprite of a lightning arc that connects the mouse cursor to the energy meter as one of my first experiments, and while "Drawing some lines" is hardly the most impressive thing one can do with a game engine, I considered it a reasonably good "Hello world" starting point here.

Armed with that confidence, I then set out to recreate a warped glass sort of effect that I was playing around with more than a decade ago, adding in a few little extra touches to give that little 'science-fantasy' feel. You can see the result below, not too bad so far. I'm given some encouragement by this progress, and have banned myself from having any more fun with this until I've made some more of the actual game.

The first version of this I wrote this week had the FPS counter sitting around 35, which shows you that even a very low resolution game can run badly under the direction of a fool. This gif looks choppy because of the screen recording software which is missing frames (you can see by the loop counter), but it's very smooth and nice in game, even on my little laptop.

Writing

I still have only spent a tiny amount of time on writing, but in putting together a little bit of dialogue to help guide players through the build last week I arrived at an interesting thought. Often in game dialogue the player is provided with multiple ways to respond to a statement or question. A lot of the time in RPGs the choice is "Good alignment accept quest/Evil Alignment accept quest/No I don't want this quest", or Jon Ingold speaks on "Accept/Reject/Deflect". A lot of the time in adventure games we like to either just add some in for variety or comedy value. But what I found was none of these approaches quite suited the section I was writing, and yet it felt like I should have multiple options here.

Eventually after deliberating on this for a while, what I realised was that having the multiple options actually acts as a way of parallel information giving to the player. For example, let's say a character confronts you with "Why are you late for work again?"

You can give the player the following options:

-I slept in again, I had to deal with the baby half the night.

-Hey, go easy on me this month. Remember how much I covered for you in summer?

-Shouldn't you be focusing on your own work? Management says your sales are down.

Not particularly exciting examples, but the nice thing is that I might want to give all of this information to players, without having to force it out unnecessarily through linear dialogue. Even though the player only gets to pick one of these options, they are presented with all three points of information in parallel, so in addition to giving them the ability to pick a response that suits their style the best, the writer also gets to give them all of this information in a way that doesn't feel overlong. I'm sure writers think about this a lot, but to me this is a new angle to consider.

Design

One of the most interesting things to report is that I thought the prototype build would be far too obvious, be considered a little condescending, and almost be annoying to players. Not at all. In fact, some of the things that I thought were too obvious were perhaps not obvious enough. It's so interesting to be so wrong about these things. In any case, I've committed to making players as entirely aware of how the various elements work at all times so that the interface is never the challenge, only the gameplay itself. I went and played a little Commandos 2 to remember just how awful an interface can get*, and then threw myself in to making my own game as straightforward as possible. I even changed the name of one of the abilities so that all of the hotkeys are grouped together on the keyboard, which feels SO nice to use.

One thing about having things in good working order is that I need to now stop thinking about what abilities I am going to give the player and now start building a game around these abilities. It's a little like having all the furniture built, and now I have to decorate a house with it. I have more experience doing this part than I have with doing the part I have just completed, so I am expecting it to be harder, because of course I want to design gameplay that is satisfying, just the right amount of challenging, and memorable, and of course that is much harder than "I want to design some fun abilities to play with".

Summary

I am buoyed on the good response from testers, on the excellent suggestions regarding my code, on the fact that I managed to hit my goal of having an updated build out to testers before the end of November. This week was a more relaxed week after the big push of the last couple of weeks, but I'm back to designing and building new sections of the game next week, and I'm curious to see what will happen as this game gradually reveals to me what it is. Thanks for reading folks, the comments and suggestions have been a great motivating force. :)

*sorry Commandos 2 fans, but as a fan of the first game, it's incredible how much more complex the interface got for the sequel. I know many people love the game but I find the UI just about unusable. One of these days I'll learn it. Maybe. It doesn't help that there's no quick reference card, only half the hotkeys are listed in the manual and some of those are wrong.

Devlog 11 - Systems!

Well, I've rebuilt my systems, I tried to design a gentle onboarding process, and I have given myself the day tomorrow to add some fun stuff into a build that has been almost entirely focused on being non-frustrating and robust, and then it's testing time again. Let's go through what I have tried to address!

Feedback 

After my first round of wider testing I highlighted three comments that really spoke to me about where I could improve the game, so here's how I've tried to address them:

"A lot of vectors to "do" things and I fear it's confusing." Firstly, the number of vectors have been reduced. Some of the things that were being handled with two separate vectors are now handled with a single one, and some of the things that the player had to do manually are now being handled automatically by the game. Secondly, I have built a small section of game that is designed to introduce the player to the various vectors one at a time, so that they are not immediately confronted with a whole slew of confusing options. I suspect this may feel a little too pandering, that's okay, it's hard for me to tell from my position and so I can only design it the best I can and wait for feedback.

"I wouldn't want the game to feel like it has a systemic core underneath it, but in fact the solutions be very linear." I have made a point of introducing the player to the idea that there are multiple ways of solving puzzles within this small onboarding section. When the player solves a small obstacle with one method, the game checks which method they used and another character points out the other method that could have worked. This is a small thing, but I am hoping to convey to players that this game will have mechanical non-linearity. There may be "consequences"* to your actions - maybe you will use a resource that you would have not used otherwise with a different solution - but I want players to understand that they have options. Such is the entire point of building a systemic foundation.

"[ability] felt really good because it had absolutely no gameplay system connected to it. I did it just to feel good." Some of the stuff in this build (and some of the things I hope I have time to add tomorrow) will absolutely be "just for fun" stuff. I want players to feel satisfied by overcoming challenges, but I also want them to have some joy in just poking at this world and seeing what happens outside of those challenges. This is the thing that led me to enjoying adventure games as a kid, the satisfaction of solving puzzles didn't kick in for me until much later.

Coding

So obviously I have been doing lots of this the past few weeks, and I keep talking about "systems" and so I want to show roughly what I mean here with a simple example:

Rarely have I regretted anything as much as the space between words in the property "Max Energy", a sin I pay for every day and keep meaning to change.

Here's an example of one of the player's abilities, which is "Flux" - giving and taking power from devices in the world. It's the most straightforward of your abilities, offers the least amount of fun, creative design, but when used in combination with your other abilities it offers some interesting gameplay options. In the process of using this ability on a device I have to do a number of checks to see which party has how much power, how much power each party can hold, and trigger a variety of different animations and responses based on the outcomes of these checks. I also know that every time I use this ability the player will have to walk up to the device and touch it, and different devices will require that the player walks to different locations, faces different directions, and plays different animations. Some of these animations will require the player to reach below the bottom of their feet, meaning we have to account for an offset (I have done enough animation work with AGS to believe that I won't need an X offset, but I can add this easily enough if it does become necessary).

As you can see from the code above, I've automated this whole process via a series of extender function calls and custom properties. I have to make sure that I populate each new hotspot with information that will drive these functions, but this is very quick and simple to accomplish. Then, when I want to add this ability to the hotspot I simply use:

With this single function call all of my animations, calculations and fiddly little things are handled for me, keeping my room scripts nice and neat and saving me from having to remember coordinates and sprite numbers/animation loop numbers, and meaning that I only have to write each function once. It's been a little intense getting these various systems built after my years of being away from coding, but it's coming together nicely. We'll see if this is smooth enough in the upcoming test!

Design

Most of my design lately has been focused on being gentle and informative, to help guide players into the experience, but I have still been thinking about systems based design a fair bit in the background, and playing a wide variety of different games to see how designers think about challenges outside of the very discrete world of point & click adventure games. It's really interesting to break games down into their core systems and see the various factors involved, and sometimes see the challenges that present themselves. Here's an interesting problem I noticed this week, playing "Inventioneers", a very well made clone of The Incredible Machine for iPad. Here's a viable solution to a level, in which your goal is to put the snowman's head onto his body:

It's typical fare for the genre, the balloon lifts the head, the timer wakes up the blower chap who blows the hammer which swings around and knocks the balloon into the scissors which cuts the rope, etc etc etc. However, one of the obstacles is a wall of ice, which you can handily melt by putting a flamethrower chap in place and dropping a bauble on his head to make him shoot fire. Anything in front of him with the "ice" property will melt, the snowman's head can pass through. But, in action:

See how the snowman's head happily rolls directly into the blast of the flame? It doesn't melt. That's because the snowman's head is a "goal" object, not an "ice" object. And so the logic of the game breaks just slightly because an object that I know is ice is not acting like ice. Of course, I can understand why the developers of this lovely children's game didn't want to draw a horrid animation of a lovely snowman's head melting down to a withered carrot and charred top hat, but this illustrates the sort of thing that I will have to be careful to avoid in my own project if I don't want players thinking "No, I can't send the snowman's head through there, it'll melt" and them getting stuck without trying it as a solution. Much to think on!

Summary

It's been a busy week, and I wish I'd given myself another day for adding fun stuff and polish, but tomorrow will have to be enough and there's no point polishing something that absolutely needs testing before anything else. I'm not confident that I've solved all of the problems with my first build, but I do think that I've taken steps to address the majority of the non cosmetic concerns (the fonts are still awful, there are still many missing animations and things), and I will start making plans for what's next once I have gotten some more feedback from folks and have a better idea if I have made progress or not! Thanks for following along in the journey! :)

PS: If you want to critique my code here, feel free! I'm very much an amateur, looking to improve my abilities.

*I am approaching consequences here quite differently to how I usually see it done in adventure games. I do not plan to scold players for their decisions, to change the ending based on their choices, or to present choices as 'better' or 'worse'. Instead I am interested in allowing players to solve problems in multiple ways. This is inspired by my love of RPGs and the like which allow a fairly wide variety of options to solve problems like "get into the building". I am even planning to have things designed so that if you spent a resource (say an inventory item) in solving a puzzle one way, but then think of a different solution that either doesn't spend that resource or spends a different resource, to allow the player to go back and undo their solution and do things a different way. Think of games like Eye of the Beholder, where you could hold a pressure plate down with a sword if you had nothing else, but if you then find a rock through the door you just opened, you can go back, pick up your sword, and put the rock down in its place. Or put the rock down as well as the sword. Or maybe your party is all casters & thieves and nobody uses swords, but rock throwing is great for you in combat. Options! :)

Devlog 10 - Progress, Again.

I have more than just old game scenes in my reference folder, but I'm keeping my PureRef file to these for now.

No Monday morning test this week, because while I rebuilt my UI at the end of last week, the UX still needed a fair bit of work. So a good chunk of Monday was spent doing UX refinements. It's mostly a thankless task because UX is a bit like a font. You only really notice them when they're annoying, when they're done well they are basically invisible to most users. It also seems to be the consensus that the best way to get UX right is to keep getting it slightly less wrong through each iteration until it's basically not annoying anymore. So a lot of the day was the cycle of implement, test, adjust, test, etc. By the end of that development day I had everything feeling pretty good to me (although there's a tiny bit more vector math I need to do in order to get some timings right. Later, though - it's a simple enough calculation, I just have to stay focused on productivity so I can get this new UI in the hands of testers).

I finished off the day by re-learning how to use drawing surfaces & dynamic sprites in AGS. You can't say I don't know how to have a good time.

Tuesday and Wednesday were spent building a second room designed very specifically to teach a particular idea, and on Thursday I designed another room to teach another aspect. Friday I was fixing, polishing and implementing stuff, not doing new things. Next week I plan on getting all of this gameplay working, polishing and tweaking and trying to make sure it feels good, explains itself well and if I can have it in some sort of decent shape, I plan to get testers looking at it again by the end of the week.

Where I think the project sits now:

I think it feels good to use your abilities. When I was testing the game before sending it off to testers, I felt the tedium of my own systems. When the tests came back reflecting this, I wasn't surprised. I don't think the whole thing is "right" yet, though it's a lot better. Still more to do, but I think it can be refined, honed, tweaked. I even expanded how the abilities can work a little, and I expect this will keep happening the more I design around them.

I think the mechanics can be used for some clever gameplay. You only have a few abilities, but they can be combined in interesting ways, and I already have a list of puzzles that I want to build. I fully expect some will work well, others will get thrown out, but this is my first time ever designing in this way, so that won't be a surprise.

I think I still need to find the fun. "Clever" doesn't necessarily mean "fun". I worry that the limited number of elements will make for repetitive gameplay - though of course aside from the things I've been building, I have the normal avenues of inventory items and dialogues with which to craft gameplay. But I have been very, very focused on the systems and the foundation are not the gameplay. On Friday I finally started to try to put the "game" in, as opposed to working strictly with mechanics, and I'm hopeful that it'll start to come to life soon.

The systems are not the gameplay. This was the topic of some extremely sleep deprived, late night, "I have to rethink how I approach implementing these ideas a bit" emails to a friend last weekend. Yes, of course, I have been focused on getting the systems sorted out. That is crucial. But once they are, the gameplay will not be a solved problem, in fact, it will only be the beginning of the problem. Designing a system does not mean that you've designed gameplay. It means that you've designed some tools. You then still have to design what you want players to do with those tools. My game is not fun yet because my focus has not been on designing interesting gameplay, it has been on designing a foundation. It's akin to making sure that it feels good to make Mario run, jump, shoot, fly first, and then you can design your challenges around these mechanics once they're right.

I think my game will look nice. I mean you all know what to expect from what my games look like now, and in drawing my own visions it's almost comical how quickly my style throws back in time a decade or more and I'm drawing the most Ben304 looking game ever. But I've looked at art a lot since back then, and I've honed my skills. I made a big PureRef file that you can see at the top of this post with some of the influences for the project, and the two scenes I painted for the game are scenes I feel good about. Even though I am plenty experienced at doing game art, it still takes a while to find the right direction for a project. I think I'm getting there.

Summary

In general, I feel good about the progress this week. My instinct is always to push forward, move ahead, feel productive, but the outcome of my last test told me how important getting this bit right will be. I've even changed one of the abilities slightly after having done some design around it, and this is what I think of as "the game telling me what it is". I can't promise that the next test will not be miserable for everybody too, but at least I'll know I've tried!

Devlog 9 - Taking direction

Here's a sketch that I put down randomly months ago just to capture an idea that I went back and referred to when laying out a new environment this week.

The week began with me getting a great amount of feedback from my very patient testers, and some things were made abundantly clear to me:

1. My current interface is not clear, is not intuitive, and is tedious to use. This isn't a great surprise to me because the game's design was torn in a few different directions for a while, and it's still taking shape. Getting the interface right is something that can't be finished until I know what the game is, and that takes time! But working on this has become my #1 priority now.

2. Trying to use subtext with gameplay elements is not working. That should be obvious, but it wasn't until I put the game in front of other people. There's a couple of things that I have been trying to do in a clever way, and absolutely nobody understood them. That's okay, UI and UX design are probably my biggest weaknesses, but I know this: I have to refocus everything towards clarity.

3. People seem to be more accepting of the game's tone than I expected. Somehow this was my biggest worry going into the prototype testing phase, and largely people were pretty okay with the tone, it seems. I'm still a bit too wordy, I need to give the players a bit more motivation, but I have spent very little time on any writing, and I believe I can fix those things.

4. I think the game's second area is more coherent than the first. The feedback on this was not unanimous, and I think some of this is absolutely because of UI/UX issues getting in the way, but I feel this way, and the shape of the feedback seems to imply this. The difference being: I designed the first area while I was still working out how the player's abilities work. I designed the second area once I had figured them out. Hardly a surprise that my ability to design around them has improved.

5. My coding is reasonably robust. After the first two lots of feedback came in, I jumped back into the project and made a number of changes to try and make the game less tedious and unclear for the third tester, and because all of my interactions are handled with pointers and functions, doing so was a matter of just an hour or so worth of tweaking. That's a good feeling! The only thing that broke was the final puzzle of the prototype, which I am probably going to cut and implement in a more clear manner.

I want to share one snippet from each of the three test reports that I got back that really helped me solidify an affirmative direction for me this week:

"A lot of vectors to "do" things and I fear it's confusing." This was an excellent way of summarising the problems very succinctly, and kind of condensed all of the feedback down to its core. I believe it's quite acceptable to give the player various vectors to do things, as long as those vectors are extremely clear, and the onboarding process is curated towards clarity also. That way players can operate with intent and make deductions and decisions and feel like they are in control, rather than trying to guess at what will happen.

"I wouldn't want the game to feel like it has a systemic core underneath it, but in fact the solutions be very linear." Perhaps the ultimate compass with which to steer this ship at all times - if you give the player a lot of options, and the game allows them to do all of those things, but the actual world interaction itself is entirely linear, then the systems have been largely squandered. I need to make sure that my gameplay design aligns with my systems design. There is some dichotomy here between the solutions based puzzle game and the exploration based adventure game that I have been trying to balance, and to have it stated this elegantly is so helpful.

"[ability] felt really good because it had absolutely no gameplay system connected to it. I did it just to feel good." This was exceptionally valuable to me because I had spent so much time trying to develop the systems that this had been my core focus, and it was wonderful to hear that and interaction I had put in just as an exploration of the world and character actually felt rewarding to a player. It reminded me that players aren't just here to "solve problems". Having systems that allow the player to interact in detail with the world is great, but some of those interactions should be just for exploration, even if it's the outcome of using an ability. Exploration is gameplay!

Summary

Okay, so let's sum all of this up. 

Nobody had fun playing the prototype. Everybody mentioned that they liked the ideas, that the core is good, but the UI got in the way, and the UX got in the way, and it was generally a frustrating, confusing mess. The UI cannot be saved, and so it's been thrown out completely and I've rebuilt it. I am okay with this, I was not attached to it at all after testing the game myself using it a number of times.

Everybody seemed into the setting. A few things to polish and tweak, but I always expect that. That means that I am building a world people want to explore, and that's always one of my biggest goals. I feel good about this. I would say that I didn't spend much time on this, but that's actually quite wrong, I have dozens of pages of sketches where I slowly developed the game's world, bit by bit, earlier in the year. That fact that it was so long ago just make it feel like it wasn't much effort - I definitely put lots of time into it.

People liked some of my cool visual effects, disliked others. I am an art man, not a design man, and so I want to put interesting visuals on everything. Sometimes that is annoying. That's okay, I can strip out most of the stuff people disliked without being too disappointed. Some of the visual things were just distracting. I don't want people getting distracted.

Having rebuilt the interface, I'm now building a gentler introduction to the mechanics. I expect that I will probably make it too hand-holdy. That's okay, I will accept feedback on that part and take it in my stride. I'm still finding out the shape of this game, and I've worked on enough games now to know that some of the best ideas take a while to emerge from a project. If everybody hated all of the mechanics and told me directly then I would accept that my ideas are bad, and scrap the project. That hasn't been the case, so I am grateful for the silver linings, and I shall do my best to address the rest!

Devlog 8 - Putting it to the Test

This guy from Eric the Unready is one of my favourite guys.

Another week down, another few things off the to-do list. My primary goal for this week was to get a prototype in a decent enough shape that I could send it to a few testers with whom I've specifically discussed gameplay design with in the past, so they could try out my systems and share their thoughts on whether they work or not, what feels confusing, what feels tedious. The writing, art, animation and audio is all still very much WIP, but I have a different set of testers that I think of as more "mood" or "overall" testers that I'll show the game to a little later, when this stuff is all more set in place. In any case, I successfully hit my goal, and have sent a little prototype off. Depending on how busy those folks are, I'll be sharing the outcome of this in upcoming devlogs!

Testing

Monday morning's playtest this week went very well. Another reason that Kelsey is an excellent candidate for playtesting, aside from what I mentioned in my earlier dev diary, is that she's quite an emotive player. She'll mention immediately if something is frustrating, or confusing, or feels broken. She also reacts quite audibly to things she thinks are funny, interesting, strange, etc. In this case, I had put her in a brand new area with familiar elements, and a puzzle that was intended to be a combination of all of the elements that I had built - effectively, showing the player how the abilities they learned how to use in the first area can now be combined together in order to overcome an actual puzzle. The player is purposefully confined to a single room while they figure this puzzle out, and I watched Kelsey examine the elements, observe what happened as a result of her actions, and after a few moments I heard an audible gasp from her as she correctly deduced the solution to the puzzle, and watched with great satisfaction as she proceeded to execute her solution.

Success. I can design a puzzle using these systems! It'll be interesting to see what the other testers think, as they won't have the bias of having tested the game earlier and having familiarity with it that Kelsey has.

Programming

Most of this week was spent getting the prototype ready for a few more folks to take a look and give me feedback, and that involved a lot of cleaning up things I had built in a rush, putting in some more feedback for when players try to do things, connecting a couple of things I had been building in isolation together. I need to build a few more testing tools for myself, because testing is going to be very tedious until I do, even with a very short little snippet of a game like this. Adding in the inventory functions made me realise that I need to adjust some of my default interaction handling in my switch functions, but it's trivial to make that change. Mostly, though, I need to make sure I'm writing down what I need to do on my todo list the moment I think of it, because the amount of times I thought "I must fix that", then got distracted with fixing something else and forgot about it is amusing and a little annoying. In any case, I have no doubt that my test feedback will contain funny bugs. I certainly found a few myself!

Design

I have been playing lots of puzzle and narrative style games lately, just to refresh my memory on what I aspire to design towards and what I hope to avoid. It's interesting to dig into really puzzle forward games like The Witness and The Talos Principle again, and also more system based things, more narrative based things, and try to work out where I want to sit. Ultimately my goal is to make a reactive world, but by that I don't necessarily means a world that will judge you based on your decisions, or remember your choices - mostly I just want players to be able to try things and for those things to work, even if it might not suit a specific puzzle. I think of it a bit like The Incredible Machine - the balls still bounce, even if they don't land on the thing that will make them bounce into the right bin.

Replaying Eric the Unready this week has been particularly fun. I never got far in it when I tried playing it years ago, although I did think it was very charming, and I love Legend games in general. What I am really enjoying on a replay of it is how the game allows you to goof off regularly and gives you fun responses for it. If Eric the Unready has a puzzle that involves showing your ass to someone, you can bet that the game will allow you to show your ass to everybody, and often give you fun consequences.*

I also have been finding out how I want to handle dialogue in the game, and it might end up just being slightly differently to how a lot of my peers do it. I don't have anything innovative or noteworthy planned, I've just been noticing a few patterns about how conversations in games leave me feeling lately, and what I think I'd like to avoid.

Summary

With the prototype build sent out, I feel a little more at ease than I did last week. It's always a little odd waiting for feedback from testers, but I am actually quite calm about it. The nice thing about testing on such a small prototype is that I know that I haven't wasted too much time on an idea if everybody hates it, and I haven't designed too much game around it if people think that it could do with a fundamental change. Of course, it's hard to foresee anything yet, so I will get back to playing Eric the Unready, and deal with all of that stuff next week. Thanks for reading!

*Yes, of course there's a puzzle in Eric the Unready that involves you showing your ass to someone.

Devlog 7 - Late to the Party

Some of the books I've read/plan to reread as part of gathering inspiration for this game

As work on the project continues, I am still probably spending a few too many hours figuring things out rather than just building, but the results of this week's Monday morning playtest were a success - the thing I thought would be annoying did, indeed, turn out to be annoying, and so I dove in and fixed that as my first task for the week, and then started working on the next room of the game. Everything is solid enough now that I believed I could get the whole next room playable and have that ready as the subject for next week's Monday morning playtest. I did accomplish this, as well as allowing myself some nice tinkering time. AGS 4.0 is proving itself most amenable to working with my ideas once again.

Writing

I didn't actually do much writing this week, but I did go and gather up some of the books I've been planning to read & re-read as grist for the mill of inspiration. I'm in the rather lovely position where many of the most inspiring books I've read came into my life after the last time I wrote a game, and so I have a wealth of untapped inspiration bouncing around my mind. With the intensity of juggling a range of things I haven't made any time for reading in the last couple of months, but that's changing now, and I'm currently working my way through M. John Harrison's Viriconium series. I've loved Harrison's writing style ever since I read Light, and I knew Viriconium would have a setting that suited the world I'm building here a little more closely, so it's a delight to dig in to this. Especially after making it through The Pastel City which pretends to be a very standard Sword & Sorcery novel with a nicer vocabulary for the first 95% of the thing and then turns into a proper Harrison novel.

I still can't find my old thesaurus, and boy do I need it. I was directed to Power Thesaurus by Nic Tringali and it's lovely, but I really do like to be away from the screen sometimes.

Programming

A nice side effect of lurking the forums and reading people's technical suggestions this week was that I learned about the function late_repeatedly_execute_always which seems to have been added since I last used AGS. This is a wonderful feature and allows me to be much more specific about when things happen in the order of operations. Within two days of learning about it I had already used it to get a couple of things done that would have needed really annoying workarounds otherwise. What a great feature, that I am quite late to the party in finding out about.

Another thing on my list is to relearn how to use drawing surfaces and dynamic sprites effectively. This can be a bit of a rabbit hole, so I'm putting re-learning how to do that sort of thing on my future todo list, once the more gameplay important stuff is done. It's also quite possible that what I have in mind won't be very performant in AGS, and it would be very funny but not very wise to build a 2D point & click adventure game that runs slowly. It's a little frustrating to be so out of touch with this stuff, but I know I can learn it all again, eventually.

In implementing the game's second area I found an issue with how I designed one of my systems, and I built a workaround that makes it work correctly, but it's an annoying workaround and I hope to soon be competent enough at code logic to not need it anymore. For now, it works, and I can keep building the game, and it will probably never get in my way, but it's extremely inelegant and it would be nice to have it fixed properly.

Art

This week saw me paint a single scene up, but it was a scene based around a gameplay idea that I thought would be challenging to sell effectively in AGS with consistent visuals. It was nice to see it working properly after all the elements come together - hopefully the illusion works as well to everybody else's eyes as it does to my own. Non AGS developers will probably think it's a fun, atmospheric scene. AGS developers will probably be annoyed that I got it working once they see it. Except Ivan who will smirk and say "of course you did this :')"

I had to, Ivan. You know this.

Summary

Yes, it's taking longer than I would like. Ugh, weekly update seven and I've only just put the second proper room in the game. I only put the first inventory item in today, and there's not a single dialogue tree yet. What kind of adventure game are you even making!? Oh gods it's not edutainment is it?!?!* 

It's interesting how much longer "Making an adventure game with some slightly more complex mechanics in AGS" takes than "Making an adventure game in AGS". That said, the bulk of that time was getting the systems ready for building the game with, and it was very important to me. I am happy to be making steady progress on my todo lists, though, checking items off every single day, and I have a strong foundation† built now.

Next week I will be putting the final piece of gameplay into the opening section and then tidying some things up, adding some extra animations, worldbuilding text and things, and then I think it's time to show it to people. I'm not sure if I can get it into the state I wanted it to be before showing everybody, but it will be close enough, and there's no point trying to get it perfect before I know how well the core works. Wish me luck!

*it's not edutainment, any learning you do while playing this game will be your own fault, unless I accidentally make it a bloody allegory, please god don't let me make it a bloody allegory I respect my players intelligence too much for that surely

†"strong foundation" says the guy in the same blog post that he expressed his frustration at having to use a terrible workaround for a stupid problem he himself created, nice