Categories
Games Marketing/Business Politics/Government

Announcing the Post Election Stress Sale

There was a lot of anxiety before the election, and there are a lot of feelings to process now that it is over.

We know that there is a lot of work to do, a lot of organizing and community-building, and a lot of support to provide in the coming weeks, months, and years.

For now, in case you are looking for something to occupy your mind for a little while, I’m holding a sale on my leaf-raking business simulation game, Toytles: Leaf Raking.

Toytles: Leaf Raking

During the 90 days before winter, you’ll:

  • Seek out neighbors who need your services and turn them into paying clients.
  • Make key purchasing decisions, such as which types of rakes to buy and how many yard bags to keep in your inventory.
  • Balance your energy and your time as you seek to keep your clients happy without overextending yourself.
  • Visit the kitchen to ask your parents for their advice and wisdom.
  • Learn about personal responsibility and the importance of keeping your promises.

If you are a fan of older games like Lemonade Stand and other small business sims, or a fan of turtles, you can get it today at 50% off.

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Still Designing/Planning

In my last report, I said I had started working on my next Freshly Squeezed Entertainment project, which will focus on clowns.

I find myself struggling to strike a balance between trying to capture as much of the design and scope upfront as possible and accepting that I will never get it all upfront and so can make decisions and updates as the project continues and I learn more about it while building it.

I was hoping to have captured enough to get a head start in October, but now that the first full week of November is starting, I think I’ll start working on implementation.

Basically, I feel confident that the start of this project will be the same no matter what: I’ll be creating a title screen menu and get a basic project up and running (and shutting down).

So I can get started coding, but I still need to figure out the schedule in a lot more detail. It will help me identify what needs to be done, what can’t be done, and what might need to be changed.

Perhaps for future projects the design and schedule planning work should go into the project plan as well. Right now, I’m treating them as separate from the game’s actual development even though they are taking up time and are as much game development as any task I would have.

For now, here’s another mock-up:

Clown creation mock-up screen for unnamed next project

Thanks for reading, and stay curious!

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Starting a New Game Project

If you recall from last time, I put further development on hold for The Dungeon Under My House, my non-violent, first-person role-playing game and what was supposed to be my second Freshly Squeezed Entertainment project.

Since then? I’ve been working on the design of my next project.

I don’t want to reveal too much yet, as it is still very early and no development has occurred yet. Still, I can say the focus on this next game will be about clowns.

Fun clowns, not the creepy or scary kind.

I love clowns. I loved watching Bozo and Cooky when I was a kid, and I loved seeing the clowns whenever Ringling Bros and Barnum & Bailey Circus came to town.

I have had a soft spot for clowns ever since reading a newspaper article from many years ago that said that there was a clown shortage in the world. And I think clowns get a bad rap because so many people only see them in horror movies or as creepy villains in games anymore.

But real clowns are entertainers, using laughter to create a real impact on society. There’s a rich history to clowning that I’m still digging into as both a fan and as the developer of a game that will feature clowns.

And I find it strange that there is a real lack of games that feature clowns in a good light. My hope with this next project is to improve that situation.

When I worked on my last project, I think I managed it too loosely. As a result, it was a six month project that I finally decided to stop working on in its 20th month.

For this project, I am going to try to do as much upfront design work as I can, and I will create a project schedule that is as detailed as I can. In both the design and the plan, I expect that things can change over the course of the project. I can’t possibly believe that I would know exactly what will happen over the course of six months.

But I’m hoping that by focusing a lot more work upfront that I can make better prioritization choices and have a much more informed understanding of the impact of a major change.

If I do this work right, I think it is safe to say that you can expect to see this new clown-based game released next summer.

For now, here is a mock-up of a screen:

Clown view mock-up screen for unnamed next project

Wish me luck! And tell me what you think!

Want to learn about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Categories
Game Design Game Development Geek / Technical Personal Development Post-mortem

Freshly Squeezed Post-mortem Presentation: The Dungeon Under My House

Recently I conducted a post-mortem of The Dungeon Under My House, my unfinished non-violent, first-person dungeon crawler that was meant to be the next Freshly Squeezed Entertainment project.

Now I’ve created a presentation based on that post-mortem, so if you prefer videos, you’re welcome:

Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get full color PDFs of the Toytles: Leaf Raking and Toy Factory Fixer Player’s Guides for free!

Categories
Game Design Game Development

Authenticity in Game Development

I’m currently reading “This Is What It Sounds Like: What the Music You Love Says About You” by Susan Rogers and Ogi Ogas.

It’s about the science of what makes certain music appeal to you (or repel someone else). The author argues that there are seven key dimensions that make up a listener profile.

One of those is authenticity.

It’s cliche to talk about “real” musicians vs those who are overproduced candy for the masses. While authenticity is subjective (if you were moved to tears due to a Spice Girls song, no one can say you were “wrong” or “misguided”), it’s separate from a musician’s technical skill.

There is an authenticity to both The Shaggs (a group of sisters forced to practice and perform for their father who refused to actually get them lessons or expose them to outside music, who produced a unique sound that was considered awful until it was rediscovered a couple of decades later by music producers and musicians who were a lot more positive about it) and to Bach’s skillful use of music theory and technique in his concerts.

I’m still reading the book, but I was immediately thinking about how it could apply to games and game development, how some people loved games such as Gears of War or Half-Life 2, and some people really love the amateur games that you can find in game jams, and almost no one likes it when a game adds random features to an otherwise cohesive game design to try to check some boxes to make it more like Fortnite or when a beloved title like Dungeon Keeper becomes a mobile game with silly features that are clearly designed to get you to spend money to speed up knocking down a wall, something that is almost a non-event in the original game.

I imagine that even if we start seeing a lot more GenAI used to create art and animation and audio that there will be a certain something detectably missing. Maybe many gamers aren’t so discerning and authenticity is less important in games than it is in music. Maybe there will be a lot of money made by people who exploit GenAI (and ignore the costs they aren’t paying for).

But I think there will be a difference between something created and something generated, and that something might be what makes a game (1) something that felt worth making to the developer and (2) something that felt worth playing for the player.

Categories
Game Design Game Development Geek / Technical Personal Development Post-mortem

Freshly Squeezed Post-mortem: The Dungeon Under My House

After 20 months of development, I’ve decided to put on hold further work on my non-violent, first-person role-playing game The Dungeon Under My House, what was supposed to be my second Freshly Squeezed Entertainment project.

The Dungeon Under My House

It’s a decision that makes me both sad and glad. I really liked this project and I enjoyed working on it and the idea of what it could become when it is finished, but as a solo indie game developer who is working very, very part-time, it is taking me too long, and from my very rough estimates that are probably very optimistic, I’d have at least a year of work left.

That’s a long time, and I need to be more prolific if I want to succeed. Maybe in the future if my capacity increases, I’ll return to it. I hope so. I think it was going to be a neat game.

Still, just because the project isn’t going to be finished and released (for now), it doesn’t mean there aren’t lessons that could be learned from it, which is why I’ve decided to write this post-mortem for it!

I hope one day in the not-too-distant future a second post-mortem of the project links back to this one.

EDIT: I have also created a presentation version of the post-mortem.

Information about the Project

The Dungeon Under My House started out as just an idea that I had at the end of October 2022. Now, ideas are a dime a dozen and all, but this idea wouldn’t let me go. I got excited about making a non-violent Wizardry-like first-person dungeon crawler in which you are a child hanging out with friends in your modern day home, only to discover a secret door in your basement that leads to a multilevel dungeon. It turns out that your family comes from a long line of explorers and adventurers.

So each day after school, you pick a subset of your friends (with unique strengths/weaknesses) to go into the dungeon for adventures. Adventures might take multiple days (you are children with bedtimes, after all, so you can only explore for so long), and you can prepare for adventures by raiding the house for supplies.

Encounters require you to use your skills and tools to distract, befriend, scare away, bribe, help, etc the creatures, monsters, or other adventurers you find in the dungeons.

In my head, The Dungeon Under My House would be a cross between Wizardry and The Goonies, in which your friends and your friendships play a huge role. It would also be a Freshly Squeezed Entertainment project, which as a reminder are games meant to be quickly created and given away for free.

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.

I started working on the project in earnest in November of 2022, with the hope that it would be a six month project, but anticipating that it might take me as long as a year.

Ha. Haha.

I don’t know why I was so optimistic. This was a big project, and I’ve never worked on and completed an RPG before, nor did I sit down to scope out the project to figure out how to fit it all within six to 12 months. But more on that later.

What Went Right

  1. Creating a design document gave the project a North Star

    Obviously I’m not a believer in creating 1,000 page tomes as a game design document, but I found that not creating a game design document at all for Toy Factory Fixer resulted in a lot of wasted time.

    So I created a document that is mostly based off of Rosa Carbó-Mascarell’s Game Design template, which you can find here: https://rosacarbo.notion.site/Game-design-template-0132383574dd4c2dbff5d14e3a90761c

    I found it very helpful to identify the core design pillars, the theme and mood I was looking for, and general activities the player would participate in.

    I anticipated that the design might change a bit. For instance, I originally thought the idea of designing your own adventure plans and then executing them was going to be a key part of the game play. I envisioned being at the titular house marking up the map with objectives, then entering the dungeon trying to achieve those objectives. As the project progressed, I could drop this set of features easily as it wasn’t strictly core to what the game needed to be.

    But other things stayed the same. The game was always set in a sleepy modern-day suburb, so I never had to waste any time wondering about medieval or fantasy themes fitting in.

    And the core pillar of non-violence helped me steer away from having any sense of a threat to the physical safety of the characters in the game. In my document, I wrote:

    There should be no attacking or threat of attacks, no abuse, no physical or psychological danger, and no killing.
    – So can there be threats that aren’t related to physical/bodily harm?

    And then I listed out ideas of threats to property (theft, vandalism, etc), relationships (break-ups, loneliness, hurt feelings), and information (secrets, lies, incomplete knowledge).

    The document got updated periodically as I needed to jot down parts of the design I hadn’t anticipated, so it wasn’t like I wrote the design once and forgot about it or pretended that I needed to stick strictly to it. It was a living document that I kept open on my computer any time I was working on the game.

    And having all of my design notes and decisions in one place definitely helped me know what forward progress looked like.

  2. Creating cheap prototypes and mock-ups sped up decision-making

    The beginning of a project is always exciting, when anything and everything can be possible, but at some point I need to make decisions that take the project in a certain direction and necessarily cut off other options.

    The design doc helped make some decisions quite easy as mentioned above, but other decisions involved choices that weren’t necessarily right or wrong for the project.

    For instance, knowing that I wanted the game to have a 1st-person view in the dungeon, the question came up: what angle should the camera be at?

    A simple solution is: centered! It would be simple, but it might look boring and uninteresting. Having the imaginary camera higher up and looking down more would show more of the current dungeon tile while also giving the impression that the ceiling is lower or that the player is taller. And having the camera lower would maybe be a more appropriate vantage point for the young children who would be the main characters in the game, but it might prevent the player from being able to see as much.

    At the time, I was planning on using old-style tiles to simulate the three-dimensionality of the dungeon, so creating mock-up art for each angle sounded quite tedious.

    Instead, I used a physical prototype. I took an old shoe box, printed out some dungeon wall image and taped it to the back of the box, then placed some wooden figures in it. Then I took pictures from various angles to get a sense of how it would feel.

    The Dungeon Under My House - cheap and fast prototyping

    The Dungeon Under My House - cheap and fast prototyping

    The Dungeon Under My House - cheap and fast prototyping

    It took me only a few minutes to create, and I learned right away which one I liked best.

    There were also many ways I could show things on the screen, and even if I didn’t know what might be eventually on the screen in the end, I could at least start somewhere. So I created this mockup:

    The Dungeon Under My House - preproduction mock-up

    And I found that doing so helped me figure out where I thought some UI elements would work best. The downside is that I realized very quickly that my mock-up didn’t anticipate the on-screen controls that would be necessary for the mobile version, so I tried another mock-up:

    The Dungeon Under My House - preproduction mock-up

    The latest actual in-game shot shows that I tried a combination approach in the end:

    The Dungeon Under My House - latest dungeon view

    One of the next features I would have worked on would have been the in-game map on the HUD, and so I was already anticipating needing to rearrange and resize various controls, but I know exactly where I want that map to live.

  3. Looking for reference art helped me create a cohesive, “real” world.

    I knew I wanted the game to feel light-hearted and family-friendly. I wanted to have stylized, cartoony art, so photorealistic art wasn’t what I wanted at all, nor did I want a gritty and dark theme.

    I’m primarily a software developer, but I know enough about art that having good reference material helps a lot.

    So I spent time looking into dungeons, sewers, caves, coal mines, and all sorts of things that could act as a dungeon hidden under a sleepy suburb.

    I was disappointed to learn that most real world dungeons were not much more than pits to keep prisoners in, but I was delighted to learn that the Paris has a sewer museum! I even learned that here in Iowa the Wastewater Reclamation Authority has a website that describes how their facilities work AND THAT YOU CAN REQUEST A TOUR!

    And I was very interested to learn of Derinkuyu, Türkiye’s underground city that was rediscovered when someone found a tunnel behind a wall in his home a few decades ago.

    Meanwhile, the other part of the game would take place in the house, so I tried finding art related to various rooms: bathrooms, dining rooms, living rooms. A website about the living rooms of various 90s television sitcoms helped. The living room in my game has a staircase leading up because of course it did: that’s how the rooms on TV look!

    When I found a neat cross-view of a house that had a dollhouse look to it, I knew that I wanted that look for my game.

    Simple house view

    Besides looking for environment art references, I also spent time looking for character art references. Various cartoons, comics, anime, video games, and even clipart examples of children that I thought seemed promising ended up in a large document. I even had some animals, because I hadn’t quite figured out whether or not all of the characters in the game would be human.

    And with a game featuring people, I needed them to look distinct. Clothing store websites feature all sorts of child models, so I found quite a few neat looking outfits, which helped inform the clothing customization options that I added to the game.

    Now, I could have done whatever I wanted. The existence of games featuring sprawling dungeons despite the lack of a real-world equivalent means that it is already OK not to stick to reality. But having a basis for the “reality” of my game’s environments and characters helps sell the reality better than if I used my untrained artistic abilities to freehand everything with no good rhyme or reason.

    Something non-artists might not know: it’s not cheating to use references to inform your art. Use them!

  4. Planning only one thing upfront to work on each week

    This one is kind of a mental health thing for me, but it is a deliberate change from how I ran my previous projects that I think worked out well.

    I ran my project on a weekly cadence. Each Sunday, I would write a blog post about the previous week as a development update, then I would plan the coming week’s sprint.

    In the past, I would kind of mix up my sprint plan with my larger planning, and so I would pick a collection of features to work on, usually features that I think go well together. That is, once all of these are done, I would feel like a significant piece of the game would be done.

    The problem was that sometimes one of those features big quite a lot to work on. Breaking it down into tasks, I’d maybe get a small subset of the tasks done.

    So when I would write my weekly devlog blog post, I would report my progress by saying something like the following from the Freshly Squeezed report of Sprint 42 of Toy Factory Fixer:

    Sprint 42: Training levels

    Planned and Completed:

    • Make sewing worker unique

    Planned and Incomplete:

    • Show tooltips during game based on triggers
    • Create floor training levels/tutorial

    Imagine weeks of saying “I planned to do X, Y, and Z, and I only did X” and you can see why I said it was kind of a mental health thing for me.

    Even if I didn’t mean to say I would get all of these things done in a single week, it still looked like I wasn’t getting things done, and it can be demoralizing.

    And of course, it is hard to predict when things would get done if I kept lying to myself. Not finishing these items means I can’t start working on the next items, and if I do this for weeks in a row, then if I was hoping to get the next item after Z finished by a certain date, well, I can’t even promise I’ll have capacity to start it by then.

    So for this project, I made sure to only plan one feature. Then, I either finish the feature and start unplanned work next before the end of the sprint, or I have only the planned work that is incomplete.

    By and large, it felt better. I no longer felt like I was behind, which is weird because I am my own boss and the feeling came from the accidental promise I was making by listing a bunch of planned work that I wasn’t actually trying to meet. It also helped me avoid deluding myself that a bunch of work would suddenly occur in a single week.

  5. Creating devlog videos to attract more potential fans

    I’ve always written about my game development. This blog started in 2005, after all.

    But sharing my weekly devlog blog posts on social media only gets so much traction these days. Adding devlog videos might increase the likelihood that someone finds out about the games I am working on. It’s another opportunity for someone to discover GBGames and TDUMH.

    So I started making a weekly devlog video. Here’s my first one, published on October 3rd of 2023:

    Oh, that’s rough. You don’t have to watch it.

    YouTube said it has 20 views total.

    In fact, for the next few months, my videos would get about 6 to 35 views each. That’s not a lot, but you know, YouTube is very algorithm-heavy, there’s a lot of other videos being made continuously, my own videos don’t have amazing production values, etc.

    So I spent some time looking into best practices. I started creating custom thumbnails instead of using a random frame from the video that YouTube chose, and I even bought a new microphone to replace the ancient one I’ve had since forever (I think I got it when Windows 95 was the latest thing).

    With catchier thumbnails (I refuse to do a “stupid YouTube face” thumbnail no matter how effective) and a less tinny, much sexier voice, my videos started getting a couple hundred views as well as regular comments.

    Creating the videos each and every week was hard work, even with the low production values. I would write a script, create some video clips of various new features or progress I’ve made on the project, then record myself talking through the update. In the end, I would produce a video that is only a few minutes long.

    While I always tracked how long it took to write a blog post, one day I decided to track how long it took me to create a video from start to end, and I realized that it could take me about 1.5 hours.

    Remember how I said that I am working very, very part-time? I don’t have 1.5 hours to create a video each week! It eats into the time to actually make something for me to show off in the video in the first place!

    So I cut back to only creating a video once a month or two. One benefit is that I have more to show in a given video. Here’s the most recent one that I published at the beginning of this month, and you can tell that is definitely smoother, as I have gotten into a groove creating them in a consistent way:

    And another benefit is that while it takes me longer to make each new video, I feel more comfortable with batching all of that time together once in awhile.

    Obviously the videos are not bringing in thousands of customers, but I do think that it has helped me to increase awareness with a few people about what I am doing, much more than my blog and social media posts alone. As a bonus, it gives me practice with using tools such as OBS Studio, and I can also create animated GIFs more easily.

What Went Wrong

  1. Not creating a real schedule resulted in a non-stop treadmill of development.

    Definitely my biggest mistake was not creating a schedule for this project.

    When I made Toytles: Leaf Raking, I created a road map. It was an optimistic road map in that I anticipated creating the initial release of the game in three months but the actual release didn’t occur until the eighth month of development.

    But the road map was still helpful to create as it helped me nail down as much of the project as I could upfront. I knew that estimates are likely to be way off, but I don’t think I appreciated knowing as much as I did about my project.

    When I worked on Toy Factory Fixer, I didn’t create a road map. I think I had read something about how road maps are awkward in modern development because it implies being able to believe in accurate estimates and also believing that you could know exactly what a project would look like at the end from the beginning.

    In Agile software development, you expect to be able to adapt to changing market conditions, changing stakeholder demands, and changing realities. The road map is a relic of old-style plans that presume you can nail down requirements up front.

    So I skipped the roadmap, and that project lasted a year. What I remember was that it was supposed to be a one month project, and each month I “hoped” that I would finally be finished with it.

    In hindsight, I don’t know why I ever expected to be finished each month because I do not remember doing any work to figure out the full scope of the project until near the end. Maybe it was because I believed my feature backlog was exhaustive and was always surprised as I added to it?

    For TDUMH, I once again skipped the road map, and I didn’t even pretend my backlog was complete. I basically came up with what I thought was a good first pass, and I fully expected that I would learn about the nature of the project as I worked on it.

    I could be responsive, changing and updating my plan regularly.

    And frankly? This works just fine. I could work on the project at the pace I am at indefinitely, and eventually the game would be finished.

    At the same time, I did nothing to try to figure out how to fit this project into a six month period, which is what I wanted it to be. But merely wanting Toy Factory Fixer to be a one month project wasn’t enough, either.

    So I had a conflict that I wasn’t addressing: my business expected me to release games more frequently, and my management of the project had me working as if I could take forever to release the project if I wanted to.

    At some point in the last few months I realized that I needed to figure out how much work was left on the project, and with my very rough estimates, I’ve decided what was left was way too long.

    And I think if I knew it upfront, I might have tried to make a smaller version of the game.

  2. Not prioritizing the work well wasted my time.

    Even early on I knew that by making the game non-violent, I would need to replace all of the compelling combat-related mechanics such as health, weapons, armor, attacks, etc with something equally or more compelling. My goal was to emphasize conversation and knowledge-acquisition.

    The thing is, I didn’t know what it would look like.

    A branching dialogue tree wasn’t going to cut it. I didn’t want to make a rigid story or a visual novel. I wanted something more dynamic and flexible, that required the player to make more interesting decisions than choosing between a handful of pre-written options.

    In short, I wanted the conversations to BE the main game play.

    And yet, instead of spending time prototyping conversation systems and UIs and researching existing games that do interesting things with conversation mechanics, I worked on character customization.

    The Dungeon Under My House - new character customization

    The Dungeon Under My House - character customization

    I justified it to myself. I really, really wanted the player to feel like they could see their friends and family, or maybe a fantasy version of who they wish their friends and family were, in the game. It seemed important at the time.

    And I worked on creating the first person dungeon view, first by trying to create tiles, and then creating a raycasting renderer, and then profiling it and debugging it to see if I can get it to be performant each time I made a change that slowed it down.

    In hindsight, I should have realized that the first-person aspect of the game, as nice a thrown-back as it was to the kinds of old-school RPGs I wanted to remind the player of, was not necessary or fundamental. A top-down overhead view would have been faster and easier to implement. Character customization turned out to be tedious work, which I didn’t anticipate when I started, and perhaps for this project I should have created concrete, unchangeable characters if only because it would have been faster.

    And the main reason I wish I had done those parts of the game so much faster is so I could focus the bulk of my time on the more interesting game play that I was trying to create with conversations and personalities and knowledge acquisition. Instead, after 20 months, the systems in place feel clunky and limited, and I knew I still needed to expect to spend considerable time on experimenting and figuring out this core part of the game.

    It would be one thing if I spent only a little time on non-core things. Spending 20 months on a project might have been more palatable if I had spent a large amount of that time coming up with new game play, but as it is, I feel like I could have used my time better.

  3. Not quitting earlier meant missing opportunities to publish more frequently.

    This one is kind of related to the previous points. If my goal is to release a game in six months, I should hear alarm bells in my head when I hit the six month point and not have a game anywhere near finished.

    In fact, those alarm bells should have been heard long before six months passed, because I should have an idea how much of the game was finished versus how much is left to do and be able to figure out how confident I felt about getting the remainder of the work completed in the time left.

    Instead, as I said before, I could work indefinitely on my project, inspecting and adapting as I go, and given my limited capacity, I wasn’t investing time to inspect the health of the project as a whole. I did not treat the six month deadline as a real deadline so much as a soft suggestion, which didn’t help give me a sense of urgency or a reason to worry.

    Toy Factory Fixer’s initial release was in 2021. I didn’t start TDUMH until 2022 with an expectation that I would release it in 2023. Even if I had succeeded, that is already a long time between game releases, at least for my business goals. Taking longer than six months means even more delays for accomplishing those goals.

    Maybe if I would have put the project on hold or canceled it in 2023, I could have used the time since then to figure out a smaller scoped game. Maybe by now I would have released at least one, perhaps two or even three more games.

    Better late than never, but I should be more protective of my time. I am getting too old too fast, so it isn’t just my business goals I’m worried about.

  4. Waiting so long to use freely available UI elements made my game look amateurish

    When I started working on the project, I slapped art together to get something on the screen as quickly as possible.

    The main menu’s buttons, for instance, looked like this:

    Freshly Squeezed Entertainment game #2's title screen mock-up

    Just colored rectangles. They are functional and easy to create.

    I also tried to add a little bit of detail to them to make them better, but it was still very basic:

    The Dungeon Under My House - old title screen with placeholder buttons

    Between taking screenshots and making videos, I had a lot of footage of the game with these placeholder UI elements.

    Which is unfortunate, because the entire point of publishing footage of the game was to get people interested, and I was basically saying, “Here’s this ugly amateur thing for you to not waste your time with.”

    It was only recently that I decided to use buttons from the free Kenney UI Pack, and after adjusting some font colors and sizes, the buttons on the screen looked way better.

    The Dungeon Under My House - title screen with new buttons

    What’s weird is that I had no problem using existing UI art. I already used icons from Game-icons.net in various places, and I already knew about free assets from Kenney.

    So I’m not sure what took me so long to get around to it other than a sense that other things were more important to work on.

Lessons Learned

  1. I should take advantage of good art assets earlier.

    I should definitely start my next project with great looking icons and buttons, especially if they are going to be displayed on the screen a lot and they’ll be some of the first things seen in screenshots and videos.

    While I still like providing my own art in general, and I don’t think I should fill my game entirely with free sprites and icons, using fantastic, ready-made resources such the Kenney UI Pack makes the game look way better than I could on my own and in a much faster time period. I should really need to justify not using them rather than the other way around.

    And if game UI icons and assets make sense to bring in early, what about sound effects and music? I usually leave those until late in the project, and perhaps it makes sense to have placeholder audio at least.

  2. If I want to release more frequently, then I need to make a schedule.

    Open ended projects are a luxury I can’t afford.

    As I said above, it isn’t as if I couldn’t keep working on my project the way I have been. I know each week I make a little progress, I can inspect and adapt as I go, and one day I’ll work on the last bit of progress and call it done.

    But my business strategy ostensibly requires me to release my games much, much more quickly. Until I can increase my capacity to work on my projects, my projects will need to be scoped much, much smaller so that I can get them done in a reasonable time.

    I still expect that I’ll need to inspect and adapt, that I can’t possibly anticipate everything, but I’ll have a better idea of what needs to go into a project plan for a small game than a big one.

    So simultaneously knowing as much about a project as I can will help me create a realistic schedule, and a schedule with deadlines should help me limit how much a project can be.

  3. With my limited capacity, I need to ruthlessly prioritize the work.

    I like to be purposeful, which means that each project I work on isn’t just a random collection of cool-sounding features. When I create a game, I like to identify some core part of it that is the reason it needs to exist now instead of some other project.

    For TDUMH, I wanted to make a non-violent dungeon crawler, and what I should have done was figure out exactly what I needed to focus on to make it work. I already mentioned above that not having combat in the game isn’t enough, as I needed some compelling game play to replace it.

    If I were to start again today, I think I would realize that I need to prioritize prototypes related to conversation and knowledge-acquisition mechanics as early as I could. Maybe I could have decided then that a party-based RPG would be too big of a project, but what if I applied the same focus on conversation and knowledge-acquisition to a game that consisted of nothing but a small room and two or three people, and maybe a few objects?

    I might have been able to put together a game in a much shorter period of time, and I could always use it as a building block for my next project.

    Since I instead worked on things that shouldn’t have been prioritized, I still need to figure out compelling game play because right now I just have customizable characters and a dungeon to traverse but not a whole lot else.

    Even if I had more capacity, I still would want to prioritize my time much better, if only to make sure that I am releasing games sooner than later.

    For the early stages of my next project, I should spend time trying to identify the dependencies between different features and systems. I did a light list for TDUMH, in fact, but it wasn’t something I paid much attention to, and well, here I am wishing I had done more.

  4. I should continue to seek out opportunities to promote my work.

    People have asked me why I still try to sell Toytles: Leaf Raking after all these years. Why don’t I just drop it and forget it and move on?

    And my main objection to that reasoning is that it isn’t as if lots of people saw the game and thought, “Nah.”

    So I try to promote it and sell it because people by and large haven’t had a chance to reject it yet.

    Like most indies, obscurity is my main obstacle to success.

    For TDUMH, I found that sharing screenshots, posting weekly progress reports, and publishing videos means I am giving more potential fans a chance to find out that my games exist.

    Some of those people become fans who start to ask about details, but I don’t know where the next fan will come from. Maybe they’ll find my blog post because someone shared it. Maybe they will be perusing YouTube and the algorithms will manage to place my video in their feed at the right time. Maybe they’ll see one of my screenshots posted on social media.

    Most of my time is spent on game development, but it doesn’t take much time at all to capture in-development screenshots that I can then easily use in blog posts, videos, and posts on social media. There’s no excuse to not tell people what I am working on more frequently and in more ways.

    Plus, making games with an audience is a bit more motivating than listening to crickets.

  5. It’s easy for me to keep my nose to the grindstone.

    Each week, I plan the work for the next sprint, and then each day I succeed more often than not to make steady progress.

    On average last year I worked about 7.5 hours per week, and this year I’ve been trying to hit 7 hours per week as well.

    As much as I would love to make more time for development, given my life priorities and obligations, this pace is doable for me. I rarely find myself exhausted or burnt out by it.

    Maybe that sounds silly, but the hours add up, and each hour I work on my game is an hour I’m not spending time with my family. Until I quit my day job and free up a significant source of hours, this pace is my reality.

    That said, I have shown that if I set myself in a direction, I can continue plodding along until I’m finished. I stick with things, and I can keep focused on the same task. These are good things!

    The challenge is to make sure I check in on myself to ensure that direction is still a good one and course-correct as needed.

    I’m used to focusing on the current sprint’s tasks, then planning the next sprint. I’ll need to start looking at any given sprint as part of a whole, asking myself how far along do I think I am and how much more is there to do. And I’ll need to be honest. If I already have X tasks to do in Y weeks, and I discover an X+1th task, it very likely means I’m working for more than Y weeks if I think it needs to be done. Which means I’ll need to be sure that it is something that “needs” to be done and not just a really appealing nice-to-have.

    These frequent project health check-ins should help me lift my nose up from the grindstone periodically, mainly to make sure I’m using the right grindstone.

Conclusion

As excited as I was about The Dungeon Under My House, it ended up being too big of a project for me at this time.

I’m not new to game development. I’ve been creating games for many years. Still, this project reminded me of my limits, and if I am honest, it humbled me a bit.

I do believe that if I kept going the way I had been going, the game would eventually be finished, but it would take me way too long to get there. At least, too long for my overall business goals.

The opportunity cost is too great when I could be releasing smaller games and building an audience during that same time. So as painful as it might be to have to part ways with this project for now (and potentially forever? I hope not), it’s not a hard decision to make.

After 20 months of development, even though I won’t be shipping this project, I am glad I can take stock and glean some insights from it.

I know this analysis will help me greatly with my next project. If I could sum up the lessons, it would be that it isn’t enough to keep moving forward because I also need to ensure the destination isn’t too far away.

I hope this post-mortem helps you, too. Let me know if it did!

Stay curious!

Want to learn when I release updates to Toytles: Leaf Raking, Toy Factory Fixer, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and get full color PDFs of the Toytles: Leaf Raking and Toy Factory Fixer Player’s Guides for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: iOS SDK Updates and Scoping the Current Project

Last time, I reported that I was working on iOS SDK updates for my existing projects, which required taking a short break from The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

iOS build automation

So as I said last time, much of my iOS port work tended to be manual, partly because Apple development environments are so bizarrely different from everyone else’s, and partly because Apple seems to strongly discourage build automation.

Well, sort of.

See, I made the mistake of thinking that build automation is the same as everywhere else: you write scripts using command line tools, and then you can specify configurations and kick off builds whenever you want.

But last week I found out that the reason why I couldn’t find much info about using xcodebuild is because it was buried in the docs for using the Xcode Cloud. “Oohhhh, of course! You’re supposed to do it the Apple way!”

Well, whatever, I’m not planning on using their Cloud services, and I’ve figured out much of what I need to do with CMake and xcodebuild as it is.

In fact, I think I am at the point when I can run a single script to generate an Xcode project and then build it and install it on a simulator to test it, and a different variation of the script to build and archive and upload to the App Store for validation and potentially preparing for publication. Nice!

Of course, as I said, I have an old Mac Mini that runs an old version of Xcode, so when I try to do so, I get a fun error:

Asset validation failed. SDK version issue. This app was built with the iOS 16.2 SDK. All iOS and iPadOS apps must be built with the iOS 17 SDK or later, included in Xcode 15 or later, in order to be uploaded to App Store Connect or submitted for distribution.

BUT what this error also tells me is that I’m probably ready to use Mac in Cloud.

Mac in Cloud offers a Pay-as-you-go plan. While I could have gotten the day by day plan, I decided to go with the hour by hour plan because my own development efforts match it better. Some days I only get an hour of game development in, and it would feel wasteful to have access to 24 hours and use such a small part of it.

What I didn’t anticipate was that I found myself not logging in to make progress because this past week I found myself struggling to find an hour that I knew wouldn’t be interrupted. My desire not to waste my limited hours conflicted with the need to make forward progress and my own time capacity.

It didn’t help that when I finally tried to log into the Mac in Cloud instance that I kept getting an error message. When I contacted help, they offered no help (other than a screenshot that indicated that they had logged into my account successfully) and instead offered help related to connecting to the server in the first place. Obviously if I got as far as the login screen and error messages, then I didn’t have an issue connecting, right?

But I clicked the link they provided, which took me to the same place, and I couldn’t login still.

So I decided to finally get a screenshot, and…suddenly I could log in? I must have been typing my username and password wrong this whole time?

And of course, by this time, I didn’t have the hour to take advantage of anymore, so I wasted a session. B-(

Anyway, I expect I’ll make the time this week, and hopefully building with the latest Xcode and SDKs won’t pop up too many surprises to debug and address.

The Dungeon Under My House scope

Meanwhile, I’ve been slowly plodding along with The Dungeon Under My House (TDUMH), and I recently decided to figure out just how much work is left.

You might be thinking: wait, you don’t know?

No, I don’t. No one really knows how big a project is at the start. You can pretend to know, but often your initial project plan misses things, sometimes very big things, and so you find yourself working on things you didn’t know you would be working on.

So my approach to this project was to try to identify some major features upfront, but also to be flexible enough to handle the addition of new features as I recognize their need.

As you may remember (since I bring it up a lot!), I’m a very, very part-time indie game developer. Between family, a day job, and other obligations, I only spend so much time on game development.

On average this year, I have done around 7 hours of game development in a week. Some days I do multiple hours, and some days (usually weekends) I do almost none. Even some weeks have very few hours while others have more to make up for them. In other words, my productivity is uneven.

As much as I would like more time to work on game development, I currently can’t see sacrificing other priorities in my life to make it happen. Given my capacity, I’ve found my plodding efforts are fairly sustainable. I feel like I could keep up this pace forever.

However, I know this project has been in development for a very long time. At least, calendar time. The actual amount of time spent working on it probably works out to a bit over 650 hours, although I don’t keep track of time spent on individual project, so any chunks of hours working on my previous game updates aren’t separated from these numbers. But most of the time is definitely focused on TDUMH, so let’s pretend 650 is a good rough number.

If this was a full-time effort for me, 650 hours works out to a little over 16 weeks, or ~4 months. That’s not bad. Another 6-8 months, and I can this project being not only finished but also highly polished.

But since it isn’t a full-time effort, those 650 hours are spread out over 20 months. I’ve spent 20 months of my life on slowly adding features and creating the game content to take advantage of those features, and I don’t have a game anywhere near releasable.

When I started this project, my intention was for it to be a six-month project. Not a six-month full-time project. A six-month project at my current game development pace.

It’s not great being 20 months into a six-month project with no sense of how many months are left.

So when I wasn’t working on iOS SDK build updates, I was spending time trying to identify all of the remaining work for TDUMH. I’m not finished with the scoping work yet, but I can say that there is quite a lot left to do.

Once I get a much more solid sense of it, I can make a decision about the future of TDUMH. My goal is to release games more frequently than I am, stay tuned!

Thanks for reading!

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: iOS SDK Updates (and Rant)

In my last report, I updated the buttons to significantly improve the look and feel of The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

While much of last week was spent attending to other tasks, such as creating a devlog video about the last two months of progress, I did spend a little time on automating my iOS builds for Toytles: Leaf Raking and Toy Factory Fixer.

New mobile requirements

This work is generally applicable to all of my projects, not just The Dungeon Under My House, but it will benefit as well.

I like to ensure my game is available on as many devices and platforms as possible, so I write cross-platform code, avoiding proprietary technology as much as possible. By doing so, I am able to publish my games for Linux, Mac, Windows, iOS, and Android.

Unfortunately, Apple and Google like to update their requirements for keeping your apps in their stores, even if your game hasn’t changed.

For Google Play, it’s not so terrible: I simply get the latest NDK and SDK and build, fixing whatever little changes might be required that usually doesn’t affect my game’s code so much as the various Android-specific scripts and configuration. And I can do it on my normal development computer, which is a Dell PC I bought in 2013 running Ubuntu that has had some of the internal hardware upgraded and still works just fine.

But for the App Store, I cannot easily do the same. In fact, not only does Apple require that apps need to support iOS SDK 17, but that the apps must be built with Xcode 15, which means it needs to run on an Apple computer.

Apple Developer Program requirements

Both iOS SDK 17 and Xcode 15 were released about a year ago, and both are free. What’s the big deal?

Well, unlike previous updated requirements, this one comes with baggage.

See, I have a Mac Mini. I bought it in 2017, and despite it being fairly underutilized and otherwise perfectly working hardware, it’s old enough now to be considered officially “vintage”.

If you’re not familiar with Apple hardware life cycles, vintage means Apple stopped selling the product between 5 and 7 years ago, which limits how much support they provide for it.

In this Mac’s case, it stopped getting OS updates after macOS Monterey, which means the latest Xcode available to me is definitely NOT Xcode 15.

Next year, my Mac Mini will be considered “obsolete” because it will be after 7 years since they last sold that model of Mac Mini.

Ok fine, I just need to buy a new Mac, right?

Well, I’ll get to that. But first, the computer I have still processes bits and bytes just fine, and so I’m more than a little frustrated that Apple’s policies are forcing me to abandon the as-already-mentioned perfectly working hardware.

Yet Apple won’t provide new OS updates to this machine, which means no Xcode updates, which means I cannot use this perfectly working hardware to create and publish apps in the App Store anymore.

You know, if Apple sales were a real money-maker for me, I could see the investment in a new computer being a no-brainer cost of doing business. But they aren’t.

In fact, between paying $700 for the Mac, $400 for the iPhone SE to act as a test device (which of course is also now vintage), plus $170 for a used iPhone 7 to act as a second test device when I couldn’t reproduce an issue on the SE that was being reported to me from a customer, plus $100+/year for the Apple Developer program since 2019, I’ve spent a lot of money to ensure my games can be available on the App Store as it is.

In return, I can say that I’ve only earned back a total of a little over $100.

To be clear, that amount is the total since my first sale on the App Store in 2020.

I have not earned back my investment the same way I have with the one-time Google Play $25 developer program fee.

Now, you can say that I should be doing more promotion, that I should make the game more attractive, and it is my fault and such, and you’re probably right.

But it still makes me wonder why I should spend hundreds more for a new computer just because Apple insists that I need to use one.

Which is why I signed up for Mac in Cloud’s services. If I can successfully build and publish my games through THEIR modern Mac, I can pay significantly less than the price of a new Mac that Apple will call vintage within a few short years, and the only thing I need to worry about is testing on a real device.

The real challenge is that my iOS development up until now has been fairly manual.

I have a CMake file that allows me to generate an Xcode project. For some time I had pieces that I still had to update in Xcode such as adding images to the resources folder and setting up code signing, but eventually I updated my CMake files and other configuration to set those automatically, too. The only thing left that I did in Xcode was building and archiving the project, then uploading to the App Store to publish it.

But I’ve never liked feeling like I need to use Xcode. Almost all information and help out there assumes you are building through the IDE for some reason.

While I don’t find it to be a very fun IDE to use, the main concern is that I like scripting and automation better. Having a script you run to build your games can be a more consistent experience, and I don’t need to worry about forgetting how to do something when the scripted command is in version control.

So my work this past week has been trying to figure out how to automate the building of my project with xcode-build. I’m doing this work on my Mac Mini, because again, it is otherwise perfectly working hardware, but also because I don’t need to use up my Mac in Cloud hours.

Once I get it figured out on my own Mac, then I’ll switch to using the Mac in Cloud service, where I expect I’ll run into minor Apple-specific configuration requirements that I’ll only discover when Apple rejects my app for not having them or when Xcode 15 turns some optional configuration into a requirement.

Wish me luck. I hope it won’t take me long, and if Mac in Cloud works, the price is much more affordable, but I am wondering if next year’s $100/year Apple developer program fee will be worth it, and we’ll see how my efforts to sell my game in the coming year work out to change the equation.

Thanks for reading!

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Video Progress Report: Giving Items, Sleeping, and UI Improvements

Here’s the latest Freshly Squeezed Progress Report video, with footage covering the last couple of months of development, including this past week’s report: Improving the UI

Enjoy! And let me know what you think by replying below!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Improving the UI

Last week, I reported that I had fixed a number of defects and finished working with quantified items allowing the player to distribute snacks to other characters in The Dungeon Under My House, my non-violent, first-person role-playing game and my second Freshly Squeezed Entertainment project.

I needed to switch my efforts to supporting other projects but first I decided to tackle something that makes a substantial difference to the look and feel of the game.

Sprint 2024-31: UI – buttons

Planned and complete:

  • Improve UI buttons shapes/images

If you’ve been following along from the beginning, you know that I’ve had some placeholder buttons in place.

Freshly Squeezed Entertainment game #2's title screen mock-up

Here’s what it looked like last week, which is what it has looked like for months after I did a slight improvement by creating the outline, but I was never happy with it:

The Dungeon Under My House - old title screen with placeholder buttons

And here’s what it looks like today:

The Dungeon Under My House - title screen with new buttons

I decided to take advantage of the Kenney UI Pack, part of the many free assets created for game developers to use in their games. Why haven’t I been doing this sooner?

I took a button that I liked, modified it so that it can represent different button states, and now this lifeless interaction:

The Dungeon Under My House - moving quantified items between inventory slots

instead looks like this:

The Dungeon Under My House - moving quantified items between inventory slots

Seeing it in action really helps explain how much of an improvement this small change made.

I also realized that it would help to have fonts that contrast better with the button’s color, so I tweaked some of my UI helper code to allow me to specify the font color, and I think it is definitely better.

What do you think?

The GIF doesn’t seem to make it clear each time the button is pressed, but I think that’s more due to the frames being dropped because in-game it looks fine.

After this small yet impactful change, I started to work on my existing games. Basically, Apple requires new and updated apps to be built with Xcode 15 and use at least iOS SDK 17, and my current Mac Mini is too old to support the latest Mac OS which is why I can’t run Xcode 15.

So I signed up for Mac in Cloud which offers access to an M1-based Mac Mini and development environment that I can remote into, and it lets me pay for hours instead of days. That’s great, because as someone who works very, very part-time, who sometimes only works an hour a day on my projects, I don’t need to feel like I’m wasting my money.

Still, I do need to make sure that I make those hours count, so I’m currently updating my games to use the latest libSDL2 and related libraries. By and large it is straightforward and everything is compatible, but of course the main sticking point is that Apple has new requirements that the library might not yet support.

I’m still investigating, but I know a lot of effort is being put into libSDL3, so it isn’t clear to me yet if libSDL2 will be able to support the latest App Store requirements.

And I’ll see how complicated this work is and if I think it might be worth it going forward. My apps haven’t actually changed, yet I have to go through this effort just to keep them up in the App Store, and I’m not sure if it is worth it.

I’ve been paying ~$100/year for the privilege of being in the Apple Developer program, which allows me to publish to the App Store, but I am not making anywhere near that from the App Store, and unless my marketing efforts start to change the numbers substantially, I’m just paying to lose money, which makes this annual porting effort questionable as a business activity.

Thanks for reading!

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!