Here’s this week’s progress report for new updates to Toytles: Leaf Raking, my family-friendly leaf-raking business simulation available for iPhones, iPads, and Android devices.

Learn how to get it at the Toytles: Leaf Raking page.

Last week I reported that I finished adding the neighbor status indicators into the game.

All that remained to do was to create a new release for iOS and Android, test it, and publish it.

Sprint 13: Holiday-specific dialogue

Last week’s sprint plan was:

• Create iOS release
• Write blog post announcing release
• Write email announcing release
• Create holiday-specific dialogue

At the end of the previous week, I had created an Android build. I spent the earlier part of this week on creating the iOS build. In both cases, I installed the game on a physical device, then played the game until I was satisfied that things seemed to work more or less fine.

Then once I felt it was ready, I submitted it for review at the respective app stores, and then I published the announcements once they were ready to go live. Read more about it at the Toytles: Leaf Raking v1.4.3 announcement post.

Then I could start working on the current sprint’s actual goal, which was adding dialogue related to the current date of the calendar if it was special somehow.

I ended up not doing much. I worked long hours at the day job due to commitments at both the top of the morning and the late afternoon, which meant I did not work on game development at the times I normally would.

I did only 1.5 hours of game development, most of which was spent on getting the release published. I found that I had effectively taken most of the rest of the week off, even though I hadn’t wanted to. I found myself exhausted and needing to rest each day, and so I listened to my body.

In the future, I think I need to plan and make time for a periodic break instead of letting it happen.

I did finish the week my looking at my code related to dialogue and the calendar. Currently, I have an enum called DialogTag (I’m clearly still struggling with picking either dialogue or dialog, which depending on who you ask are both acceptable in North America. Alternatively I’m using dialog when I should be using dialogue). Each neighbor has a collection of things they say, each of which is tagged based on whether they are clients, ex-clients, prospects, etc.

Now I want to add dialogue that is tagged based on a calendar event. While I could add a tag for each holiday, I’d like to have one tag type for holidays, and then I would have a separate piece of data indicating which one.

There are 6 holidays, but I can create more, such as birthdays for the neighbors. Still, it isn’t like I’ll be adding hundreds of holidays, so it wouldn’t be so bad to hardcode a separate enum value for each holiday.

But then I start thinking about a neighbor getting excited the day before a holiday. Or being sad the day after.

Of course, what this kind of scope creep tells me is that there is still a lot of interpretation for how to handle the immediately work, and I need to remember that I can put something together that works now and slowly change it to do something that works later.

So hardcoded for now.

The other big thing I need to figure out is how to decide which dialogue to show. Up until now, a neighbor can say only one thing based on their status as a client. Since you can’t have a neighbor be both a client and a prospect or an ex-client, there was no choice to make. Only one option filtered out.

With dialogue based on the current date, however, now two options can be available at once. Perhaps clients and prospects should say the holiday-specific dialogue, and ex-clients say their normal ex-client dialogue? Or maybe only happy clients (clients who have no leaves in their yard) say more interesting things? Or perhaps holiday dialogue is said first, then followed by regular dialogue? Or regular dialogue followed by holiday dialogue? Or randomly choose among options, so sometimes a neighbor might talk about a holiday and sometimes they might not?

There’s clearly more I need to think about, but for now, thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

Here’s this week’s progress report for new updates to Toytles: Leaf Raking, my family-friendly leaf-raking business simulation available for iPhones, iPads, and Android devices.

Learn how to get it at the Toytles: Leaf Raking page.

In my previous report, I once again lamented how little capacity I have as a very, very part-time indie game developer.

And yet, I still felt optimistic.

Last week’s sprint plan was:

• Make it clear from the map which neighbors are your clients, ex-clients, and prospects

This week I did 5.75 hours of game development. I had a few false starts, and in the end, I still don’t have the indicators in the game.

I started working on creating an animated sprite, which is basically just a regular sprite but with frames, where the frames have a length of time and an image that should show during that time.

Then I wondered if perhaps there were best practices or at least expected ways it should work, so I did a bit of research, and I remembered that CSS animations are a thing, too.

For a good part of the time, I was feeling fine. I designed and started to implement an animation system that works similarly to how the animation systems in CSS or Godot engine works. That is, if there is a property to change, I can setup “tracks” to change those properties over time. Position, scale, color, sprite image, etc, all of these can be changed independently and simultaneously.

And then I realized: my sprint goal is once again nowhere near done. I was spending a bunch of time creating a generic animation system when these indicators really just need to flip between a few frames and bob up and down.

So after a few hours (which as a reminder is over the course of half of the week) I stopped working on the generic animation player, and I went back to my animated sprite widget.

And now I’m at the point in which I am creating an animated sprite as an indicator if a neighbor is a client. That is, I am actually starting on the work that will actually get the sprint goals accomplished.

I can see a way to do all of the above in a hacky way. That is, I’m sure I could have quickly coded up what I needed to show indicators if I didn’t care about trying to ensure the code is supportable and maintainable in the future. And after three weeks of not getting the indicators into the game, it sure feels like I made the wrong choice.

Others might argue I made the wrong choice earlier by not using an existing game engine instead of writing all of the code myself.

But I need to remember that the last three weeks of amounted to a total of about 17 or 18 hours of work. That’s not a lot of time in the grand scheme of things, especially when those hours are broken up across entire days, making it difficult to keep focused.

And I also need to remember that I want to be able to support and maintain this project in the future.

One thing I’ve learned is that the game framework code library I’ve created and updated and modified over the last 10 years still has some inconsistencies, and so working to add animation on top of the existing sprite and widget code was more confusing than it needed to be.

For example, widgets are objects that I create once and then reuse across update/draw cycles. Widgets can not only be drawn, but they can also be made interactive/clickable.

IWidget is the base class that not only provides the interface for widgets but also handles drawing child widgets. That is, any derived widget automatically gets the ability to add and render child widgets, and all a derived widget needs to provide is a way to draw itself.

IWidget provides a setOnClick() function which allows you to specify the rectangle in which it should detect a click (usually the size of the widget) as well as what option/command should occur when a click occurs.

How does it know that you clicked it? Widgets have an update() function that takes the input (mouse button presses and mouse location). I have a ButtonControl class which IWidget takes advantage of.

What does this have to do with animation? Well, how do I make sure an animated sprite changes over time? I’d use a different update() function that takes a deltaTime in milliseconds.

So throughout GBLib, which is what I call my library of general code for all of my GBGames projects, I have some update() functions that handle input and some update() functions that handle the change in time. And IWidget provides an update() that handles input, and now that I have an AnimatedWidget that derives from IWidget, I also want an update() that handles the change in time.

And while most programming languages let me have two separate update() functions that take two different sets of arguments, I think it would be confusing and is just one example of the kind of lack of cohesive design to GBLib that makes me want to sit down and figure out what I actually want this code to look like.

But it doesn’t mean I’m going to do it just yet. I’m focusing on getting the indicators in with an AnimatedWidget, and if it means it is a bit awkward, then it is a bit awkward. I can fix awkward later, especially since I have an automated test suite to support the work.

And I can eventually make a more generic animation system. The optimistic developer in me was convinced I only needed a few more hours to finish the work I started the week on.

But the producer/delivery lead in me also recognized that after a few weeks, it would be nice if I had something to show for it. I thought I was working on a compromise between quick & dirty and generic & clean, but I realized I was still doing too much for future needs.

So I’m doing the simpler work now in order to get a new release out, and I can worry about generalizing the code when I have something that needs generalizing.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!

Last week’s report hinted that I’d be working on making it easier to see which neighbors are your clients as you travel the neighborhood.

Sprint 9: Visualizing client status

Last week’s sprint plan was:

• Make it clear from the map which neighbors are your clients, ex-clients, and prospects

I put in a total of 6 hours of development. I’m actually feeling relatively good about that number because out of all of the weeks in the last two months, it ranks 4th in terms of hours of effort per week. And as a very, very part-time indie game developer, roughly 5 hours a week is what I aim for.

I spent a good part of that time using pen and paper to figure out what my indicators should look like. I even created some mock-ups and posted them on Twitter and in the local chapter of the IGDA’s Slack to get feedback.

I created a speech bubble with the idea that it alone will tell you if you are looking at a client or not. What’s inside the speech bubble can indicate if the client is worried. Prospects won’t have any indicator.

In the following image:

• Mrs. Smith is a client
• Isabella and Alberto are both unhappy/worried clients
• Marsha is an ex-client

You can ignore Brian’s empty speech bubble, as it was just a placeholder, although I got feedback that it was confusing, so…good then.

I also got feedback from the image above that the exclamation point looks like someone is trying to get your attention to give you a quest. The angry scribble is playful while communicating that someone is upset, but it isn’t clear why.

I was worried that the “no entry” sign makes it look like you can’t visit Marsha, when in fact you can. My wife pointed out, “Why would your ex-client want to talk to you anyway?” which got me thinking about how much work I want to put into allowing you to visit ex-clients.

Maybe one of the consequences of losing a client is that you cut off access to all sorts of witty writing by yours truly?

I created a new iteration based on the above feedback:

• Mrs. Smith is a client
• Isabella is an unhappy/worried client
• Alberto is a happy client (no need to rake the yard at the moment)
• Brian and Marsha are ex-clients

I don’t like Brian’s speech bubble because it goes completely against the idea that a speech bubble is a quick visual indicator that you have a client.

But the smaller blinking “no entry” over a rake symbol should make it clearer that the raking is what is prohibited, not necessarily visiting.

At least, I hope so. I realized surprisingly late that feedback from mockups only gets me so far, and that I’ll need to observe playtesters to see if it actually works the way I want it to work.

The other feedback I got was that the happy turtle face I created to indicate a happy client looks more like a frog, which is confusing in a game about turtles.

And when I look at it…yeah, it does look like a frog.

So I spent some time trying to make it look less frog-like and more turtle-like, getting feedback from local game developers as I went:

I tried making the beak more obvious:

I doodled a bit and experimented with a cartoony emoji-like face:

An artist presented a sketch with the eyes a bit farther apart and with some nostrils, which looked waaaay better than this initial version:

So I doodled a bit more and came up with this:

I was told that the eyes looked sleepy, so I took away the lids and thinned the smile, creating what I think looks like a pretty decent smiley turtle face:

Some of the images above were pictures I took with my phone because it was easier to do so to share on Slack, which is why they are such poor quality.

The last part of the week was spent moving the neighborhood rendering code out into its own files to make it easier for me to work with to add the indicators. I haven’t finished that work yet, which means so far last week was spent designing, iterating, and getting feedback on the indicators but no indicators are implemented yet.

Next sprint: actually implementing it

I expect it won’t take me long to actually get the indicators working in the game. I think the bulk of my time this coming week will be playing the game and getting a feel for how the indicators change the experience. Do they make it easier to understand who your clients are and which ones need urgent attention when you are looking at any given neighborhood screen?

Worries I still have:

• Should prospects have an indicator? Will people ignore them if there is no indicator?
• Will people avoid ex-clients because the indicator makes it look like they can’t or shouldn’t visit? Should I, in fact, make ex-clients less interesting (or beneficial) to visit as a natural consequence of losing a client?
• Does the happy turtle face still look too frog-like?

Hopefully I’ll get some answers in the coming week.

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future games I am creating? Sign up for the GBGames Curiosities newsletter, and get the 24-page, full color PDF of the Toytles: Leaf Raking Player’s Guide for free!