Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – More Worker and Inventory Animations

Last week, I reported that I focused on enhancing the workers by animating their arms, which helps make Toy Factory Fixer just a little more enjoyable to play. I wanted to continue making the workers more interesting in the next sprint.

Sprint 33: Worker polish and training levels

Planned and Completed:

  • Move toy parts towards inventory

Planned and Uncompleted:

  • Make worker eyes follow to nearest toy on belt
  • Create floor training levels/tutorial

A big part of what the workers do is separate Bad Toys into parts. I had the toy parts merely fall off the bottom of the screen, but the inventory count on the right would increase. Yet, it was not very clear that there was a connection.

So I fixed it. Toy parts now fly from the worker’s hands to the inventory, making it clearer that the parts are added to the inventory.

I even animated the icons in the inventory so that you knew which ones were getting increased.

And I made the toy parts rotate because everyone loves things flipping through the air.

Toy Factory Fixer - throwing toy parts at inventory

I decided to try adding particle effects, because why not?

I wanted to create a cartoony cotton fluff to represent the stuffing coming out of the toy parts, but trying to draw them from real references was awkward. I ultimately ended up looking at Winnie the Pooh and the Honey Tree.

But my cotton fluff looks more like a dust cloud, especially since it fades over time. I’m not entirely pleased with how it looks, and so I think I’ll change it.

Ultimately, I spent all of my time on getting the toys to move to the inventory and getting things to animate that I didn’t get to other worker enhancements such as eye movement. The arms move, but they still look dead inside, and I would like to make them look more emotional.

But more importantly, and perhaps in hindsight what I should have been doing for many months, I need to focus on creating levels.

I’ve been tweaking a few things as I have been play testing, especially once I added the new worker types a few weeks ago, but I need to create a few solid intro levels.

In the meantime, I’ve gotten more play tester feedback, and some of the things I want to do to address that feedback seems critical for a first public release.

It feels simultaneously like I am so close to creating that first publishable version and also so far away because it takes me weeks of part-time effort to do what would probably take me mere days if I was focused on it full-time.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Worker Animations

In last week’s sprint report for Toy Factory Fixer, I added new worker types.

I continued to focus on the workers last week.

Sprint 32: Worker polish and training levels

Planned and Completed:

  • Animate worker putting down toy

Planned and Uncompleted:

  • Make worker eyes follow to nearest toy on belt
  • Move toy parts towards inventory
  • Create floor training levels/tutorial

After adding some simple yet effective enhancements to the toy movement that I thought made the game a lot more enjoyable to experience, I thought it seemed odd that the workers continued to stay stationary, so I thought I should do something.

Early in the week I managed to separate the arms from the workers, and I created a way to rotate the arms based on time relative time it takes for a toy to move.

But first, I had some fun with them. You know, to test it out:

Toy Factory Fixer - worker arm animations

Ultimately, I ended up creating a specific motion for the arms to flip toys into the air, which works for both throwing separated toy parts into the inventory and throwing a crafted Good Toy onto the conveyor belt.

Toy Factory Fixer - worker arms animated

Before I could work on anything else, I found that there was a strange flicker with the arms that occurred if there were multiple workers. It took a bit of investigation, but the arms animate if the worker has finished either crafting a Good Toy or separating a Bad Toy. Crafting and separating happen at the same time, but toy parts will go into the inventory first, then Good Toys will be thrown onto the conveyor belt.

All well and good, except I reuse the same variable to manage a timer to move toys in each step, and I reused that same timer to manage the rotation of the arms.

Now, each step only occurs if it needs to. That is, if there is no worker putting down toys, then those sequences and the use of the timer for those sequences won’t happen.

So when you have one worker, or when you have multiple workers who all finish separating toys at the same time, nothing goes wrong, but when you have multiple workers who aren’t doing the exact same thing at the same time, then the timer, which governs the rotation of the worker’s arms, rotates the arms during an irrelevant step. It was too easy for things to go wrong due the overuse of a single variable.

So, for example, a worker who just finished separating toys will launch the toy parts into the inventory, raising their arms and lowering them back down based on the same timer that is moving the toy parts into the inventory. But then that same timer starts over for the next phase, and so that worker will raise their arms again even though they shouldn’t.

In the end, I ended up adding more states for the worker to represent when they “celebrate” finishing the job of separating or crafting a toy, and it made it easier to manage. The arms only animate when the worker is in one of those celebration states, and immediately after that animation ends, I change the worker’s state so that they don’t animate the arms anymore.

The next thing I started to look at was changing what happens to separated toy parts. Currently, they fall offscreen, but I think it would be more intuitive if they were thrown at the inventory on the right side of the play area. So a small bear head would get thrown at the small bear head inventory icon, and perhaps it would animate to really make it clear that the small bear head quantity is going up.

It turns out that it would take quite a bit of work to change the static inventory widget that only redraws when there is a potential for the inventory numbers to change, and I ran out of time to work on it this past week. I expect to get it done early this coming week.

I didn’t purposefully mean to do any work on creating the training levels, but between having new worker types and testing their animations, I ended up playing through a few different sessions and figuring out that I actually have a fairly enjoyable game coming together, even with it being unbalanced. I need to create a solid set of levels before I release it to the world, but it’s exciting when you realize that you got distracted from testing something because the game itself distracted you.

Thanks for reading!

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

Categories
Game Design Games Geek / Technical

Books I Have Read: The Works of Ian Bogost

A couple of years ago, I purchased a number of books by Ian Bogost, the game designer, author, and professor who also created the parody game Cow Clicker and one of my favorite things on the Internet: buns.life, which lets you put words between buns.

I read some of Ian Bogost's Books (words in buns)

I can’t remember why I decided to buy multiple books by Bogost at the same time. I imagine it was because Racing the Beam was on my wishlist for a very long time, and when I finally decided to get it, I thought, “Yeah, I could stand to read more books about games.”

I finally got around to reading these books recently. In fact, I read each book within a week before moving on to the next, so I felt I got quite immersed in Bogost’s world in a little over a month. I could trace lines of his thoughts as they evolved over time and also recognized the same references he makes across multiple works.

Here are some brief thoughts on each.

Racing the Beam

Racing the Beam

Racing the Beam: The Atari Video Computer System, co-written with Nick Montfort and published in 2009, was a joy to read as someone whose first experience with video games was my family’s own Atari 2600 that I still have in my possession.

The book covers both the technical details of the Atari VCS, what I always knew as the Atari 2600, as well as analyzing how it impacted what kind of culture was being created by the developers who worked on the games for it.

I learned a lot about the history of Atari and the people involved in it, the reason why games worked the way they did for this platform, and how the system was flexible enough that it allowed for such a wide variety of games to be made for it, way beyond what could have been expected when it was designed.

There were times when I wished to dive even more into the technical details of how the system worked, but what was provided was probably deep enough for the target audience. Besides, I am sure there are actual manuals and guides for that kind of depth.

But I also enjoyed reading about the Atari 2600’s place in terms of the time period, the market, the politics, scandals, and more. I liked the insight that came from what were seen as poor quality arcade ports in terms of what it takes to make something successful as an adaptation. I liked learning about the names of the people behind some of my favorite games for that system, as well as learning more about the constraints they worked their magic within.

Despite diving into the details of a piece of hardware, I found this book to be one of the more accessible ones to this non-academic.

It’s also part of a series at MIT called Platform Studies, and I know I have copies of a few of those books thanks to Humble Book Bundles, so I look forward to diving into them soon.

Unit Operations

Unit Operations

While I found Racing the Beam to be accessible, I found Unit Operations to be a challenging read. I felt smarter within a few page partly because I had to look up a few words because the rest of the sentence or paragraph that they were encountered didn’t seem to give me enough clues to their meaning.

This was a book written for an academic audience. I had to work for it, and I’m glad I did.

Unit Operations has a copyright date of 2006, and if I managed to successfully understand it, it was Bogost’s attempt to create a grand unifying theory of criticism that would work for not only games in particular and computation in general but also cover typically criticism-comfortable ground such as literature and poetry and film.

This book covered everything from philosophy to art to computer science to psychology to film and of course games.

Much like with Racing the Beam, I enjoyed the placing of context of different pieces of work. I happened to listened to a course on Western philosophy a few years ago, and so I was able to get references to major thinkers and writers.

As for a unit operation, well, my understanding, which might be wrong and not nuanced enough, is that a unit operation is a “thing that has meaning.” Specifically, a thing that can be combined with other things and understood with its relationship with those things in that specific combination.

That “thing” can be a cog in a wheel, or the wheel itself, or the concept of machinery in general. Bogost talks at one point about object-oriented software You can write a piece of code as a component of a larger system. Maybe that system is a component of an even larger system. But each component can be understood both in isolation and as part of the system it operates within. And the components work together differently if they were combined in a different way. The components in a particular configuration allow for certain operations and meaning-making. I wasn’t sure if I followed his understanding of “object technology”, but the general idea of procedural meaning seemed to make sense.

He talked about the Baudelaire poem “A une passante” which “expresses a unit operation for contending with the chance encounter.” It’s love poetry about the fact that the woman walking away in the busy and modern Parisian atmosphere will never be someone the author will meet. Walter Benjamin named this idea “a figure that fascinates” as it isn’t about the woman so much as a lost chance at connection.

Baudelaire was trying to figure out how to make sense of this new modern city life. This chance encounter idea was kind of new. The loneliness despite being among so many people was new.

Decades later when Charles Bukowski wrote “A woman on the street” it similarly was about that figure that fascinates, that lost chance to connect. Bogost argues that this concept went from being a novel experience to a meme-like cultural understanding. In a way, everyone understands this concept now, as everyone knows what living in modern society is like, and so instead of needing to describe it in detail, you can use shorthand.

It became a unit operation, a way to help us understand the meaning behind it all.

And then Bogost explored how it applies to The Sims expansion Hot Date, exploring the unit operation in the simulation that the game provides of modern urban living.

And the book was filled with similar analysis across multiple types of media.

I think one major takeaway I got from Unit Operations was the idea of simulations, and games in particular, being necessarily subjective. Bogost’s definition of a simulation focuses on the gap between what the simulation represents and what the user brings to understand it.

But I think that in light of complaints by some gamers that politics should stay out of games, I think it is interesting that there is this idea that all games are necessarily political because the game creators had to decide what to simulate and what not, what to put in and what to ignore, what to model and what not to.

I think I am glad that I read this book now as opposed to when it was released, because I don’t think I would have understood nearly as much. I expect that if I reread this book in five or 10 years that I’ll pick up some nuances or learn that I completely misinterpreted an aspect of it that I would grok much better then.

But I really appreciated how this book brought together so many seemingly different subjects. I find I can be fascinated by anything, and this book put a lot of anythings within easy reach and allowed me to see them all next to each other in a very satisfyingly holistic way. I remember finishing it and thinking, “I wonder how often unit operations will come up in other works” but I did not see them mentioned in his other books, and I wondered if it meant that the concept did not catch on.

How to Do Things with Video Games

How to Do Things with Videogames

In 2011, Bogost published How to Do Things with Video Games and explored the relevance of games as a medium by analyzing what spectrum of possible uses they can be employed.

I mean, you can play games, sure, but more than that, games can be used to make art, or to train, or to persuade, or sell, or exercise, or anything in between.

Each chapter explores one use that games have already demonstrated they are capable of. Rod Humble’s The Marriage usually comes up when talking about games as art, but there was a chapter about using games for politicking that touched on Bogost’s own work in creating a game for a U.S. Presidential election. There was one chapter on promotion that focused a bit on Burger King’s series of Xbox games, comparing it to similar efforts at promotion in the 80s and demonstrating that games have a long history of allowing people to do a variety of things with them.

I think one thing that struck me was that Bogost argues that games aren’t just for the stereotypical gamers anymore. The idea of the gamer will be as silly as the idea of the movie watcher. You just have people, and people might play games. A few years after this book came out, there was an ugly and sometimes violent backlash against women who wrote essentially the same thing. I don’t recall hearing Bogost getting the same vitriol thrown at him, but I could be wrong.

How to Talk About Video Games

How to Talk about Videogames

The next book I read was 2015’s How to Talk About Video Games, which addresses the idea that games, while different from other media, shouldn’t be treated as either special or less than.

Specifically, Bogost was unhappy with the idea of “games writing” or “games criticism” because it risks isolating games from the rest of the world. People can look down on games, and they can get away with it because society as a whole looks down on games.

In the intro, he says “This is a book full of … attempts to take games so seriously as to risk the descent into self-parody. Or even, to embrace that descent, since caricature is another means to truth.”

And it is here that I have to say, at the risk of offending Bogost, that multiple times in the previous books I thought to myself, “Ok, are we actually being serious here, or is this an elaborate joke?”

Around the time I was reading Unit Operations, I saw Bogost tweet “Sbarro Studies, Year One.” Clearly, THAT was a joke, but there were times where I fully expected it to be mentioned in the wide array of topics and subjects that the book addressed.

How to Talk About Video Games is a series of chapters that offer some kind of analysis or criticism about games or game publishers or the culture in which a particular type of game is popular.

My favorite chapter is the one about Ms. Pac-Man titled “Can a Gobbler Have It All?” It covers the pre-history of the game, going back to insights about the Atari 2600 again, the way arcade machine enhancement kits functioned both technically and economically, and finally argues that the creation of Ms. Pac-Man the game and the character has a deep connection to the roles women have in society.

Bogost admits that making parallels to the creation of Eve from Adam and to women who want to excel at a career and a family life seems absurd, but then proceeds to make a very compelling case by talking about how the game character was marketed, the story within the game, the origins of “Ms.” both as an abbreviation and as part of the title of the game, and more.

She is, after all, the first female lead in a videogame. Everything Pac-Man can do, she can do – and better. Her job is less predictable and more exciting, making it more challenging and rewarding. And yet Ms. Pac-Man is a traditionalist, a family woman willing to make a home with the right man – one whom she chases as much as he chases her – and a mother, able and willing to care for her Pac-progeny.

Bogost argues that the culture around games has fooled itself into thinking it is bigger than it really is. I am reminded of an article I once read in The Escapist when it was new and still trying to recreate a print magazine experience awkwardly on a web page, in which someone was surprised that there were gamers who didn’t read enthusiast magazines and websites about games. That people showed up at GameStop or Babbage’s and just didn’t know what the heck they were about to buy.

But there are a lot of people who don’t know inside baseball about the game industry, and it is easy to think, with an industry that has eclipsed Hollywood’s revenues, with more people playing games than ever, that it’s them who are weird.

I think the conclusion for Bogost follows from How to Do Things with Videogames, that rather than double-down on insisting that games are the most important medium of expression, and therefore marking them as different and special from the world, we can just live with games. There is no need to insist on the one true game that only gamers play. Games are for everyone, and there can be some games that appeal to only certain audiences, and games don’t need to be a sole focus, and that’s OK.

Play Anything

Play Anything

Play Anything, published in 2016, is one of the deepest dives into the concept of play that I’ve ever read. Which, as I already admitted I am not an academic, might not mean much, but still.

It also surprised me because it was about how to enjoy life, and as I turn 40 and keep an existential crisis at bay each day, this was an important message for me to receive.

I loved the beginning in which he talks about the modern popular use of irony as a way for people to avoid deciding whether or not they “mean to mean” something, as a way to avoid engaging with something to protect against disappointment or disaster.

Are you wearing that t-shirt of that brand as an expression of how much you like that brand or as a parody of people who would do that? With irony, you don’t have to choose. You can be neither of them. You can avoid what you are afraid of, which might be that brand betraying you by turning out to be a terrible faceless corporation after all, or that rejecting the brand isn’t very interesting.

So there’s an indecisiveness to engaging with things that comes out of fear, and our world today has a lot of things. Bogost argues that rather than hoping for something to be more than or less than it is, we can take it and accept it for what it is.

Perhaps the problem that afflicts us is not having too many possessions (or too few), or too many choices (or too few), but in failing to know how to treat anything with enough respect that its existence feels like an opportunity rather than a burden. And not an opportunity because we get something back from it or because we can put it to maximally optimized use, but because we can train ourselves to approach it for exactly what it is, rather than wishing it – or we – were something different.

The theme of treating reality honestly, of accepting what is, and of entering into relationship with that very real reality instead of trying to manipulate it into something it isn’t comes up a lot.

Play for Bogost isn’t compatible with irony, in which you hold things at a safe distance, neither accepting nor praising nor rejecting them.

Bogost argues that play is an inherent property of things. Irony’s position is that things aren’t going to be sufficient, and play’s position is that, duh, of course they aren’t, and that limitation in things is interesting and potentially enjoyable if you come at it the right way. Play is about doing what you want with what is there, and fun comes from exploring the possibility space there, especially when you think you’ve seen it all.

It’s not just mindfulness, about being aware of my own thoughts about them, but an awareness of everything else that isn’t me.

It’s about seeing things, really seeing them, paying attention to them, and doing what we can with them without being disappointed that they don’t offer something they can’t.

Conclusion

I felt a sort of kinship with Bogost. Here’s a person who also seems to love to explore a wide variety of topics, seeing and finding connections between different areas of study, and expecting to find that those connections exist.

As a game developer, as someone who is trying to create meaningful experiences through entertainment, I think I have gained a much greater appreciation for what is at stake, what the work involves, and how it relates to life in general.

I recognize certain modern debates as continuations of discussions that have been happening for centuries related to other media. I’ve found that my understanding of games as a medium has been grounded a lot more.

I think it is interesting to see how some things have borne out over a decade after he wrote about them, such as how relevant games are in politics or how the concept of the gamer is still alive and well despite the fact that pretty much everyone plays games.

And I think I’ve gained an appreciation for living a life in a way that I can appreciate living. People say life is short, that you should do what you love, that you can stop and smell the roses or practice gratitude or whatever. Maybe it is also due to the pandemic revealing a lot of the absurdities we as a society have tolerated needlessly and sometimes fatally, but I’ve found myself more and more seeing situations for what they are. While I can’t say I’ve found a way or motivation to play in a dysfunctional corporate environment or play in the misinformation surrounding COVID-19, I’ve given myself permission to have some agency in whether I participate in someone else’s constraints or my own.

Life is more enjoyable when it is honest and authentic, when you can explore the possibilities it provides, and when it is well played.

Categories
Games Personal Development

Teacher Streamer: Learn About Games and Their Classroom Potential

Last week was the Games for Change Virtual Festival 2021, and I learned about an attendee named Scott Beiter, a science teacher who also streams games on Twitch.

Specifically, every Wednesday this summer he is playing a different game and talking about its potential use in science classrooms on https://twitch.tv/sciencestreams.

Recently he played the games Red Planet Farming and Surviving Mars, obviously to explore the science behind the planet, and he talked about what his students experienced when playing through the games, how to get the games, and other logistics.

Most recently he has been exploring marine biology through games such as Subnautica: Below Zero.

I admit to not exploring a lot of his videos, and I wonder how many of these games end up amazingly adapted to classroom use as opposed to games that end up completely inappropriate or challenging to use.

Still, it’s pretty neat to see an educator not only using games in the classroom but also live streaming about his research into which games work well there.

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – New Workers

Last week, I reported that I had added a lot of “juiciness” to the toy animations as well as some other enhancements, and I made changes to the end of game grading of the player’s performance.

This past sprint, I wanted to focus on the workers.

Sprint 31: Polish and end game

Planned and Completed:

  • Create different types of workers

Planned and Uncompleted:

  • Animate worker picking up/putting down toy
  • Make worker eyes follow to nearest toy on belt

I added two new worker types to the game. One type is significantly stronger and so more capable of separating Bad Toys, but they can’t craft Good Toys as well. The other type is an expert at sewing and does a great job of crafting Good Toys but is terribly weak and can’t separate Bad Toys into parts as easily.

So the idea is that when you hire a worker, you have a tradeoff you can make. Maybe you want your strong workers closest to the dispenser to catch and work on Bad Toys as fast as possible, and your sewing workers can be closer to the shipment chute. Maybe you want the jack-of-all-trades regular worker who isn’t great but isn’t terrible at any job.

I found it straightforward to add the new types to the game in terms of updating the hiring menu. I already had the strength and craft stats in the game, so it was a matter of creating workers with different stats.

I needed new art, though, so I spent some time doodling some concepts.

I wanted the strong workers to come across as muscle-bound, large, solid characters, so the characters were more blocky and rectangular.

Toy Factory Fixer - Strong worker concept art

I wanted the sewing experts to read as more dynamic and speedy, and I experimented with triangle-based character designs.

Toy Factory Fixer - Sewing worker concept art

In the end, I went with these two as the base of my sprites:

Toy Factory Fixer - Sewing Worker

Toy Factory Fixer - Strong Worker

I started out drawing them at 1024×1024, being a bit sloppy but getting the basic line, shadow, and lighting in. Then I scaled down to the size they are in the game, and it more or less held up.

I added texture and color to the strong worker before scaling down, and the end result wasn’t very clean.

I scaled the sewing worker before adding color and texture, and it felt like I had more control over the end result.

Toy Factory Fixer - Sewing Workers scaled

Toy Factory Fixer - Strong Workers scaled

And here’s the updated hiring menu.

Toy Factory Fixer - Hiring menu with three worker types

One thing I need to do is figure out if the hiring cost makes sense. Right now, I am operating on the idea that the experts are worth more than the well-rounded worker, but maybe it doesn’t work out that way in actuality, so their costs and stats might change before I release the game.

I would love to get the workers animated. At the very least it would possibly help to see them moving their arms and blinking their eyes. When they toss the toys on the conveyor belt, I’d like to see them actually look like they are doing so. Maybe do a celebratory dance once in awhile. Something to make them look more alive.

And the more I play test, the more I am not a fan of the current variations of the worker barks. I tried changing the pitch to make it sound slightly different, but I think I made them too different. In the end, it makes it sound like the wrong audio cue is playing.

I’ve got a lot of work ahead of me, but I think I am close to making a releasable version of the game. I was hoping to have it out by my birthday next week, but it isn’t looking like I’ll make it. Still, it’s close, and I’m excited.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Toy Juiciness and Player Grading

In last week’s sprint report for Toy Factory Fixer, I focused on making the audio less tedious and making the toys feel better when they land.

It was a very small start to adding to the game’s feel, and I found myself continuing with it.

Sprint 30: Polish and end game

Planned and Completed:

  • Award grades to player performance
  • Add juiciness to toys landing on conveyor belt

Unplanned yet Completed:

  • Add juiciness to toys moving on conveyor belt
  • Interpolate money changes
  • Change value of small vs large toys

Unplanned and Uncompleted:

  • Create different types of workers

Like the previous sprint, I didn’t get started on putting any effort into game development early on due to the July 4th weekend and spending time with family.

That said, somehow this last week was still one of the most productive I’ve had all year. After multiple sprints in which I didn’t finish my original planned work, pulling in multiple pieces of unplanned work AND getting them done feels good.

And the game itself feels a LOT better.

If you recall from last week’s report, I created a dinky dust cloud animation. It’s not great, but the idea was that it made it clear that a toy landed on a conveyor belt.

Here’s the animated GIF I created to illustrate it, which looks ridiculously simple to me now:

Toy Factory Fixer - Impact dust cloud animated

It’s better than no effect, but just barely.

So I made the toys squash and stretch to sell it more. I spent a little bit of time learning about squash and stretch as an animation technique, and then I made two simple changes.

One, I created a new DISPENSING state for the toys. Each turn in the game moves the toys along the conveyor belts if they aren’t being actively crafted by a worker, and so now I can animate the toys differently if they are being dispensed in a given turn.

Two, I did what I said I was imagining last week, and I made the toys arc up into the air before landing. Basically, I used a sine wave and interpolated a vertical offset (stay in school, kids!). Then, I changed the scale of the toys using that same sine wave technique so that as the toy launches up into the air it would squash, then stretch, and as it came to the top of the arc it would squash, and then stretch as it came back down.

And it was so delightfully playful! I was a bit giddy, in fact. It’s my new favorite thing about the game.

I mean, look at it compared to the animation above:

Toy Factory Fixer - Toy movement juiciness

You’ll note that I also made the toys lean back as they are moved along the conveyor belt (a rotation based on a sine wave and the direction of movement), and it might not be obvious but I made the value of money interpolate instead of instantly changing values.

Again, I love the effects of these simple changes. The toys were the focus of the game before, but now the toys FEEL like they should be the focus of the game.

I now have to rework the dispenser art again, as I want it to look like a cannon shooting the toys out. And the lack of animation from the workers is now very obvious and should be addressed.

But I returned my attention to the end of level grade report. The original ending let you know if you won or lost based on whether or not you shipped a Bad Toy.

Here’s a screenshot from February which doesn’t look much different from last week:

Toy Factory Fixer - Game Over screen

And here’s what it looks like today:

Toy Factory Fixer - Level end grade report

In wanting to be more forgiving and give the player a self-directed challenge, I wanted to grade the player in three categories: the quality of toys shipped, the number of turns taken to finish the level, and how much the player earned versus spent.

Now I need to work on calculating these values more. For instance, grading the number of turns taken requires judging how many turns the player should have taken. I would need to figure out what “par for the course” is versus what would be amazing, and there are still a number of variables related to the time it takes toys to traverse the conveyor belts, the time it takes workers to work on separating them and crafting them, whether or not the player started production runs early, etc.

But overall, I like this screen, and I really like the joke that “MEETS EXPECTATIONS.” is always there no matter how well or badly the player did. It replaced the “GAME OVER” text before, and I originally wanted to have different text based on how the grades worked out, but I might keep it this way because it amuses me as a commentary about how many companies handle performance reviews.

Finally, I decided to start adding new worker types to the game. I didn’t get too far in terms of actually implementing it, but I did change the health of the toys so that they take longer to work on with the “normal” worker.

I’m thinking of adding two new worker types, one that crafts toys more effectively, and one that separates toys more effectively. These workers cost more.

I’m also considering some changes. Perhaps instead of tediously assigning a crafting task to each worker, you tell the worker to focus on crafting or separating. So a worker will not pick up toys if they are in a crafting mode, but they also won’t craft if they don’t have the inventory to work on the toy in question.

Also, what if you can’t hire the specialists unless you spend money to put out a call for workers, who show up within X turns? What if there are unlimited normal workers but a limited supply of specialists? Or limited supplies of all workers? Can you hire workers faster if you offer to pay more for them? Will they take longer to show up if you offer to pay less?

These are just thoughts, and I do need to worry about feature creep, but maybe they can be in a future deluxe version of this game if enough players want it.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Sound Effect Variety and Animation Juiciness

Last time, I reported that I finally fixed the issues I had with Android 11 and added some fancy effects to the toy dispenser to give it some more character.

This past week I planned to continue adding juiciness to the game.

Sprint 29: Make publishable

Unplanned yet Completed:

  • GBLib: Make it easier to play a random sound with one command
  • Add variety to sound effects

Planned and Uncompleted:

  • Add juiciness to toys landing on conveyor belt

Planned and Not Started:

  • Award grades to player performance

Ok, so let’s start with the fact that I didn’t do much at the start of the week, and when I finally did put in some time a couple of days after the sprint technically started, I decided to change the plan and instead work on fixing how tedious the worker grunts sounded.

Whenever you tap on a worker, hire a worker, or give a worker a job to do, you’ll hear the worker make the same sounds two sounds. One is kind of a confused acknowledgement that you selected a worker, and another is a confirmation “Uh, huh!”

Over and over. It gets old.

I basically made two more versions of each sound effect with a different pitch. So it’s the same two sounds, but each has a little bit of a difference.

I’m not sure if it is enough to make it feel less tedious, though. I’m thinking I’ll revisit these effects and create a variety of grunts/barks.

Weeks ago I found that my existing GBLib code didn’t make it easy to play random sounds. Basically, there was a command to play sounds, and I abstracted away the number generator that tells it which of a few options to play, but the way I did so expected that a number generator was owned by some other object.

Which at the time made sense: I could create a single number generator object, and then it can get used by multiple objects that need it, whether it is for audio or something else.

But it practice it made it painful to create these sound objects because I had to do the extra work of figuring out what other object was responsible for the number generators.

So I changed things so that while you still needed to pass it a number generator, the play command object now owns the generator object and will manage its lifetime.

And I created some helpers so that the generator created was guaranteed to be tied better to the size of the collection of sound effects you want to choose from randomly.

Ok, so for now, my library has been improved for future games, and the audio grunts are less tedious. Next, I decided to work on adding a special effect when the toys land on the conveyor belt.

It wasn’t going to be a major effect. I just wanted a dust cloud or something to convey that there was an impact as the toy hit the belt, which happens whenever a Bad Toy gets dispensed or when a worker tosses a finished Good Toy.

I managed to create a somewhat OK piece of art that combines an impact ring and some translucent clouds. It doesn’t look like much by itself.

Toy Factory Fixer - Impact dust cloud

But it’s not meant to be static. I scale it up in size and make it more translucent as it finishes animating, and … well, I think it still doesn’t look like much, but on the other hand, it sells the impact (especially when you hear the thud sound effect with it):

Toy Factory Fixer - Impact dust cloud animated

I have yet to create this effect when the toy is dispensed because I also need to change how toys get dispensed. Right now, the way toys get dispensed is that they appear behind the dispenser art, and they slide right out onto the conveyor belt right next to it. I would need to change it so that they look like they are spit out a bit higher so that they land on the belt next to it, but that requires changing a few more things.

I considered not doing the change, but I am starting to enjoy the juiciness I’m adding. It makes the game feel more playful, and I’m already picturing the toys getting dispensed in an arc like they were fired by a short-range t-shirt cannon.

The main game play change was one I didn’t get to at all. I wanted to change the game ending from either a binary win or loss based on perfection to giving the player a grade. The idea is that the game will be less harsh while also giving the player goals they can self-assign. If you got a C grade, you can decide if it is good enough or if you want to replay the level to try to get a B or an A.

I’ll spend time on it this coming week.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Android Defect Fix and New Dispenser Art…Again

In my previous sprint report, I talked about updating my project to use SDL2’s new android-project directory and Android’s gradle-based build. Upon doing so, I fixed a screen orientation defect where the game played in portrait mode despite the configuration specifying it should be in landscape mode. I also started work on improving the art for the dispenser so that it communicates what is happening to the player better than it has.

Sprint 28: Make publishable

Planned and Completed:

  • Add juiciness to dispenser
  • Defect: game seems unresponsive on main menu screen (Android)

Ok, I might be premature in saying this, but I think I fixed the Android 11 touchpress issue that my tester reported.

With SDL2, I basically pretend that a tap is a mouse click by paying attention to the values that come from SDL_MOUSEBUTTONDOWN and SDL_MOUSEBUTTONUP events. There are also SDL_FINGERDOWN and SDL_FINGERUP events, which are for touch events, but since the default behavior is for mouse events to get simulated from touches, I ignored them.

My tester said that tapping on the screen didn’t seem to make the menu options respond at all. I added some debug text, and I changed my code so that the SDL_FINGERDOWN/UP events modify my game’s input data. Oddly, we learned that the taps do seem to cause at least some effect in terms of setting the simulated mouse cursor position, but there was no down event or up event that changed whether the simulated mouse button was down or not. Weird.

I found that I couldn’t reproduce the issue with an earlier version of Android that my phone and tablet have access to, and I don’t yet have an Android 11 phone, so other than the Android emulator, I wasn’t able to do much.

However, if you run the emulator, and in a terminal you run adb shell, then you can run the input command with arguments to simulate a tap on the screen.

And I found that the simulated tap does indeed seem to reproduce the behavior.

Well, I finally decided to play unique sounds when the SDL_FINGERDOWN and SDL_FINGERUP events are processed, and when I ran input tap…the sounds played!

WHAT?!

Ok, so to cut a long story short, it turns out that the tap is so quickly simulating a touchpress and release that the two events end up in the same queue.

My code processes SDL2 events using a typical event pump. Basically, I have a function called update() that calls SDL_PollEvent() in a while loop. If it returns 0, there are no events, but if it returns 1, it means that there is one…namely, the event pointer argument that is now set.

The SDL2 wiki says:

The common practice is to fully process the event queue once every frame, usually as a first step before updating the game’s state:


while (1) {
    SDL_Event event;
    while (SDL_PollEvent(&event)) {
        /* handle your event here */
    }
    /* do some other stuff here -- draw your app, etc. */
}

And quite frankly, the code above is almost what my own code looks like.

The way my game’s UI works, though, is to detect a mouse click on a UI element whenever there is an update in which the mouse button is down and then later up while the cursor is over the element.

And it does so across separate calls to the update() event pump.

Well, I discovered that if I change the while loop’s condition, I can exit the update() function whenever a finger/button down or up event occurs, ensuring that my game’s input data is set correctly.

void HardwareLayer::update()
 {
+	bool handledTapOrButtonClick = false;
 	SDL_Event event;
-	while (1 == m_sdlInstance.PollEvent(&event))
+	while (!handledTapOrButtonClick && 1 == m_sdlInstance.PollEvent(&event))
 	{
 		doRenderUpdate(true);
 
@@ -345,6 +346,7 @@ void HardwareLayer::update()
 
 			case SDL_FINGERDOWN:
 				{
+					handledTapOrButtonClick = true;
 					m_fingerIDs.insert(event.tfinger.fingerId);
 					if (m_fingerIDs.size() < 2) 
 					{
@@ -358,6 +360,7 @@ void HardwareLayer::update()
 
 			case SDL_FINGERUP:
 				{
+					handledTapOrButtonClick = true;
 					for (std::set<long long>::iterator iter = m_fingerIDs.begin(); iter != m_fingerIDs.end(); ++iter)
 					{
 						if (*iter == event.tfinger.fingerId)
@@ -399,6 +402,8 @@ void HardwareLayer::update()
 
 			case SDL_MOUSEBUTTONDOWN:
 				{
+					handledTapOrButtonClick = true;
+
 					if (SDL_BUTTON_LEFT == event.button.button)
 					{
 						m_mouseButtonStatuses.at(GB_MOUSE_BUTTON_LEFT) = 1;
@@ -412,6 +417,7 @@ void HardwareLayer::update()
 
 			case SDL_MOUSEBUTTONUP:
 				{
+					handledTapOrButtonClick = true;
 					if (SDL_BUTTON_LEFT == event.button.button)
 					{
 						m_mouseButtonStatuses.at(GB_MOU

The update() function already gets called multiple times between draw calls, so it isn’t as if I lose anything by exiting the while loop early. I’ll end up right back in a new while loop and can handle the next event without missing a beat.

And so now I wait to hear from my tester to find out if this worked on a real device with a real person’s fingers.

Fingers crossed!

In the meantime, I also worked some more on the dispenser art. If you recall, I had another tester tell me that he had trouble understanding why it looked like the game wasn’t advancing, so I decided to update the art and use animation to make it clearer.

The new dispenser art has arrows that now light up and turn off as it is running. I added a bit of a glow to try to sell it.

But I also created a lever switch. The handle moves towards the Play side when the turns are advancing, and it moves towards the Stop side when they aren’t. The Stop square changes fades in and out to make it clear that everything is stopped.

Toy Factory Fixer - Animating Dispenser

As a final bit of juiciness, each time the dispenser spits out a toy, it changes size, almost like it is building pressure and then relieving it. It’s a subtle effect, but I think it looks decent enough.

Toy Factory Fixer - Dispenser animation

I’m looking forward to hearing from my other tester to see if this graphical enhancement makes it easier to understand what the current situation is at a glance.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – Android Defect Fix and New Dispenser Art

In my last sprint report, I finished up my work of updating my build scripts to create an iOS project successfully to deal with Apple’s latest requirements, and then I turned my attention back on addressing Google’s new requirements.

Sprint 27: Make publishable

Planned and Completed:

  • Defect: game plays in portrait mode instead of landscape (Android)

Not completed:

  • Add juiciness to dispenser
  • Defect: game seems unresponsive on main menu screen (Android)

The good news was that I didn’t need to change too much of my existing Android build process. I basically needed to replace the older SDL2’s android-project directory with the new one, change a few files so that it did what I expected, and then change my CMake files so that it used the new gradle-based build rather than the old ant-based build. I was pleased that aside from a few things, much of the work was changing the directory names to match what was expected.

While the SDL2 docs mention using the command ./gradlew debugInstall, I wanted to have more fine-grained control. I wanted to be able to run three separate steps: build either a debug or release build, sign a release binary, and install the APK.

When I checked the Android docs, they mentioned the arguments assembleDebug and assembleRelease, so building is as easy as changing the argument to gradlew.

While I haven’t uploaded to the Google Play store yet, signing looks like it is the same as before, which I do with jarsigner and zipalign. I assume that since I can run a signed release build on my own hardware that it is not going to require any changes when I do upload it, but I’m prepared to learn otherwise.

And installing, either in the Android emulator or on my device, uses adb as before.

One thing I ran into was that the build would look like it was fine, but then suddenly I’d get a bunch of linker errors along the lines of:

undefined reference to 'std::logic_error::logic_error(char const*)

It turned out that in android-project/app/jni/Android.mk, I needed to uncomment the APP_STL line to make sure it uses the C++ STL that my project requires. Then it built correctly.

I sent the latest builds off to my testers. Based on my own testing in the emulator and using adb shell to play with input tap, I’m worried that the touchpress detection is still not working in Android 11. I was using SDL2 2.0.14, and I even tried by downloading the latest in-development branch from GitHub, and it still didn’t respond correctly. But maybe my tester who was having issues on his device will see something different.

In the meantime, my other tester who reported that the game runs in portrait mode instead of landscape mode on his phone informed me that the new build does in fact run in landscape mode correctly now. So that’s one defect fixed!

While I wait to hear back from my other tester, I got back to actual game design work. I started experimenting with some graphical enhancements that didn’t pan out, then I started working on updating the dispenser’s look.

Toy Factory Fixer - Old vs New Dispenser

This new dispenser is a bit bulkier to hide the fact that it basically draws over the toys. The old dispenser had a skinny part, and toys would show in the background, which broke the illusion that they were coming out of the dispenser.

But this new dispenser also allows me to make it clear if turns were advancing or not. One thing I was told by one tester was that it wasn’t very obvious at times that you needed to hit the Go button to make things move forward, especially when you were hiring or telling a worker to do something. The game is kinda continuous-turn-based, and so it continues until you perform such an activity, and then it stops everything, and you have to hit Go to again.

Right now, the only indication you have is that the button says Go instead of Stop, and the fact that nothing is moving.

So I wanted to make the dispenser light up when the machines were active, and perhaps have a different animated light to indicate that it was stopped.

I might change it so that one of the arrows is a lever, which is up when it is running or down when it isn’t, with a blinking light to make it clear which setting it is.

Anyway, I’m easing back into it, but I’m happy to get back to actual game development rather than fighting with platform-specific changes brought about by other companies changing requirements.

Thanks for reading!

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

Categories
Game Design Game Development Geek / Technical

Freshly Squeezed Progress Report – iOS Icons, Android Updates, and Design Tweaks

In the previous sprint report, I wrote about spending time figuring out how to build SDL2 and combine it with my CMake-generated iOS Xcode project for Toy Factory Fixer successfully, as well as configuring that Xcode project to automatically know where to find my app icons, which made me a bit giddy when I got it working.

I continued with the iOS work in the next sprint.

Sprint 26: Make publishable

Planned and Completed:

  • Create iOS icons

Not completed:

  • Defect: game seems unresponsive on main menu screen (Android)
  • Defect: game plays in portrait mode instead of landscape (Android)

I once again didn’t spend as much time as I would have liked on game development, but then again, I took my first true day off for the first time in what feels like years. Normally my days off from the day job tend to become opportunities to spend more time on game development, but my family took a trip out of town, and when we came back, the kids went to a day camp, and so my wife and I spent the day together. Due to a variety of things going on, I didn’t do any game development until halfway through the week.

I created a script to take a 1024×1024 PNG and convert it into all of the image sizes I would need for iOS app icons.

I learned a few things from this experience that I can take to my future projects. One, when it comes to generating those icons, I need to start with a higher resolution image. As it is, I had to actually generate a larger icon from a smaller one, and so it looks more pixelated than I would have liked.

And that leads to two: I should probably use vector graphics to create art initially so that I don’t need to worry about issues when I scale the image for a different purpose later. Between icons, marketing materials, and even in-game art, vector graphics would provide more versatility.

Anyway, my game now has icons for iOS. I did have a scare in which I deployed the app to my iPhone, then when I used the app switcher, I saw the icon was missing. What gives? I double-checked, and I wasn’t missing any icons as far as I could see. And I didn’t see how to specify this specific icon in the app switcher (which comes up when you hit the Home button twice quickly).

It turns out that iOS caches things…and it had my app’s old icon, which was no icon.

So once I restarted my phone, everything worked fine. Hopefully this information helps someone in the future.

So now that the iOS port seems to be working properly, I returned my attention to Android issues. If you recall, Android 11 seemed to have broken things like touch input and respecting the fact that my game should run in landscape mode instead of portrait.

And since I am using an older version of SDL2, I needed to update to 2.0.14, which actually requires me to update from the old ant-based build to the gradle-based build.

The good news is that SDL2 comes with an android-project directory, just as before, and the documentation for it is a lot better than the iOS docs. I was able to compare what I already had in my project directory to what they specify, see that most of the compiling parts are identical, and basically move everything into a subdirectory that didn’t exist before.

Then, I needed to make sure that the Android.mk file specified the correct STL, and everything built and linked correctly.

So far, so good, but next is the part where I need to change from using ant to gradle, and the docs get a bit opinionated about how to create a debug build or how to deploy directly to your hardware. Literally, all it says is:

Run ‘./gradlew installDebug’ or ‘./gradlew installRelease’ in the project directory. It will build and install your .apk on any connected Android device

Normally, I build my code, then create an APK package, then sign it, and that signed APK gets uploaded to the Google Play store. If I wanted to test it on my device, I would create a debug build and deploy it using adb to install.

So I need to dig a bit more to see if there is a gradle way to do what I already did before, which is build the APK as a separate step from doing something with the APK like installing it on a device or signing it.

So far, when I ran gradlew as above, it downloaded gradle.

I hate that. I mean, I should have read some docs about gradle and gradlew, so it is my fault, but why the heck is there a tool to download a tool from someplace random and put it on my machine without so much as asking me if it was OK to do so? I already have to deal with it when it comes Javascript at the day job.

Anyway, after it downloaded gradle, it failed, so I still need to figure out what changes I need to make to get this build working. I’m hoping it won’t be much longer before I can get an Android build working and deployed to my testers to verify whether or not it works on Android 11.

Meanwhile, I’ve also been trying to dig back into the design of workers, toys, and the level layout in the game. I want to make sure that the player doesn’t feel bored by obvious decisions to make, whether by giving them the ability to hire more interesting and varied workers or throwing different kinds of toys or movement patterns in the game. I’ve got some ideas, and some might be terrible, but some made me laugh as I wrote them down, so hopefully something good can be shared soon.

Thanks for reading!

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