Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Finding Reference Art and Addressing Annoying Infrastructure

In last week’s report, I was still taking my high level ideas and concepts for my yet-revealed Freshly Squeezed Entertainment project and trying to make them more specific and implementable.

Since then I have enough to start actual work.

Sprint 3: Pre-production and initialization

Planned and incomplete:

  • Finish initial design document
  • Create save file
  • Create player character
  • Create [redacted] environment layout

Ok, to start with, obviously I didn’t get anything finished.

That said, I did spend much of the beginning of the week looking up references to help inform the art style for this project, both for the characters and the environments they spend their time in. It was also informative to read some background on some of these environments, and while I think it will ultimately help me create a better world, I also worry that there was still too much absorbing input and not enough creating output.

I spent time learning about the pitfalls of games that this project is likely to be compared to, especially when it comes to how those games and the companies that made them handled things like race and inclusion. More on that topic another day.

And I started to work on creating the initial save file, since persistence is going to be a very key part of the game from the beginning.

Unfortunately, I got slightly sidetracked. Since the code is my own, there is a bit of infrastructure related to how I handled menu-related things that is quite clunky. It is old code related to my understanding of the IMGUI concept, and it has been bothering me for a few projects now, and I finally decided to address it. EDIT: I realized that my attempt to address this clunkiness wasn’t well thought out and so I ended up reverting my changes. Ah, well.

Otherwise, I’ve been creating doodles of the environment and of potential characters, and I think I’ve got a good idea of what at least one of the characters in the game will look like.

So it has been a weirdly fruitful week while simultaneously feeling unproductive. I knew I had put too much on my plate when I started the week, at least if I expected to finish it all, and I’ve done this a lot.

On the one hand, when it comes to planning the week, I should plan what I can get done by the end of the week. I should have planned less.

On the other hand, I think what I captured in this list is a chunk of work that I want to get done together. It is less of a set of goals for the week as a set of goals for an initial playable milestone.

So, another clunky thing is that the way I handle project plans is a bit clunky, at least when it comes to how I actually try to manage the project. I should either plan less for a week, or I should find a better way to identify these collections of work for a given milestone.

Anyway, I apologize if this kind of background information is not interesting to you, but if you do like it, then you’re welcome!

For now, know that I have started coding for this project in earnest, and I am looking forward to being able to share more about this second Freshly Squeezed Entertainment game.

Remember, sign up for the GBGames Curiosities Newsletter below if you want to be the first to see what I’m working on.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: More Detailed Designing and Planning

In my first progress report for my second Freshly Squeezed Entertainment project, I was a bit enigmatic about what I’m starting to create. My goal for the last week was to take a lot of my high level concepts and make them more concrete, tangible, and real enough to implement.

Sprint 2: Pre-production and initialization

Planned and incomplete:

  • Finish initial design document

Last week I said that this game was going to be a 2D, 1st-person, non-violent, family-friendly game focused on mystery, exploration, and personalities intersecting. It will be available on mobile devices as well as personal computers for free, and there will be no ads, in-app purchases, or any data tracking, so it will respect your privacy just like my other games, Toytles: Leaf Raking and Toy Factory Fixer.

I also said that I didn’t want to share more until I had something more solid. Much of my design was still very high level, and I wanted to focus on nailing down exactly what some of the concepts would mean when realized in a game.

I had an 11+ page design document that I am still adding to and modifying, and I needed to turn it into an actionable project plan.

So I had three major tasks for this past week.

First, I wanted to identify the player’s main activities. What does the player get to do? “Move” is too vague, but being able to navigate forward and backward, and to turn left and right are more specific. I’ve eliminated moving side to side to keep things simple, for instance. “Interact with objects” is another example of vagueness that I wanted to make more specific. What kinds of objects? What happens? And how does the player interact with them?

Second, I wanted to identify the major “modules” I’d need for the game. I know I have two modes in the game, one of which is 1st person. What exactly do I want the player to do in the non-1st person mode? Also, what about other aspects, such as saving and loading, or customization? I’ve already scoped down a bit here while identifying what I consider a must-have for this aspect.

And third, I wanted to identify the art style of the game. What is it actually going to look and feel like? I already have a bunch of reference art that I’ve put together over the previous month for characters, but I need to do something similar for the environments.

I did manage to put in a relatively significant amount of time into the first two tasks. It’s hard to quantify how “done” these tasks are, especially when I can always come up with more and can always recognize that there is some vagueness to make clearer.

But I was able to flesh out my project plan with a prioritized list of tasks and features that should let me get the core spine of this project playable fairly quickly, and I think that’s a successful week of effort. I can more clearly see what the next few weeks (months?) of development are going to look like, and I can more clearly see what I might need.

For instance, I realized that I’m going to need a tool to help me build out the world, because I can already see that manually modifying a text file myself is going to be tedious and error-prone. Whether I use something like Tiled or create my own map editor, knowing that this kind of effort is coming can help me avoid too many surprises.

I’m also seeing just how large this project can potentially be. My project plan so far has a lot of work identified in setting up mechanics, which says what CAN happen in the game, but I only have a few things that specify details about content and story, which says what DOES happen the game.

In Super Mario Bros, you can jump and run, but jump and run on what? To where? For what purpose? These mechanics ultimately allowed you to save a kidnapped princess, but at a smaller level it allowed you to avoid enemies, find secret locations and power-ups, and raise flags on flagpoles to complete individual levels.

Much of this kind of work, the connective story work and context for the mechanics, isn’t represented in my project plan yet. I have some major ideas of what I want the game to be about, and a lot of the mechanics that I do know about are due to those ideas, but I anticipate that some of the details might need to wait to find out how much of the scope of the work above might change as I get into it. I don’t want to plan for a sequence in the game that requires a set of mechanics that I decided to cut due to complexity and time.

But that’s ok. I think I am at a good point to start implementation, and the project can evolve as I work on it. The challenge is how to figure out when I’m at a point when I want to stop evolving it and get it shipped.

For now, I am hoping that in the next week or so I can have enough to show off that I can show subscribers to the GBGames Curiosities newsletter what my next game is going to bed. If you want to be the first to know, subscribe to my newsletter below.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: New Project and Initial Design Work

I’m excited to say that I finally decided on my next project and started actual work on it. Here’s the first of my weekly Freshly Squeezed Progress Reports for my second Freshly Squeezed Entertainment game.

Sprint 1: Pre-production and initialization

Planned and complete:

  • Get a basic project building/running/quitting

Planned and incomplete:

  • Finish initial design document

What’s the game? Well, I’ll tell you later.

I’ll refer to this project as FS2 for now, as I want to have more to demonstrate before I officially announce it, and I will be telling subscribers to my Curiosities newsletter first, so sign up for the GBGames Curiosities newsletter to be one of the first to know what FS2 will be!

Here’s what I can say for certain about the game:

  • it will be playable on mobile devices as well as desktop computers
  • it will be a 2D game with a 1st-person perspective for the main game play
  • it will be free, with no ads, no in-app purchases, and no data harvesting
  • it will be family-friendly and non-violent

And anything more will give away too much. Maybe next update?

To start a new project, I took my previous project, Toy Factory Fixer, copied its source files, then deleted all references to that game, then made sure that I could build and run a main menu that lets me quit the game. Until I get title graphics, I used a mock-up, and I am using gray rectangles to represent buttons.

Here’s a peek at part of the title screen:

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

It’s not pretty, but it doesn’t need to be at this point. I just needed to get something up and running that I can use to build off of.

That was the quick and easy part.

As for what to build next, well, I didn’t feel comfortable working on implementing anything until I figured out a more solid design.

I didn’t intend to make a design document of any significant size, and I know I don’t want a multi-hundred page document that I’ll never look at, but I’ve been writing down a lot of ideas at this stage. 11 pages, in fact. I expect that I will scope it down significantly, leaving a lot out for a sequel or future update.

I’ll have more to say about the details of that design, but for now here are some of the core aspects of this project.

First, this will be a non-violent game: “there should be no attacking or threat of attacks, no abuse, no physical or psychological danger, and no killing.” With the kind of game this is going to be, I feel that making it non-violent is going to be relatively challenging, but it should be relatively unique. While there are many examples of non-violent games, especially in mobile games, it really does feel like most games provide verbs of ATTACK or KILL or DESTROY and not much else. To be clear, I’m not saying that I don’t like violence in games or that you shouldn’t play games that feature violence. I’m just saying that if you want violence, there’s plenty of games to choose from, and I want to try to make a game that is about something else.

Second, the game will focus on personalities intersecting: “when you have multiple people with different interests, goals, and norms meet together, the results can be insightful, explosive, beautiful, synergistic, or counterproductive.” In past games, I found myself adding personality to the main characters and entities late or not at all, and I think it made those games feel cold, impersonal, and mechanical as a result. For this project, I want to make it feel like you are dealing with living, breathing people and other entities. When you see two different entities, they should be two different entities, with unique identities, rather than clones.

Third, I want to focus on mystery and adventure: “the ____ is like a completely different world, with rules and laws that are strange and wonderful. It holds secrets, and the player will want to learn them all.” I want the game to be about exploration. That’s a tall order, especially as I expect it will require a lot of world-building and narrative design, but I’ll have more to say when I can tell you what “____” is. B-)

As for the mood and feel, I want it to be light-hearted and family-friendly. I’m taking a little inspiration from the game Earthbound and the movie The Goonies. I want it to be a game that is incredibly accessible, and so long as you can read and think, you should be able to play. It won’t be hardcore challenging, but at the same time, it won’t be incredibly simple either.

Since I’m at the beginning of this project, it’s one of the most exciting ways a game can exist: as a collection of really cool ideas in my head. The problem of course is that to actually create this fantasy project as a real game might take forever, or it might not actually work at all.

I know what kind of game I want to make, and I know a few of the fundamental things I will need to implement. I also recognize that while there are a few things I can borrow or steal from other games of this type, many of the things I am thinking about doing with this project require some experimentation and prototyping. Probably too many for someone with limited time such as myself.

Basically, while I have enough to get started, there are still too many vague ideas the game is depending on. I don’t need to have everything worked out in extreme detail, but I need enough there to actually have something to implement and prototype.

So my own goals for this past sprint were to figure out more precisely what this project will actually be. I needed to identify the player’s actual goals, activities the player will be involved in, and the high level systems and interactions I’ll need to implement to make it all real.

Part of that work has become the lore of the game, and I think I have a good overarching goal as well as some interesting situations to put the player in. Plus, as I have been figuring out what locations and entities should be in the game, I’ve been identifying specific systems that might be needed to make them work.

I’ve made good progress on turning my high level ideas and concepts into more specific features that can be made into actionable and tangible work, but there’s still more to do. What I’m looking for are the building blocks to start with, the things that let me build the spine of the game, and then I can iteratively and incrementally add to it. What I don’t want is to work for months on a set of features that I hope fall into place with the risk that it never does.

I apologize that the above lacks a lot of specifics. Rereading it, it sounds like I am saying, “I’ve got a new project, but not really.” Maybe this update was premature, or maybe I’m putting too much importance on wanting to wait until I have a little more substance to tell my newsletter subscribers what I’m doing before I announce it here.

But for now, I have some designing and planning to do.

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical Personal Development

What I Learned Creating Game Designs Based on News Headlines for a Month

As a very, very part-time solo indie game developer who has to wear a lot of hats, I worry that my game designer hat tends to get neglected, especially as I spend the bulk of my time programming, creating art, or updating my project plans.

You could argue that game design activities are infused throughout the game development process, but it feels like my opportunities to do focused game design work are few and far between.

Which meant that I probably wasn’t getting better at game design.

To address this skill gap, I wanted to improve my game design abilities through regular practice and in a way that didn’t require me to completely upend my daily routine. I only have so many hours in a day I can dedicate to my game development business (very, very part-time indie, as I said), and I didn’t like the idea of sacrificing more of that precious little time.

So I decided on doing a daily challenge of taking 20 minutes to create a working prototype or 1st iteration of a game based on that day’s news headline throughout the month of September.

I explained more in my post Quick Daily Game Design Practices, but the short version is that I expect that even a short amount of focused daily game design should result in me gaining experience and developing a better intuition about game design over the course of a year.

I’ll break down the challenge:

  • Daily: if I do it once in awhile, such as every Ludum Dare, or anytime I start a new project, it seems too infrequent. Plus, there is a difference between practice and being on the clock.
  • 20 minutes: the exact amount of time doesn’t matter, but the focus on speed serves two purposes. One, even on a busy day, I figured I could more easily justify carving out 20 minutes than if I needed to spend hours on it or dedicate a weekend to it. Two, the time constraint meant that I couldn’t waste time. I needed to focus.
  • Working prototype or 1st iteration: it’s one thing (and super easy) to come up with ideas for a game. It’s quite another to actually implement those ideas. I didn’t need to make a finished, publishable game, but I did want to make a finished-enough-to-give-to-someone-else game. It will likely be necessarily rough around the edges, unbalanced, or even potentially broken, but it needs to be real.
  • Based on a news headline: having a daily prompt meant that I had some focus for the theme or concept, so I wasn’t starting from a completely blank slate. It also meant that I might have to work with a topic that I might not have picked myself, potentially pushing me out of my comfort zone and challenging me with a topic I might know nothing about.

So how did it go?

First, I will say that I really, really enjoyed this challenge.

Over the course of September, I created 21 playable prototypes based on NPR’s top headline of the day. For each day, I created a one-pager that listed the key parts of the news item, as well as the setup and play instructions for the game I created. I published the one-pager and some pictures I took of my playtesting sessions in Twitter threads, partly to indicate to myself that I finished the day’s exercise but also to encourage others to do something similar.

At least one person posted their own playable video game prototype!

One-pager for daily game design

Playing cards used for daily game design

Here’s the links to those Twitter threads if you are interested in seeing them and the quick analysis I did after many of them:

I made games about indigenous representation in the U.S. Congress, about the need for young farmers, about housing issues for teachers in California, about student loan forgiveness, and the politics of clean water in Jackson, Mississippi.

I made games about monkeypox vaccination and about wearing masks during the ongoing COVID-19 pandemic.

I made games about the death of Queen Elizabeth II, who gets her dogs, and the nations that won independence during her reign.

I made a game about restrictions on safe and legal abortion access, and about the migrants treated inhumanely to make a political point.

I made games about the effects of the war in Ukraine, between a nuclear plant that needs to be shutdown safely and the gas sanctions affecting Europe and U.S. prices.

I made a game about Magnus Carlsen resigning after a single move in a rematch with Hans Niemann.

I made games about hurricanes in general and about Puerto Rico’s recovery from Hurricane Fiona in particular.

I made games about presidential term limits, about acquiring voting machines, and I even made a couple of games about the Mar-a-lago FBI seizure and the special master who was assigned to look at the documents.

Some of the games used a regular deck of playing cards, others used dice, and others used a variety of components, such as coins, tiles, wooden barrels, and pawns.

In fact, it was a great excuse to have my game design prototype toolbox nearby, after years of being mostly ignored. In fact, I even changed the contents a bit so that I could add a deck of cards, some dice, and even a minute sand timer.

My updated game design prototyping toolkit

And I decided to order The Infinite Board Game from Workman Publishing, which is basically a piecepack implementation along with a book explaining some of the games you could play with the components. I would have preferred high quality wooden components, but plastic works well enough.

Pieces from piecepack used in daily game design challenges

Now, you don’t strictly need all of these components, but I loved the variety and the ability to choose from day to day what I was going to use.

What didn’t go so well

September has 30 days, but I only made 21 prototypes, so what happened to the other 9 days? Well, I fell behind.

And despite trying to do two or more designs in a given day to try to catch up, it was difficult to do so, mainly because I frequently took more time than I originally hoped I would.

I timed myself once, and it took me 1.5 hours to go from nothing to my published Twitter thread. And I know some of the challenges probably took me much longer. If my actual maximum time on any exercise would have been 20 minutes, I think it might have been much easier to have a game for all 30 days.

Which was fine, in that I didn’t care too much about sticking to 20 minutes. More time spent on game design meant more practice and more benefit to me.

But it definitely ruined the whole “won’t interfere with my daily routine” part. By the second half of the month, I found I did nothing in terms of writing or game development outside of these exercises. In fact, on days when I tried to do more than one exercise to catch up on my backlog of NPR headlines, I found that it got in the way of other routines and habits, like reading or going to bed at a decent time, which had cascading effects on my ability to wake up on time the next day. This situation wasn’t sustainable.

Perhaps 20 minutes was ambitious. Strictly speaking, I might have had a 1st iteration within a few minutes, but my 1st iteration always felt too simple, or it had no connection to the news item, or otherwise it needed work before I felt good enough about it to “publish” it.

Another thing that didn’t go well is that news headlines can sometimes get repetitive.

What makes the news might stay in the news. Hurricanes, political scandals, and the deaths of long-living monarchs tend to dominate the news cycle for multiple days or weeks, and at least once I skipped the top headline to choose another one that covered a theme I hadn’t already worked upon.

And sometimes the headline news is depressing. While I felt like I was paying more attention to the news thanks to this exercise, sometimes doing so felt like getting punched in the stomach. Making a game about how Florida’s governor tricked migrants onto planes and knowingly sent them to areas which did not have the resources to help them? It was my least favorite part of this experience (and probably my least successful design).

Don’t get me wrong. While I imagine many people think of games as “for children” or only for fun, you can definitely make games that model serious situations. My discomfort with confronting the news pales in comparison to the real harms inflicted on human beings who were treated as political pawns.

But even though I anticipated bad news being an occupational hazard of this exercise, I don’t know why I didn’t expect to have my heart broken by witnessing how awful people can be to each other.

Of course, maybe having experience creating games that reflect the real world even when it is ugly isn’t such a bad thing.

Things I learned

In just one short month, I learned a few things that I will carry into my future game design efforts.

  • For quick iterations, I should use fewer components and/or a smaller scope.

    For my first game design exercise, also documented in my Daily Game Design Practices post, I used the 66 cards from the game Iota. In hindsight, it was a mistake.

    It was a bit unwieldy and might have obscured the dynamics because I was simultaneously dealing with figuring out my rule changes AND with the existing how it interacted with the sheer quantity of shuffled cards.

    When I had what seemed like an interesting set of rules, I ran into the problem of the game not ending satisfactorily and being too random, so some games were over almost right away and some took forever to end. Having fewer cards might have helped me iterate more quickly.

    I found that I struggled the most when I used an entire deck of playing cards (more on that below), whereas if I used a subset of the cards, I was able to produce and iterate on designs much more quickly.

    For my non-card games, I found that I still had too much going on. Either the playspace was too large, or there were too many components needed.

    For my game about Magnus Carlsen and Hans Niemann, I was originally planning on using an entire chess board, but I opted to use a smaller board, and I think it was a much better exercise as a result. I was able to quickly play out entire sessions within seconds rather than minutes, modifying rules, and repeating.

    When I think about computer games I’ve made in the past, they tended to be on the large scale. An early RPG prototype I made in QBasic had a massive overworld map, and the individual screens had a lot of tiles, and each town/cave/castle was similarly potentially huge. It was so big that in order to test the entire game more easily, I added a special cave that allowed me to instantly appear at key parts of the world, doing what the kids today call “Fast Travel”. I never finished that game, despite having a fully functional dialogue system that let you talk, buy, sell, or steal (or be stolen from) and plenty of created areas to explore complete with residents. Of course, this description is probably more exciting than the not-quite-a-game actually was.

    My leaf-raking business simulation game Toytles: Leaf Raking might have too many residents/yards, and the game takes 3 in-game months representing the fall season to play but perhaps it is too long. I had one player tell me that there isn’t much to do to fill up that time. I wonder if the reason why Harvest Moon games tend to have a 6 day week instead of a 7 day week is because it allows the pacing to move along more smoothly.

    Similarly, one of the design decisions that I wish I had spent more time on was figuring out what dimensions to make the levels in my non-violent tower defense game Toy Factory Fixer. Maybe larger, easier-to-see graphics with a smaller play area would have worked better? It’s hard to say after the fact, but there were a few times when I was creating the levels that I thought that there wasn’t enough content in the game to justify the potentially long conveyor belt. Players seem to like the game, though!

    But I think my future game designs might start out with fewer moving parts, at least to start, mainly so I can get through iteration cycles much faster.

  • Don’t write down the rules until the end

    I quickly discovered that writing with a pen to create the one-pager for a given design made edits painful and ugly. Crossing out or modifying the instructions did not go well, especially if I didn’t provide enough white space or already used the margins for a previous edit.

    This lesson might be too specific to the fact that I chose to create a one-pager on paper and wrote with a pen. Maybe if I used a digital text file it wouldn’t have been so bad.

    But then again, my iterations were completed on the order of moments, not days or weeks, so I didn’t need to spend time writing down the rules until the very end.

    Not having calcified rules gave me the freedom to make up rules on the fly, which is very useful when I run into an edge case while playtesting. And those edge cases came up often because there are almost always situations not covered by the few rules a game starts out with.

    Basically, I didn’t want to accidentally constrain my designs due to not wanting to try to squeeze text modifications on paper. B-)

    If I could try to extrapolate out a larger lesson, perhaps it means I should also try to spend more time in pre-production before calcifying the rules in a computer game. It is a lot easier to iterate the rules in my head than it is to iterate rules compiled into an executable.

  • I was able to recognize my tendencies as a game designer.

    The fact that I was done with a design each day meant that each day’s efforts were easily compared to the previous ones.

    And I noticed that I might often start with trying to represent more than I needed to. For instance, when I was making Gas Sanctions, the game about the effects of the war in Ukraine, I originally wanted to represent population as well as their energy needs for each region of the world. I ultimately simplified energy demand to a die roll and removed the population concept entirely.

    My card game about Queen Elizabeth II’s corgis, Who Gets the Dogs?, didn’t end up how I intended no matter how long I worked on it that day. I wanted the game to be about gaining favor with the Queen before her death, and I tried to have multiple potential dog owners represented by individual cards. Eventually I changed it to be the column in which you are playing cards, mainly so I didn’t find myself needing the card acting as a token in the course of play.

    I generally wanted to make games with a lot of player agency, and so I often set out to use as little chance as possible, and when I played with dice, I found that I preferred to use the results of a die roll to inform things indirectly. That is, while some games might have allowed a die roll to dictate how far a pawn might move, other games required the player to choose how to apply dice rolls to the situation.

    Unfortunately, what often happened was that I ended up making a game with very little player agency partly due to a lack of a real choice. That is, balance was often not my main concern, and so when I decided to be done enough for a daily exercise, I might feel like the game offered no real choices. There was an obviously best move, which made it the only move.

    Perhaps I can learn to lean on randomness more, or I could practice more to find out how much work there might be to make better choices for the player that are true choices.

    But I definitely liked to try to model causes rather than effects, yet found that focusing on effects resulted in faster iterations. Can I start with modeling effects, then work backwards to mechanics that model causes? It’s something I would like to experiment with.

  • I was able to make a game even when I thought I wouldn’t be able to do so.

    Each day, I didn’t know what headline I would get. Sometimes the news item was about a natural disaster, or about political maneuvering, or about contention over resources. Often I found these items mapped to a game quite easily.

    But other news items were less about conflict or dynamics. Sometimes they were background information. A explanation of someone’s career as a judge or the history of presidential terms limits don’t sound like playable things. And whenever I ran into such a news item, I despaired slightly.

    And yet, I kept surprising myself by making playable games about them, and often quite quickly!

    I found that just the act of doing created results.

    That isn’t to say that those results were amazing. I still struggled, and some of those published iterations have a lot more potential than anything else, but I was not grading myself on how good a game I could come up with. I was grading myself on coming up with anything at all, on putting in the time to do the work.

    Basically, I showed up to the task, put something out there, and moved on. And I was better for it.

  • I need to get more familiar with my game design tools.

    I focused on creating paper prototypes because they are quick. Some of the game components I have at my disposal have centuries of history behind them, such as playing cards. But I didn’t have centuries of knowledge at my fingertips.

    Now, I’ve played card games since I was a child. I’ve played a variety of games.

    But in some of the exercises, I found myself struggling to make the cards do what I wanted them to do.

    Playing cards have suits, ranks, and colors. You can make all sorts of rules using them.

    Yet I felt like I was limited with the mechanics I came up with. The player could match ranks. The player could try to play a higher or lower card than what is on the table. I could borrow solitaire rules. I even found myself using the rectangular shape of the cards, turning them to the side to indicate something.

    I imagine that there are countless other things one can do with cards, mechanics that other games already use, and I wasn’t creative enough to come up with any in a quick session, nor did I have a lot of past experience to leverage.

    Similarly, dice are fun to roll, but often I found myself feeling like I wasn’t applying them well.

    To be fair, I was familiar enough with the nature of randomness with these different tools. You can always reroll a value with dice, while a card dealt is no longer in the deck.

    But what to do with the rolls or the card was a question I wish I had more answers for.

    I should play more games, is what I am saying. B-)

What now?

Actively doing game design every day might be a normal thing for some full-time indies, but it was a new experience for me. I believe I gained a lot out of this experiment, which makes me wonder how much my game design abilities might change if I did this exercise every day for an entire year.

But something needs to change to make it possible for me to do so. When it takes me multiple hours to work on a single game design, those are hours I can’t use for my game development in general, and most days I don’t give myself more than hour in the first place.

Sometimes when I imagine/fantasize being a full-time indie game developer again, I think about what my day to day might look like if I didn’t have a day job. Could a daily game design exercise be a great way to start the day before getting to the “real” work? Or a nice ending to a solid day of development?

Can I get a similar benefit doing one game design a week, such as dedicating Mondays to the task? Or using an entire week of 20 minute days to work on a single game design, with a published post on Saturday?

I’ll need to think on it, but for now, I need to get back to my neglected very, very part-time efforts.

I will say, however, that I wouldn’t have minded hearing from someone at NPR seeking a full-time game designer in residence whose job is to create a daily game to play based on that day’s headlines…

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Toy Factory Fixer Updates Finished, Toytles: Leaf Raking Is Next

In last week’s report, I was delayed in my ability to create and publish a new update of Toy Factory Fixer for iOS and Mac due to MacOS and Xcode taking so long to upgrade at the end of the week.

This past week, I focused on finishing my update and started work on the desktop ports of Toytles: Leaf Raking.

Sprint 74: iOS update

Planned and complete:

  • Create updated SDL2 libraries for iOS

Now that I have Xcode 13 up and running, I found that to build the latest SDL2_image, I needed to use the tip of the branch from GitHub rather than the latest officially released version (2.6.2). It’s a little annoying, but oh well.

Once I got the SDL2 libraries built, I could build the app, test it in the simulator and on my actual iPhone, and then submit it to the App Store.

And you know what was a nice surprise? Within moments, it was reviewed and available!

Meanwhile, I was still waiting for the Google Play review to finish, which finally happened after about a week.

So now Toy Factory Fixer v1.0.2 is officially published everywhere for Android, iOS, Windows, Linux, and Mac.

Whew!

Now I will stop looking at Toy Factory Fixer and start paying attention to Toytles: Leaf Raking’s desktop porting work.

Sprint 2022-1: Desktop ports; new mobile requirements

Planned and incomplete:

  • Create updated SDL2 libraries for iOS
  • Create itch.io page
  • Create Linux port
  • Create Windows port
  • Create Mac port
  • Update Android port with new Google Play requirements

Unplanned and complete:

  • Add button sounds to main menu for consistency

Technically, Toytles: Leaf Raking isn’t part of the Freshly Squeezed Entertainment line of games, but rather than create a separate blog post for From Concentrate, I’ll just piggyback on this post.

I haven’t updated Toytles: Leaf Raking since exactly a year ago, and I started by figuring out what differences there were between the CMake build scripts of this project and Toy Factory Fixer, then updating the scripts to match where it mattered.

I then updated my GBLib files, which are not quite a framework or engine so much as a bunch of code I’ve been writing, tweaking, and leveraging for all of my projects. I realized that this is the first time I had to put in significant effort to take my latest changes and backport to a previous game. The main changes were related to animation and sprites, so nothing too substantial, but when I get a third game and need to support them all? It makes me wish I had GBLib as a separate versioned project.

Anyway, I didn’t want to spend time doing any substantial feature development, but before I added an in-game privacy policy (not exactly a Google Play requirement but that’s where it falls under), I was unhappy with some of the menu visuals. The main menu has a colorful screen, but the credits menu and the options menu had black backgrounds? It’s jarring and inconsistent.

Toytles: Leaf Raking

So I added some color to the background instead, and I think it is still readable. It’s not as crisp, but it contrasts enough, and it fits the game a lot better. And now that I think about it, I should increase the font sizes so that it is definitely easier to read.

Toytles: Leaf Raking old options screen

Toytles: Leaf Raking new and improved options screen

Another inconsistency that finally bothered me enough to do something about it? The main menu was silent. You click on buttons, and it doesn’t sound like anything happens, but in the game, clicking on buttons has a distinct sound.

So I added sound effects to all of the menu screens, and now the game feels a lot better.

And then I remembered that the ending screens are similarly not the same color as the rest of the game, so I changed it, too.

I didn’t start any of this work until Wednesday, and by the end of the week I had not worked on the privacy policy.

Once I do, I believe I should be able to quickly build the game for every platform since the scripts are so similar.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: I Just Wanted to Release a Small Update

In last week’s report, I finished making improvements that should help new players more easily understand what to do in Toy Factory Fixer.

For this past week, I didn’t even plan a sprint for Toy Factory Fixer, thinking that I would “just” publish this update and move on to finally porting Toytles: Leaf Raking to the desktop. Thanks to Apple and SDL2_image/_mixer/_ttf updates, it turned out that publishing an update for iOS wasn’t as straightforward as I was hoping.

Sprint 73: iOS update

Unplanned and Incomplete:

  • Create updated SDL2 libraries for iOS

I have been working on automating as much of my builds as I could for years, and so I anticipated that creating a new release of my existing project should have been almost no work at all, so I didn’t bother actually planning to make time for it.

And I was almost right. On Monday I was able to create a Linux and Windows update fairly quickly using my build scripts, and those updates are available on itch.io at https://gbgamesllc.itch.io/toy-factory-fixer.

I was even able to quickly build an Android version and submit it to Google Play for review, which is taking a surprisingly long time to get approved, but it was out of my hands also on Monday.

In any case, that’s three platforms I was able to quickly create a new update for.

Then, I tried to do the same for iOS.

But libSDL2, libSDL2_image, libSDL2_mixer, and libSDL2_ttf all had fairly substantial updates and I wanted to make use of the latest versions.

Well, libSDL2 builds fine, but the other three eliminated their Xcode-iOS projects, so now the only project available is Xcode, which…ok.

But it meant that a straightforward update to Toy Factory Fixer turned into a week of trying to refigure out how to build the project for iOS.

When I tried to build libSDL2_image, for instance, I used the following command:

xcodebuild -scheme "Static Library" -configuration Release -sdk iphoneos SKIP_INSTALL=NO BUILD_DIR=build/SDL2_image-iphoneos

And I got the following error:

error: ApplicationServices is not available when building for iOS. (in target 'Static Library' from project 'SDL_image')

ApplicationServices is a Mac-specific framework, which means that libSDL2_image was trying to build itself using a Mac build configuration.

It is entirely possible that I am trying to build this library incorrectly, and I couldn’t figure out how to use configure/make to more easily specify that it is supposed to be an iOS project.

Eventually, by the end of the week, I found that someone else was having issues with building the libraries and having a slightly different but similar problem.

And that’s when someone pointed out to me that the latest Xcode project updates for SDL2 require Xcode 13. I was still using Xcode 12.

And in order to upgrade to Xcode 13, I needed to finally stop putting off upgrading from Mac OS Catalina.

On top of it all, I needed to do these upgrades anyway, because the App Store requires any new submissions to be done using Xcode 13 anyway.

So I ended my week upgrading from Catalina to Monterey, which looked a little stuck at one point but finished relatively quickly, and then upgrading Xcode which took relatively forever.

Seriously, I don’t understand how long it could possibly take so long to install an Apple-official development IDE on an Apple-official OS. You literally just put files onto the machine, right? I mean, even if it is gigabytes worth of files, what was it doing for hours? From experience, I knew to check to see if it was hiding a dialog box somewhere waiting for me to click Accept or login or something, but I couldn’t find any such thing. I just had to wait.

And by the time it was finished, I ran out of time to take advantage of the upgrades and/or see what changes Apple made that would break my process and build scripts, but I think that since the Github issue was closed recently it means someone else was able to successfully build the libraries just fine, so I hope all will be well with my progress early this coming week.

And if all goes well, then I hope the iOS and Mac updates will get released quickly, so I can finally, finally work on porting Toytles: Leaf Raking leveraging all of this work, too.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Improving the New Player Experience

In last week’s report, I was slowly putting together updates for new Google Play requirements and anticipating some work to improve a new player’s experience in Toy Factory Fixer.

I continued the work last week.

Sprint 72: New player onboarding improvements; Google Play requirements

Planned and Complete:

  • Update Android port with new Google Play requirements
  • Make new player onboarding smoother

Unplanned and Complete:

  • Highlight craftable toys in inventory

While I only worked a little more than 5 hours throughout the entire week, I was able to get quite a bit accomplished.

I finished adding the privacy policy into the game. I have in-game help pages, and I reused that code to also add the in-game privacy policy. Most of that work was in the previous sprint, so I basically needed to add the copy and make sure it worked properly.

Toy Factory Fixer in-game privacy policy

Next, since I’ll be putting out an update soon anyway, I wanted to make it easier for new players to know what to do at the beginning of the game.

Watching strangers play my game at 60 FPS Fest weeks ago, I noticed that at the start of a new level, players wouldn’t immediately know to click on the Hire Worker button, which is one of the only buttons that is currently available.

In hindsight, a new player wouldn’t know what part of the screen is interactive or relevant, so they had to take in the entire screen and try to make sense of it all. The Hire Worker button is a relatively small part of that screen, and it is not obvious that it is one of only three buttons that are available AND that it is the only one that is necessary to start playing.

So I added something that I hope won’t be too subtle:

Toy Factory Fixer new player onboarding improvements

Originally I was going to add some text next to the cancel button that said “Hire your first worker” but I thought it would have been easy to miss, and it also wouldn’t appear if the player canceled and got back to this main menu:

Toy Factory Fixer new player onboarding improvements

Once you hire your first worker for the level, then the giant text and arrow goes away.

I keep thinking of other improvements, but they’ll have to wait.

The other observation I made was that new players would often hire workers, then watch the workers separate Bad Toys into parts, then…continue to watch.

It would be nice to have a full-fledged tutorial with triggers to show the player what to do next, but in the absence of that kind of work, I hardcoded something for the first level only.

Basically, if it is the first level, and you haven’t commanded a worker to craft a Good Toy yet, and you have enough toy parts to craft a Good Toy, then you’ll see this also not-so-subtle hint:

Toy Factory Fixer new player onboarding improvements

I decided to add a highlight to the inventory UI, which I hope makes it easier to see when you can start crafting toys in the middle of a more hectic level. It is much more subtle when on its own, but I think it is still helpful.

Toy Factory Fixer new player onboarding improvements

And while trying to make this small change, I discovered a couple of memory leaks and fixed them, thanks to valgrind and my unit tests.

With these changes, I am hoping that when people download and try the game, they are less likely to uninstall right away.

I still need to do a bit more manual testing to ensure I didn’t break anything, but it has been a fairly error-free experience so far, so I expect to get the next release out pretty quickly.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Slowly Complying with New Android Requirements

In my last report a couple of weeks ago, I finished automating my Mac port work and also got some valuable feedback in the form of observing a number of random strangers play Toy Factory Fixer at a local festival.

I decided to incorporate that feedback into my next update as I prepared my app for new requirements from Google Play.

Sprints 70 and 71: New player onboarding improvements; Google Play requirements

Planned and Incomplete:

  • Update Android port with new Google Play requirements
  • Make new player onboarding smoother

As has been mentioned in mobile news, both Google and Apple have policy updates that basically say something like “Update your app, or we’ll remove it from our app store.”

For games that get frequent updates and new content all the time, it’s no big deal, but for games that are otherwise considered “finished” by their developers, it’s basically forcing work to ensure the game stays available for players despite the fact that the game would otherwise run just fine.

In my case, the main update I need to do for the Android port of TFF is to change the target SDK, and I figured that I might as well use the latest SDL2 libraries as well.

There is something Google requires related to privacy policy updates, but as my game doesn’t make use of anything that requires such disclosure, it might not apply to me.

Unfortunately, it wasn’t very clear. I had emails announcing the policy changes that said one thing, an Android developer page that said something slightly different, and the actual Google Play policy that said another.

But basically, I felt that I needed to provide my privacy policy text inside the app, not just on my website linked from the Google Play store page. I could just link to the page, but it felt like an app that doesn’t require much should just be able to tell you upfront what it is and isn’t doing.

After almost two weeks, I’m almost done with that work. That’s a long amount of clock time, but it represents very little actual development time. Between going on a short weekend vacation with my family and my father-in-law passing away as we were returning, much of my time these last couple of weeks has been spent tending to family matters.

I expect that I will eventually get the main requirements done, and then I can work on making it easier for new players to know what to do, especially when it comes to hiring the first worker and knowing to command workers to craft Good Toys from parts.

What I hope is that those improvements mean that I’ll see fewer people uninstalling the app in my Google Play and itch metrics.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Mac Port Automation Finished, and 60 FPS Fest

In my last report, I mentioned how my back pain was preventing me from making substantial progress in the previous few weeks, and that I was working on automating my Mac port build for Toy Factory Fixer and needing to prepare for a festival.

I continued to do the work as my body let me.

Sprint 69: Ports

Planned and Complete:

  • Automate Mac port

I have been able to sit at my desk for longer periods of time, and so I was able to be a lot more productive than I have in weeks.

I managed to update my libSDL2 libraries so that they could be found properly by my project, but I struggled for some time trying to get CMake to configure my Xcode project so that it would embed and sign those libraries.

SET_TARGET_PROPERTIES(${GB_PROJECT_NAME}-bin PROPERTIES XCODE_LINK_BUILD_PHASE_MODE KNOWN_LOCATION)

This line seems to be needed to get the libraries that are found with FIND_PACKAGE to show up in the “Frameworks, Libraries, and Embedded Content” section of Xcode. But they would be listed as “Do Not Embed”.

SET_TARGET_PROPERTIES(${GB_PROJECT_NAME}-bin PROPERTIES
    XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY ON
    XCODE_EMBED_FRAMEWORKS "${SDL2_LIB_DIRS}/libSDL2.dylib ${SDL2_LIB_DIRS}/libSDL2_image.dylib ${SDL2_LIB_DIRS}/libSDL2_ttf.dylib ${SDL2_LIB_DIRS}/libSDL2_mixer.dylib")

I found a number for forum posts, pull requests, and pieces of CMake documentation, and I felt pretty frustrated that I couldn’t get things to work properly. I made sure to have the latest version of CMake so I had the ability to set XCODE_EMBED_FRAMEWORKS and work with dylibs, but when I did the above, all I got was libSDL2_mixer to show up as “Embed & Sign” while the rest continued to be appear with “Do Not Embed” instead.

I found that no matter how I specified everything, it was always the last library in the list.

Well, luckily, someone runs a great account on Twitter, so when I was frustrated enough to end my day by complaining about my situation, I got a reply that helped me learn more about CMake:

Lists are semicolon separated?!

Now, I’ve used CMake for years, and the documentation has always felt a bit obtuse to me. It is very much a reference document and not meant to be a tutorial.

But I have never known that lists were semicolon separated before.

I mean, even the unit tests for this feature don’t feature semicolon separated elements of a list. They are separated by spaces.

But someone on IRC told me that “Semicolon separated lists is how CMake does lists. It automatically adds the semicolons if you don’t quote your items.”

So the following examples would work out in this manner:

foo bar baz --> "foo;bar;baz"
foo "bar" baz --> "foo;bar;baz"
"foo bar baz" --> "foo bar baz"

So I took some deep breaths to calm myself down, and made the following change:

SET_TARGET_PROPERTIES(${GB_PROJECT_NAME}-bin PROPERTIES
    XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY ON
    XCODE_EMBED_FRAMEWORKS "${SDL2_LIB_DIRS}/libSDL2.dylib;${SDL2_LIB_DIRS}/libSDL2_image.dylib;${SDL2_LIB_DIRS}/libSDL2_ttf.dylib;${SDL2_LIB_DIRS}/libSDL2_mixer.dylib")

And now all of the libraries show up as “Embed & Sign” like I wanted. Nice!

On a separate note, I learned that properties in CMake similarly have some flexibility in terms of what arguments can be provided.

So I have seen XCODE_EMBED_FRAMEWORKS_CODE_SIGN_ON_COPY take the argument ON in unit tests, TRUE in forum posts, and YES in examples I found on GitHub. And they are all correct, apparently.

One last thing was that I wanted to make sure I could build a release version in Xcode, but the default was Debug. Basically, I wanted to create a release by merely building the project, rather than needing to do a separate archive step.

When creating Makefiles, you can use CMAKE_BUILD_TYPE with arguments as Release or Debug, but Xcode needs you to use CMAKE_CONFIGURATION_TYPES instead.

Of course, I found that even when doing so, the release build it creates is a little different in size from the release build that gets created when using the Archive functionality of Xcode, so it might be a moot point.

Anyway, after I got the Mac port automation done, I wanted to leverage it to create the desktop ports for Toytles: Leaf Raking, but there was a game festival I needed to do some last-minute preparations for.

Last Friday, I had a table at the 3rd 60 FPS Fest, and it was gratifying to hear the first player, an 8-year-old, say, “This is definitely a fun game.” B-)

Toy Factory Fixer at 60 FPS Fest 2022

He also had a lot of ideas for how to make the game better, so I wrote some down. Thanks, Rowan!

One of my favorite pieces of feedback was hearing someone laugh about the toy parts getting “yeeted” to the inventory.

Toy Factory Fixer

I will say it was a bit humbling to see the number of people who struggled to know what to do when they started playing. I know I worked on tweaking the interface to funnel new players to what they needed to do, such as making the START button huge and obvious, or setting the default menu to the Hire Menu so you immediately know you need to hire someone. I also made the workers flash to indicate that you can tap/click on them when you have enough toy parts in inventory to create Good Toys.

And yet, it was very obvious as I watched new players struggle that I still had some work to do to make it more intuitive and easier to figure out how to play the game. Clearly whatever I’ve done so far is too subtle. I especially felt bad when a player felt incompetent or “bad at games” because it felt like a failure on my part to make it enjoyable from the beginning.

So the festival was a successful one, if only because I learned some ways to improve the game, especially for people who won’t have me standing next to them to help when asked. I also got some positive feedback from a number of new fans, including parents who were looking for non-violent, family-friendly entertainment that they could trust.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report: Back Injury Setback, Automation Work

In my last sprint report a couple of weeks ago, I managed to get the Mac port of Toy Factory Fixer published and working properly with music.

I set out to automate some of the Mac port work that had been manually done before.

Sprints 67 and 68: Ports

Planned and Incomplete:

  • Automate Mac port

I mentioned that I hurt my back a couple of weeks ago. I don’t know what I specifically did, other than contort myself earlier in the week to fix a leak under the bathroom sink, and I have not been as diligent about my yoga routine recently. I might have been putting strain on my lower back by leaning forward a lot as I read or worked at my desk, or maybe I was leaning forward because I was already uncomfortable sitting and didn’t realize it.

Either way, I have not been able to comfortably work on anything for a couple of weeks.

Which is frustrating partly because I have been trying to take care of my back so that I didn’t have setbacks like this anymore, and partly because I am getting antsy about moving on to porting Toytles: Leaf Raking and wanting to work on my next project.

Also, 60 FPS Fest is this coming Friday, which is a gaming festival that is free and open to the public, and I will have a booth there. I participated in the first two iterations of the Fest, and I look forward to being part of this one. I was hoping to have a new game in development that I could show off, but it is not looking likely.

Still, it will be the first time I get to show off Toy Factory Fixer in a public venue, and being able to tell people that Toytles: Leaf Raking is available on more platforms will be great as well.

Anyway, I finally had the ability to sit for more than a few seconds without pain, and so I was able to get some automation work done on Toy Factory Fixer’s Mac port, which means that I am that much closer to automating Mac ports generally. Basically, I created a build script that builds the libSDL2 libraries and updates their internal install directory to point to “@executable_path/../Frameworks” and then spent time trying to figure out how to tell CMake to generate an Xcode project that can refer to my custom libraries in the General > Frameworks, Libraries, and Embedded Content section.

Toy Factory Fixer Mac Port

I’m still in a bit of pain, especially when I stand up after sitting for a length of time, but I seem to be getting better each day.

I think getting prepared for the Fest this week should be no problem, assuming I don’t have a setback on top of my setback.

Thanks for reading!

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 the 19-page, full color PDF of the Toy Factory Fixer Player’s Guide for free!