Category: Game Development

In my last report, I talked about my plans for creating and releasing games for free as Freshly Squeezed Entertainment. Toy Factory Fixer is my first Freshly Squeezed Project.

Creating the Project

Historically, I’ve created new projects by using the code of older projects, removing the game-specific code, art, and sound so I can start with a clean but strong base. This project was no exception, but I found that it took me quite a bit of work to take Toytles: Leaf Raking‘s source and remove all things toytles-related.

I made a note to myself that if I am going to be doing this reuse regularly, I need to make it easier by separating the generic code from the game-specific code.

During One Game Per Month in 2013, I did do something like that, but at the time I just deleted one file because I threw all the game-specific code into it. It’s not maintainable, and I know, because Toytles: Leaf Raking started life like that before I started splitting out to make it easier to work with, but for a one month project that I wasn’t intending to return to, it worked fine.

So I want to do something similar by setting up a separate game-specific directory for game-specific code, so that way I just delete that directory’s contents and have a new project ready to go.

Anyway, once I had the new project building and running, all it had was a main menu on a blank title screen. I created a quick button, and I updated some of my generic code to render buttons with an arbitrary color, and here’s the result:

I know the menu isn’t exciting, but much like my One Game Per Month games, I want the main menu screen to be fairly standard and easy for me to build. I am already mimicking what Toytles: Leaf Raking does in terms of which buttons are available and what happens when you press them. I am hoping that aside from swapping out the game’s title and background art, perhaps even the button art, the menu requires no work to reuse for future projects.

I realized that I now have a project to work on, but I didn’t put together a a plan to work on it yet. I know some people like to use simple TODO items in a list, but I actually find it helpful to have a spreadsheet tracking not only my backlog of features, ideas, and defects, but also what I plan to work on in a given week. I think even for a small project, and maybe especially for a small project, having a project plan with a more robust sense of what I am doing and when I plan to do it. It helps to keep me from working too long on one aspect of the project and reminds me that I want to ship a working project.

If you’re interested in reading how I do it, I documented how I go about creating my game development project plans back in 2016. I do mostly the same thing today, although I found it easier to not split up the user story across multiple cells. Copying a single cell and putting it into my sprint plan is easier than trying to take multiple cells and adding the text from the column headings so it makes a complete sentence. Perhaps it might be easier still to have the cell get populated based on a user story ID so I don’t have to manually copy the text, but it’s not too big of a pain for me to worry about fixing.

So now I have a simple project plan with a simple backlog that I expect to grow as I work on the project and think of ideas or identify work that needs to be done.

Yet it’s a plan that is detailed enough to keep me focused on getting a shippable game as quickly as possible.

What’s Next?

One thing I didn’t anticipate that I should have is that the holidays are here, and I might have less than the 5 hours of week I average on game development due to working on house projects, doing Christmas shopping online, and making sure our address book is up-to-date so we know where to send our annual Christmas card.

So while my goal is to get the game out before Christmas, it is entirely possible that I won’t find myself with nearly as much time to work on it as I’ll need to do so. I know that at least the App Store is saying that they won’t review games around Christmas, so there’s a bit of a deadline if I want it out in time.

But this project is also a good first attempt to see how long it will take me to get a brand new game design into the hands of players. Some of my One Game Per Month games only took me a handful of hours to put together, so perhaps I’ll find that this game will come together much more quickly than I anticipate.

But I am also figuring out a number of things, such as what resolution should the game run at “natively” or how big should the factory floor be in terms of tiles or how the HUD and interface should look. It should be fun. B-)

Thanks for reading!

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed 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!

After the release of Toytles: Leaf Raking v1.4.5 last week, I decided to take a break from creating Personality Injection updates so I could work on something else.

I’ve been working on Toytles: Leaf Raking for a few years now, even if you don’t count the period of time when it was on hold while I was focused on a contract game project.

But I have ideas for other games that encourage curiosity and support creativity, and I’d like to start exploring these ideas through the creation of playable prototypes that I will give away for free. These free and quickly put together games will fall under the designation of Freshly Squeezed Entertainment.

Freshly Squeezed Entertainment

Now, to be clear, I do not intend to churn out unplayable junk. Each Freshly Squeezed game will be released as a perfectly playable game. It might not have all of the bells and whistles, but it won’t be broken and it will provide a complete entertaining experience.

The idea behind giving away free games is that I want my games to have as little friction finding their audience as possible, and if enough demand exists for a particular game, perhaps I will create a “deluxe” version for sale. In other words, rather than guess at what random strangers might want based on trends and fads, I’m trying to find and get faster feedback from the people who would be interested in playing the kinds of games I am creating.

My first new project in the Freshly Squeezed line of games is currently titled Toy Factory Fixer.

I spent a little over 3 hours over a few days coming up with ideas, but here’s the premise:

The toy factory had an accident after one of the worker elves tried to automate the assembly of toys.

Now all of the toys are put together wrong, and the shipping deadline is arriving quickly!

You need to put the toys together correctly in time for them to be delivered.

The worker elf implies where this game takes place. Originally, I had planned to make it a Santa’s Workshop game, with the deadline being Christmas Eve. When I explained this project to one of my nieces, she objected. She told me that making it a holiday-themed game might needlessly limit its appeal. She suggested that I instead add holiday-themed elements to the game, but keep the game more evergreen.

She’s 9. And she is probably right.

Ok, so that’s the premise. What’s the game play like?

I spent time trying to explore options. My goal for the player experience was to have the player make strategic choices for how they go about repairing toys.

I didn’t want it to be in real-time. I wanted the game to be less about reaction time and more about thinking and decision-making.

I found myself imagining a factory, with elves working at conveyor belts. I liked the idea of them taking apart bad toys to get toy parts, and then using those parts to put together good toys, and trying to do so before time ran out.

Of course, since it is supposed to be a game, I then started to think about what obstacles that prevent the toys from being separated and put back together too easily?

Here is a list I came up with:

• Time or turns are limited
• Inventory has a maximum capacity
• Factory floor has a limited number of spaces that can be taken up by toys
• Materials such as thread, screws, glue, etc need to be obtained first somehow (perhaps by permanently destroying a toy?)
• Workers must be in correct place to do the work
• Machines must be in the correct configuration to do the work
• There are a limited number of toys to work on at one time
• Toys are work $X and you need to ship $Y worth of toys to succeed
• A machine does multiple types of jobs, but must do them all at once, and since space is at a premium, sometimes toys aren’t where you want them to be

That last one really intrigued and excited me, and I might keep that idea in my back pocket for a future game.

I liked the idea of multiple types of workers. Originally I thought it would be good if each worker was a specialist who could only do one job, but then I liked the idea that they can do any job, and some types of workers can do some jobs better while doing worse at other jobs.

So for example, a Ripper can tear apart stuffed animals in 1 turn but take 3 turns to put a toy together. Meanwhile, a Sewer takes 3 turns to separate stuffed animals but takes only 1 turn to put them together. And presumably there would be an average worker who takes only 2 turns to do everything.

And perhaps there are variations of workers, and they are more effective doing a certain type of job with certain toys than others. So the Ripper is great with ripping apart stuffed animals, but the Cutter is great with cutting apart wooden toys.

I recognized that I was in the “anything and everything is possible” phase, and I wanted to quickly get to something more solid in terms of rules and game play.

I imagined the assembly line acting as a path for creeps/toys to traverse in a Tower Defense game, and the workers would be placed along the conveyor belts to work at stations, grabbing toys as they move down the line and placing toys down to be deposited into a shipping container at the end.

But imagining hides a lot of details, so I started prototyping the game on paper to get a sense for how the game might feel:

Originally I tried to use some abstract wooden circles, stars, and hearts to represent toy parts, but I found it difficult to match them, so I cut up some index cards and drew some pictures. If you’re wondering, the rocking horse is supposed to be a horse top and rocker bottom. My daughter called it a banana. Whatever. It’s a paper prototype. The fidelity doesn’t have to be that high.

I put together a small conveyor belt level, and then tried playing the game by pretending I was hitting the Play button at the bottom to advance one turn, which would produce a toy from the dispenser. Each turn, the toy advanced one square along the conveyor belt, and it eventually advances to the shipping box. I still haven’t figured out what happens if a bad toy makes it into the shipping box, but perhaps a penalty occurs.

I then assigned a worker, and then tried multiple workers, and realized I couldn’t wait until a computer could automate this work for me. Advancing toys down an assembly line, knowing what state a particular worker is in, and trying to figure out the details of mechanics such as what could possibly happen in a single turn of the game is a lot to juggle.

But I did love the basic spine of the game I had put together: toys move down the conveyor belt to a shipping box, and the player assigns workers along the conveyor belts to manipulate and fix the toys before they get there. There are a lot of details to work out, such as whether the workers are autonomous or need to be activated manually, but the basics are pretty much there.

I then decided that perhaps workers should be hired, so it costs money, which means you need some money to start with.

After hiring a worker for 1 Money, you can place them anywhere along the conveyor belt. I wasn’t sure if the worker should just influence the square in front of them or a range of squares adjacent to that square as well. I started picturing that famous “I Love Lucy” episode…

I very quickly needed to figure out what happens to the separated toy parts. Do they disappear automatically into inventory? Does the worker hold them? Does a worker need to run around the level, collecting toy parts from other workers? For now, I just wanted them to disappear into your inventory, since that seemed simpler.

What’s Next?

Toy Factory Fixer is just a paper prototype right now, so I’m looking forward to getting it into digital form soon.

I want to put together a very lightweight project plan, write down all of the ideas I’m having, and then prioritize them so I can get a playable game as quickly as possible.

Ideally, I’d like to get this game out before Christmas, but I don’t know how long it will take me. I estimate that in a Ludum Dare 48 hour game jam, I might spend only about 24 actual hours working due to sleeping, eating, and taking frequent breaks. And if I do 5 hours of game development a week on average, it means that this game is probably behind schedule and won’t be done.

But maybe it won’t take me 24 hours, and I can get something releasable much earlier. We’ll see.

One final thought: I invited my son to talk about this game’s design as it evolves, as I wanted him to get a sense of what the work of game design can look like. He’s been enthusiastic (to the point that I had to tell him that he should wait until I had finished talking about my idea before interrupting me with his own), and it has been some of the best quality time we’ve spent together.

Thanks for reading! I am really excited about this project and the Freshly Squeezed Entertainment line of games it will introduce.

—

Want to learn when I release updates to Toytles: Leaf Raking or about future Freshly Squeezed 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.

Get it at the Toytles: Leaf Raking page.

In the previous sprint report, I fixed defects I introduced due to the new screen transitions, and I started working on new dialogue.

Sprint 22: Time-based dialogue

• Story progression when finishing a yard (unique monthly client dialogue w/ difference between clear/uncleared yards

I did 9.75 hours of game development last week, which is almost double my average but quite a bit less than I was hoping to be able to put in considering I took a few days off from the day job. Then again, it was a holiday weekend, and I ended up running errands and doing things around the house. Oh, and someone was digging outside and cut the phone line to our house, and so we’ve been without Internet since the day before Thanksgiving. Someone should come out today, but I don’t know how big of a job it will be to replace the buried phone line or how long we’ll be without Internet access.

Most of the time was spent writing new dialogue for each of the neighbors. It was fun discovering what makes each of the game’s neighbors tick. And I know the new dialogue is just able to hint at their complex lives.

When the dialogue I planned to write was finished, and I was playing the game and testing things out, I found that in practice it was actually much more difficult to talk to the neighbors after you’ve raked their yards due to not being able to visit them after 7:00pm.

On the one hand, it means that I probably do not need to worry about adding too much more new dialogue because it will be unlikely to be seen by players. On the other hand, perhaps there are things I can do to allow the player to have an easier time to do things in-game as well as visit with neighbors if I either had the player’s character return from school a bit earlier or allow visits with neighbors later, or perhaps both.

My niece suggested 8:00pm instead of 7:00pm for the latest time you can visit a neighbor, and she also suggested that 3:00pm is too late to return from school. I’ll need to experiment to see what extra time in a day does to the game’s economy.

In the meantime, I found that once I started testing the game on an iPhone, the game crashed quite frequently. It turned out that during the new transitions, on my main development machine and on Android nothing would go wrong somehow, but on iOS it turned out that a deleted object was being used when it shouldn’t, which indicates that it was probably also being used and waiting to blow up on someone’s Android phone or tablet. So I fixed the issue, and now it is better across both platforms.

I thought there was another crash bug, and I spent quite a bit of time trying to figure out if there was another place where I was using deleted memory. In the end, it turned out to be a weird issue with Xcode’s debugger, and if I ran the game on its own, it worked just fine.

So expect a new release of Toytles: Leaf Raking soon.

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.

Get it at the Toytles: Leaf Raking page.

In last week’s sprint report, I talked about finishing up screen transitions and fixing some defects. I finally started to work on adding the new dialogue.

Sprint 21: Time-based dialogue

• Story progression when finishing a yard (unique monthly client dialogue w/ difference between clear/uncleared yards

I did 6.5 hours of game development this past week, and while a significant amount of it was geared towards the new dialogue functionality, I did find I had accidentally introduced a major, game-breaking defect, so I also spent time investigating and fixing it.

The Defect

Originally, the game had no screen transitions. When I switched from one screen to the next, it was immediate, which meant that I could save the state of the game immediately whenever the player made a decision.

For example, if you moved from one neighborhood to another, it took 10 in-game minutes, and that was a decision I didn’t want you to pretend didn’t happen by shutting down the game and then reloading it.

Similarly, choosing to go to sleep to end your day is a decision that gets saved.

However, once I added transitions, I had to delay changing the screen you see until after the fade out, then I would fade the new screen in.

The defect got introduced because I shouldn’t save until the screen change occurs, but it saved before the fade out, which meant that the old screen was saved.

If you kept playing the game, it would be no big deal. The game works just fine.

But if you close the app, then when you reload it, you could be on the wrong screen.

For a non-game-breaking problem, you could visit the kitchen to talk to your parents. If you close the game and reload your save, you would still be in the front foyer and not in the kitchen, and yet the dialogue from your parents would still be on screen. This issue is no big deal because there is no in-game impact from seeing dialogue in the wrong part of the house.

However, what IS a big deal is going to sleep at the end of the day. The game saves while you are on the sleep screen, then on normal weekdays you go to school, then at 3:00pm you in the front foyer. If you shut down the game and reload it, it would reload the game at 3:00pm but on the sleep screen. And the entire point of the sleep screen is that you don’t do anything but wait for time to pass until you wake up. But since you aren’t supposed to be on the sleep screen, time isn’t passing.

My personal favorite manifestation of this defect was discovering that if you saved up $1000 and went to the store, purchased the Ultimate Item(tm), and shut down the game while the screen was transitioning to the You Won screen, then when you reload the game, you would be back in the store, only without $1000. The game saved the fact that you spent it.

Interestingly, the game also saved the fact that you bought the Ultimate Item(tm), but it won’t register that you’ve won. You have to attempt to purchase any item in the store for the code that checks for the victory condition to run. So this specific problem isn’t technically game-breaking, but it would probably have upset players when they thought the game cheated them out of the game-winning money which they spent the entire time earning.

I fixed these issues by ensuring that anytime there is a screen transition that the save occurs only after the transition has ended.

The Dialogue

After taking the detour to fix the fairly major defect I introduced with screen transitions, I finally got back to writing dialogue. I’m actually pretty excited about the way my dialogue system is coming together.

I finished adding new dialogue tags for determining which month it is based on the current date as well as tags for yards being clear or yards being not clear.

In code, they are the following new tags:

    IS_SEPTEMBER_TAG,
    IS_OCTOBER_TAG,
    IS_NOVEMBER_TAG,                         
    IS_YARD_CLEAR_TAG,
    IS_YARD_NOT_CLEAR_TAG 

As a reminder, the way the tags are used is in two parts. First, I get a list of possible tags based on the current game state. So if Mr. Cardinal is my client and I am in his yard on the day before Thanksgiving and his yard has any leaves covering it, then the tags that would be generated by the current game state are IS_CLIENT_TAG, IS_NOVEMBER_TAG, and IS_YARD_NOT_CLEAR_TAG.

The second part is that each piece of dialogue in the game is tagged, and so I can now tailor the messages that any neighbor says to you based on a number of tags. So I can write some dialogue and tag it with all three of the above tags, and in the game when you visit him, the game state-based tags will match all of the tags for that piece of dialogue, and so he’ll say something unique and topical:

And once you rake all of the leaves in his yard, the IS_YARD_CLEAR_TAG would need to match a different piece of dialogue, which furthers the story of Mr. Cardinal being an inventor:

As I said, I’m pretty excited about the possibilities, especially as I add more tags. The combinations of tags, and so the dialogue that matches various combinations, can be endless.

So when can you play it?

I took off a few days from the day job this week, so I expect to put in some time to finish writing all of the dialogue and create the new version of the game for review in the App Store and Google Play.

But I wish I had a release sooner.

I underestimated how much work it would be to write 6 new lines of dialogue (2 x each of the 3 months) for each neighbor. I didn’t want to make a new release until I had new dialogue in the game, as I didn’t think screen transitions alone would make for a compelling update.

I think in hindsight I realize that I should have worked on the new dialogue first so that there was always potential to release a new version of the game.

But hey, it’s a mistake I can learn from. Next time I plan a release, I will make sure that I work on the must-haves first rather than last.

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.

Get it at the Toytles: Leaf Raking page.

Last week, I reported that I quickly prototyped a fade-out/fade-in screen transition to get a sense of how it felt, then worked on the production version once I determined that I liked it.

Sprint 20: Screen transitions & time-based dialogue

• Create screen transitions when entering/leaving yard
• Story progression when finishing a yard (unique monthly client dialogue w/ difference between clear/uncleared yards
• Defect: Visiting a neighbor causes unsightly refresh
• Defect: Reloading from the store loads a store with no items and no visit button.

I did 6.25 hours of game development last week. I finished the scene transition fades quickly enough, and then I fixed a couple of defects I found.

With the transitions in place, it is clear that the yard screen gets recreated each time you visit your neighbor. It has not been an issue, and it doesn’t affect the play of the game, but the unnecessary redraw is now distracting. So I fixed it.

More importantly, however, was finding out that there was a problem with reloading the game if you were in the store. Normally the game reloads and regenerates the screen you were on, but if you exit the game by way of the main menu, it behaved differently than if you merely shut down the app.

The problem was that the game code didn’t anticipate that you would ever be in the store on loading a game. I think the idea at the time was that it was difficult to save the game for whatever reason, plus it wasn’t strictly required. If you exited the game while in the store, the last automatically saved data would put you in the same neighborhood as the store, so when you load the game, you’d just enter the store. No in-game impact occurs.

But what I discovered was that if you reloaded the game in the store, the store screen would be empty. So you’d have a “Leave” button, but it would otherwise have no store items. It was eerily empty. If you left the store, it would transition you back to Midtown, which meant you lost 10 minutes of game time due to the neighborhood movement.

Since that impacted you as the player negatively, I needed to fix it. If you’re interested in some of the details, I initially had a false start where I tried to prevent the game from saving if you exited to the main menu, which seemed to work.

But as I tried a bunch of things, I eventually found out that it broke the game even worse: If you exited to the main menu while sleeping, on reload, you would perpetually sleep. The game didn’t load something properly and so while time didn’t advance, it offered no menu options, so you were forever sleeping at 3:00pm.

So I reverted that changed, and instead I decided to go with it and had the game generate the store screen properly. The reason I didn’t do this at first was because I was convinced that the save game data had the wrong data for the store, but it turned out that I was wrong.

The last thing I worked on was finally getting started on dialogue based on which month it was. I started with September, and it’s going smoothly.

The other piece was changing the dialogue based on whether or not the yard is clear. So the end result will be that your neighbor with say one thing before you rake their yard and another thing entirely after you do so.

Eventually, I want each day to offer multiple conversation paths based on who your other clients are, what time of day it is, and more. I won’t get there all at once, though, but I can still build incrementally up to it with each release.

But there is no new release yet. It has been over a month since v1.4.4 was released with holiday dialogue. I feel a bit behind schedule, even though I don’t really have a schedule. But expect the next release soon.

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.

Get it at the Toytles: Leaf Raking page.

Last week, I reported that I took a bit of a break due to moving my website.

Sprint 18: Screen transitions & time-based dialogue

• Fix mistakes for Thanksgiving dialogue
• Create screen transitions when moving about town
• Create screen transitions when entering/leaving yard
• Story progression when finishing a yard (unique monthly client dialogue w/ difference between clear/uncleared yards

I did 7.75 hours of game development last week, which is almost 3 hours more than average. All of those extra hours came on the day my household lost Internet access. I decided that it was a forced PTO day for the day job, and I worked on game development for 4 hours.

It felt great to get done in one day what would have taken me an entire week normally.

I fixed a few mistakes in dialogue that I caught after releasing v1.4.4, which were mainly typos or weird visual problems in which text overflowed the box it was supposed to be in. These fixes took almost no time.

But implementing screen transitions between the neighborhoods took up the lion’s share of the time:

Originally, clicking on one of the navigation buttons instantly took you to the neighborhood, but now with the sliding transition, I think it helps to give the player a sense of space in the town.

It might seem subtle, but I think it has a huge impact on the feel of the game. And I am happy that I was able to focus on it instead of spreading the work throughout the week.

Years ago, I was given feedback that the button presses themselves need to give the player feedback, and it is in my backlog list of enhancements. Other backlog items include animations when earning money, changing time, sliding in/out the modal overlays, changing the brightness of the screen (and lights and shadows) based on the time of day, and showing the player’s character on the screen. All in due time.

I did not get to work on the transition between the street-view screen and the yard screen, nor did I work on the new dialogue, but they are what I intend to work on this coming week. You know, assuming the U.S. Presidential Election this week doesn’t result in civil unrest.

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.

Get it at the Toytles: Leaf Raking page.

In the previous sprint report, I finished up holiday dialogue and fixed a few defects.

That was two weeks ago. What happened to last week’s report?

Sprint 17: Holiday-specific dialogue

Two weeks ago, the sprint plan was:

• Write blog post for release
• Write newsletter to announce release
• Fix mistakes for Thanksgiving dialogue

I wrote for 1.75 hours to create a couple of blog posts and a newsletter (want to sign up for it? See below for details!).

And as that third bullet point says, there were some mistakes I carelessly introduced into the game related to Thanksgiving dialogue. Namely, one neighbor’s dialogue is too long and extends outside of the modal overlay, and another neighbor’s dialogue has a typo.

I’m super unhappy about these careless mistakes. I can easily fix them, but it’s kind of annoying to create a new release to address just these issues.

I met Nivia Henry when she presented at dsmAgile 2019, and she pointed out something that helped me feel better about these mistakes:

Don’t feel too badly; 100% bug free software means you took too long to release

— Nivia Sedai, Amyrlin Seat, says Defund the Police (@Lanooba) October 14, 2020

It definitely helped me to stop worrying about them. They’ll get fixed for the next release.

Oh, and I spent 0 hours working on game development.

GBGames moved. I hope you don’t notice.

My time instead was focused on moving my website to a new webhost.

Around 2004, I was a regular on the Indie Gamer forums and spoke with other indies, aspiring or established. I found myself perusing the classifieds section and saw an ad for shared webhosting. There was a discount code, and I signed up, getting my site off of the free web hosting I was using before.

The company eventually changed its name from LizardSoft to Tilted Pixel, and I’ve been with them ever since. The company has long been focused on being a full-service web development shop, but I was grandfathered into the basic shared hosting plan.

I was always impressed that the few times I had a support request almost always went through the owner, Matt Inglot.

Well, in August, he sent me an email saying that they were upgrading servers and were no longer going to be able to offer support for email addresses or WordPress, both of which I depend on. So, after all this time, I decided to find a new host.

And I knew I wanted to focus on this move since, you know, I’m not a web master by trade, so I did no game development. I didn’t track exactly how much time it took me, but I was pleasantly surprised that the move went very smoothly.

Not that smoothly

At least…at first. I was in the middle of writing this post and expected to write it for last week, but the new webhost I chose was an inexpensive option that advertised itself as being so cheap due to not handling silly support issues. The idea is that you should know what you’re doing, and in exchange, they won’t charge a bunch. If there is a legitimate support request, they’ll deal with it, but otherwise, you’re on your own.

I was fine with this arrangement, except I lost access to my website for 12 hours. Apparently it was still up, but my own home IP address was no longer able to access it.

And of course, no one replied to my support requests during that time, and I didn’t know if anyone would.

I was frustrated because I was completely ready to provide my own tech support, but there was very little I could do on my own in this situation. I couldn’t tolerate this level of service going forward.

So I reverted my website back to my old host and told Matt Inglot about my renewed sense of gratitude for the amazing and personal support he provided.

I have no hard feelings towards the new host. I got what I paid for, and I am glad the problem manifested so early.

I have since found a new host, one that provides support. It’s a bit more expensive than what I was paying before, but not by much.

And I had practice, so setting up the new site on the new new webhost didn’t take me long.

I was easily able to update the WordPress theme and setup plugins, import content, and upload images and other media. I had to manually tweak a few things, and I made a note of what they were for next time.

I’d love to be able to make my website a one-click deployment instead of a multi-day effort. That way, if a disaster were to happen, I could restore everything immediately.

But one nice thing about the move to the new webhost? I’m starting with an almost clean slate.

No stale plugins. No privacy-invading analytics or ads. The site is way faster, and aside from perhaps one thing that is purposefully different, I think you would otherwise have no idea that the website is on a new host if I didn’t say so here.

If you notice anything that seems off or broken, please let me know, either below in the comments or using the contact form in the About GBGames page.

Er, and the fixes?

I had time to work on game development, but I decided not to. While creating a release isn’t terribly stressful, and I average only about 5 hours a week for game development, it is still nice to take a break.

And rather than wait for me to feel exhausted, I purposefully decided to give myself time to focus on other things. The website move took longer than I wish it had due to the issues I ran into with the 1st new webhost, so I was glad I didn’t try to do too much at a time.

I did spend a little time thinking about the design of a completely different game. More on that one in the next newsletter, I think…

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.

Get it at the Toytles: Leaf Raking page.

Last week, I wrote in my report for sprint 15 that I expected it would only take a couple of hours more to get the rest of the holiday-specific dialogue into the game.

Sprint 16: Holiday-specific dialogue

Last week’s sprint plan was:

• Create holiday-specific dialogue
• Fix holiday text being cut off next to weather window
• Fix time advancing incorrectly when loading a game in a neighborhood other than Midtown.

I did a total of 4 hours of game development, but that includes the time spent creating and testing the Android and iOS releases and uploading them to the app store. I was actually finished with the dialogue after 2 hours of work, as I predicted, and the rest of the time was spent fixing the two defects and creating the releases.

Fixing the text issue was straightforward. I’ve mentioned before that I use JonnyD’s NFont to handle a lot of my text rendering, and I was rendering the text in a box that was too small. I don’t know how long it had been that way, but I modified the box so that the text wrapped around nicely and fit better.

The time issue was similarly straightforward. I don’t know if I introduced this defect when I was moving code around in the last few months, but here’s a summary of what was happening. There are two variables: one is your current neighborhood, and the other is the last neighborhood you were in. Your current neighborhood is saved and loaded. Your last neighborhood is not, and it is just a variable that is used during the game.

The idea is that if you navigated to the neighborhood screen, you either moved there from another neighborhood and should therefore use 10 minutes of time, or you were on a house screen and making your way to the street in the same neighborhood, using no time at all. The game determines which situation you are in by comparing the last neighborhood variable to the current neighborhood variable.

But apparently I forgot to set the last neighborhood variable to the current neighborhood variable after you load a game. So if you start out in a neighborhood other than Midtown, when you visit a neighbor’s house and leave back to the neighborhood view, the last neighborhood (Midtown) and the current neighborhood (not Midtown) do not match, and so time advances. There was another problem: navigating from a different neighborhood to Midtown does not advance time because the last and current neighborhoods are both Midtown, when you were obviously not in Midtown before traveling to Midtown.

The fix is simple: when loading a game, I set the last neighborhood to the value of the current neighborhood that was loaded. Now time advances (or doesn’t) correctly.

Creating the releases was actually the most painless it has been. I don’t have it quite automated yet, but the Android build is pretty much a one-liner script. The iOS build is almost there, except I still have quite a few manual steps after using CMake to create the XCode project, such as adding the Images.xcassets to the project and then specifying that it should handle signing automatically and which team. I am sure these things can be automated, but I haven’t figured it out, and I wonder if Apple will change things yet again and break whatever I do anyway.

I’ll be announcing the new v1.4.4 update tomorrow in my newsletter, so sign up below to get the news as well a curiosity and a free player’s guide.

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.

Get it at the Toytles: Leaf Raking page.

In last week’s report, I said I was almost finished with adding holiday-specific dialogue to the game. I predicted that it would be a matter of a couple of hours at most to finish the work, then I could create a new release and get it published.

Sprint 15: Holiday-specific dialogue

Last week’s sprint plan was:

• Create holiday-specific dialogue
• Fix holiday text being cut off next to weather window

I only worked on game development for 45 minutes last week, a far cry from the 5 hours per week I’ve been aiming for.

As such, while I finished adding dialogue for Halloween, I only barely got started on the next holiday and made no further progress.

Why didn’t I spend more time on the game? The rest of my life had a higher priority on my time.

My parents are celebrating 40 years of marriage, and so I’ve been talking with my sister about last-minute preparations. My wife is celebrating her birthday, so I’ve been finishing up plans for it. And I’ve been working very long hours at the day job, getting on early and staying on late, which means I lose the opportunity to do game development when I normally would and I am sapped of energy after the kids go to bed, which is the next opportunity.

In terms of game development, last week was mostly lost. Which is too bad because the work is straightforward, and I still believe that it will only take a few hours more before I could publish a new update.

One positive thing is that I found a defect in the game while testing out the Halloween dialogue in those 45 minutes I did dedicate to making progress on this project. The defect isn’t the positive thing, but the fact that I found out that it exists is, because I can address it before publishing a release.

It turns out that if you load a save game and are in a neighborhood other than Midtown, which is the default one, then when you go to a neighbor’s yard and leave back to the neighborhood screen, the clock advances 10 minutes. It should only advance 10 minutes if you move from one neighborhood to another.

I suspect that the reason that it is happening is that when I load the game, I don’t set the current neighborhood correctly somewhere, and so when you leave a yard and return the neighborhood screen, the game detects that the neighborhood has changed when it hasn’t.

As far as impact is concerned, it’s not a huge deal…except when it is. In my case, I was visiting neighbors to see if the dialogue was formatted correctly, and I currently need to reload the game when I change it to see if the changes look better. Each time I did, I advanced the clock without realizing it, until it was past the time when visiting neighbors is considered polite. Then I had to reload the game entirely and reset the clock to the correct holiday in order to continue testing.

It was kind of annoying for me as a developer, but I can also see it being a problem for a player. If you saved the game during Mr. Matt’s store opening hours, then discovered that after you loaded you accidentally advanced the time so that the store was closed, it would mean that you can’t you can buy emergency yard bags or a replacement rake until the store is open again.

Time management is a key part of the game, and this defect makes the game a bit unfair to people who try to get to the store at a decent time.

So that defect needs to get fixed before I create the next release as well.

Thanks for reading! Please sign up for the mailing list (see below!) to hear about new Toytes: Leaf Raking releases as they are published, news about the work I am doing, and curiosities that I find interesting about the world.

—

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!