The result was expected, but still frustrating


We expected to have some DNW due to our dependencies. We never had that many dependencies in a pyweek before. Our
experience told us, this will be trouble. And yes, it was trouble apparently. The strange thing is, that we didn't
hear about it. No one except two persons asked for help.

The frustrating thing about this type of interface is, that even if you have passed all technological difficulties,
it is no guarantee that it will work. It may very be that your accent is not recognized. Or your voice. Or
whatever causes it not to behave as expected. For me it worked pretty well, even I'm not a native english speaker.
But well, I trained a week long and I'm certainly biased. And native english speakers had trouble getting it
to recognize the commands. There are other models available but they are bigger (~1GB or more), but I don't know
if they would work better. Our game shipped with an already compressed 40MB file which is heavy enough!

To give you all the chance to play it through I made a version with a keyboard interface. It will behave the same
Text Input Version


I hope you haven't read the spoilers yet since it would spoil the game. It also would be much appreciated if you could
give feedback as during the judgment period (Fun / Prod / Inno, 5 best - 1 worst).


Overall I found it an interesting pyweek. The theme was not our first choice and frankly, we didn't have a good idea.
And since quite some time I wanted to try text to speech. After some experiments I also found some libraries that
do the opposite: speech to text. Due to the asynchronous nature of those libraries the next step was to look into the
multiprocessing module of python. The result is this game. Its hard to close. On purpose. Unless you 'exterminate' it!

Thanks so much to everyone for rating and playing our game! Thanks to the highscore server that tizilogic developed, we were able to see the highscore list update over the course of the judging period as people started playing it, which was quite fun to see.

To give everyone an even chance (and because we did a bunch of balancing changes at the last moment), the leaderboard was reset at the beginning of the judging period so that everyone would have a fair shot. Our own team lead Hendrik-jan took an early lead on the board, but was defeated by an absolutely stellar score from our modeller, fireclaw, whose score still reigns supreme on the board, despite ankith101rar's many respectable attempts to catch up with him, which were nonetheless successful at pushing the rest of the dev team off the board.

The final leaderboard at the end of the judging period stands as follows:

1  	FOX  	413186
2  	ANK  	202991
3  	ANK  	151669
4  	ANK  	148328
5  	FOX  	147462
6  	ANK  	126634
7  	ANK  	115896
8  	ANK  	112719
9  	ANK  	111618
10  	AAL  	111391

Congratulations to Fireclaw, ankith101rar and whoever entered AAL for achieving these great scores!

The high score server is still up and running, if you want to have a go at defeating these champions. A live version of the leaderboard is available cops.highscores.best and will continue to be available for a while.

Thank you, everyone, for all the wonderful feedback. And congratulations to everyone who took part too. Looking at the comments there are a lot of very positive remarks and we are truly very flattered, thank you 😊. Everyone loved the art and sound aspects it seems, as did we. It's encouraging to know that all that work was so appreciated.

We were not very happy about the theme, bottom of all of our lists. It seemed too charged a topic for us, too divisive. So we aimed for something utterly inoffensive. I hope we succeeded. Others with the same problem went in different directions, (i.e. Cosmologicon). I suppose the theme is always just a starting point. In the past I remember people have used anagrams of the theme to design their games. You can't really do that with "cops".

A few people struggled with the initial learning curve. I'm sorry about that; we didn't have any external playtesting so that kind of thing was likely. All the same I think we were aware it was tight but it was also very challenging to find the right balance point.

Well, it's over for another five months. Well done again to everyone, hope to see you all next time.

PS. Did anyone play our "Endless" mode? Post your score if so!

Hey everyone,

Thanks for the feedback, we really appreciate it!

We just wanted to clarify a few things related to the game.

The KeyError that arises in the last stage was due to a typo. This (and another sneaky typo) is now fixed in the code on Github.

We are extremely sorry that we couldn't add more upgrades, moves and information. We had initially planned to add 2-3 informants, and 10-12 moves. We realised later that it was too ambitious, so we had to settle with a lower number.

Thanks again for all the great feedback! Feel free to write more feedback and comments on this diary entry.

- Team Elite-ra

Thanks to everyone who played my game! I appreciate all your comments.

Making a game like this was a bit risky, but it was worth it. I haven't done a lot of strategy games like this in Pyweek and my past attempts weren't very good. I'm happy that I was able to make one that I'm satisfied with and it looks like many of you liked it as well. It was also surprisingly time consuming; I spent a lot of time polishing the interface throughout the week and I was just trying to rush everything in in at the end. I'm glad that things worked out and I'm quite happy with how the interface turned out (which is often a weak point of mine). I might avoid strategy games next time though unless I have an idea I really want to try.
I made the mistake of leaving the tutorial to the very end. At least I probably should have done that before adding card variety. Usually when I'm making puzzle games, tutorial levels kind of come out naturally as you develop puzzle mechanics. However, with a strategy game like this with relatively complicated rules, it actually takes a substantial amount of time to develop a tutorial, and I realized at the end that I wouldn't have enough time. This was probably one of the biggest issues with the game and I was aware of it at submission time but I hope that wasn't a big deal for most of you.
There's also a weird property in this game in that chance is a big deal. You could be lucky and catch the killer very early on because you happened to have a guard in a block and there were few people there. You could also randomly target a suspect and have a chance of winning the game. For this reason, I'm not sure if this is an idea that would survive scaling up and maybe it's best that it's just a small Pyweek game. I wonder how a developed version of this idea would look like.
Congratulations to the other winners (Python Prison and Badge Blaster 2112) and to everyone else who completed a game! I don't see ties very often. These were excellent games and there were also other great games in the batch. Thanks mauve for hosting Pyweek. I had limited time to rate games this Pyweek, so sorry if I wasn't able to play yours. See you all next time!

It seems some people were confused about what to do so here's some more explanation. The point is that you can't search everyone but you have to click multiple times to complete a search at which point they are either let go or sent to jail. At the end you're presented with some stats about how you did. I guess making a game that isn't necessarily supposed to be fun is a bad idea for PyWeek success.

tl;drWhat went wrong? 

1. Our last-choice theme was chosen
2. We ran into underlying issues with the framework
3. My teammate had to drop from the competition after the second day

How did I address it?

1. Drastically reducing scope
2. Repurposing what we had already built to fit a different and much simpler gameplay loop
3. Reduce the story to fit new gameplay

What skills did I improve?

1. Planning inheritance hierarchies 
2. Pixel art

Main takeaways

1. You need more slack in your plan than you think
2. All parts of a gamejam plan should be incrementally implementable
3. A well thought-out framework can't completely prevent things from going off-plan

Next Steps

1. Contributing improvements to arcade
2. Learning about graphics
3. Maybe some more games?

What went wrong?

Disclaimer: this is written from memory and some shallow log review rather than an intensive review of git and chat history

1. Our last-choice theme got picked

What happened?

We were eager and hopeful before the theme was announced. Aquila, our top choice, got us excited about scrolling shoot-em-ups with space ships and fighter jets. We discussed how perfect arcade is for implementing games from that genre. The Raiden series and Ikaruga are commonly praised standout examples. We were also somewhat excited about other themes like Bridging the Gap and Soul to Soul.

Then, to our dismay, Cops was announced as the theme. Making any kind of shooter game now seemed both unoriginal and possibly tactless in light of recent events around the world.

How did we deal with it?

We brainstormed ways to make a cop-themed game with no violence

We had been discussing different stealth mechanics when I started riffing on recent news about the 2021 GameStop stock rally. If you're unfamiliar with the story:

1. Casual investors started buying GameStop stock after reading posts describing a profitable loophole in stock purchasing contracts. 
2. The original poster, who goes by Roaring Kitty on twitter, testified before US congress about the issue and faced a lawsuit over securities fraud
3. The readers who bought stock started calling themselves "apes", using the slogan "Apes Together Strong", and donating profits to gorilla conservation

Koko the Gorilla, a gorilla that once kept cats as pets and was reportedly able to use sign language, combined with the aforementioned topics to give us our first iteration of the game's name: Cat Burglar. We were fairly sure we wanted to make a stealth game with an ape protagonist. But what would an ape steal? A meme that became popular early in 2021 gave us our answer: three orangutans at a table, one asking "where banana" without a question mark at the end .

We were now going to make a game about an ape working with a cat to steal bananas protected by cops and redistribute them to fellow apes in need. Since we wanted to do a stealth game, a gorilla seemed like the funniest option for an ape player character since they are the largest living apes.

How would we make that into fun and non-violent gameplay? We decided that the player could use the cat and gorilla to interact with items in a police station to distract cops and sneak through a building. Objects like light switches, donuts, coffee machines, and office furniture were all now tools for stealth and distraction. We'd talked about incremental gameplay as a guiding principle. Slowly adding new interactable items to the map as time allowed after establishing a core gameplay framework seemed like a decent way to achieve that.

Things were going well!
We were excited. I made some filler cop assets that ended up being used in our final game. I began writing a stateful animated sprite class to play the animations and let us quickly prototype NPCs and environment objects. GelamiSelami started working with Tiled to help us build levels and made an excellent animated gorilla sprite that is nearly identical to the one used in the game. The frames for it are still in the assets folder if you'd like to look at them. Here's the backwards / "moonwalking" version they first posted:

GelamiSelami then combined our prior sprite work with a basic platformer physics system imported from arcade and an excellent custom camera object. I made a stateful gorilla class that could walk and animated appropriately in response to movement. I then began making alternate skin options for cops after writing a sketch of initial story revolving around the gorilla trampling the garden outside their police station during an escape. The two cop sprites were now named Randy and James as references to characters in popular media they resembled (Randy Marsh from South Park and James Doakes from Dexter). They still have their names reflected in their asset folder names in the final version of the game.

2. Performance Issues with Text

What went wrong?

We wanted to display time remaining, but we ran into an issue we'd previously seen mentioned in chat channels for game jams: as of arcade 2.5.6, frequent update attempts on the text value of a UI label will slow your game to a crawl.

The issue stems from the fact that as of the time of writing, UI labels re-render their textures entirely each time the text value is updated, and do so with the CPU rather than opengl. Not just once, but three times for each one call of text update. The three textures correspond to three different display states a label can have as part of a button. This design choice made sense when the UI label was written because they were assumed to be infrequently updated rather than a score or time displays.

Then users like us immediately grasped for the first solution that seemed apparent for displaying scores and times. This is counter-intuitive to say the least.

How did we address it?

We decided to cut dynamically updating text such as timers out of the game. Only static notifications would get shown, and I considered using speech and thought bubbles with icons in them instead of text for interaction with cops.

3. My Teammate had to drop after the 30thWhat went wrong?

GelamiSelami, through no fault of their own, unexpectedly had to drop from the competition after the second day. There was now no time to implement a single character version of the original design, let alone a second cat character to swap between.

I had to figure out a way to turn our pieces of a game into something I could finish on my own in the time remaining. This was harder than expected. I wasn't familiar with the same parts of the arcade framework GelamiSalami was, and I had to things to do during the day, leaving me limited time to work on the game.

On top of the technical concerns, I also realized that our story and art no longer made sense. How are you a cat burglar if you aren't stealing anything? Gorillas don't wear pants and they run on their knuckles, so there's no way for them to actively carry anything and run, climb, or do acrobatics effectively at the same time.

How did I deal with it?

I pivoted hard toward a drastically simpler design. Stealth wasn't an option, so I would make a runner game. 

A New Enemy & An Old Friend

The new goal of the game was to avoid touching enemies, with bananas as a thrown weapon to halt police and down drones. I added flying police drones as a second category of enemy. I'm grateful to my past self for writing the stateful sprite back-end and derived Actor class. It saved our project because it worked as intended by turning adding new enemies into a matter of artwork and passing config for loading sprites. To drive the point home, it took at least 10 times longer to finish the art than to add the new NPC class and have it spawn.

Going Un-bananas
I was thinking about how to manage multi-level terrain and how I'd depict have bananas hitting drones out of the air. Then I checked how much time I had left in the week and I made a decision that is now clearly good in retrospect. 

I abandoned all plans for bananas, complex drone behavior, terrain, and scripted intro scenes. I didn't bother removing the assets. There are unused drone, gorilla, and cop assets in the asset folder. I now have a new and very personal appreciation for the unfinished game assets and entities often discovered buried in shipped with game titles. Sometimes, there's not enough time to take things out without risk of breaking something.

This game was turning into a poor clone of the dinosaur game in Google Chrome. I made enemies delete themselves after they moved too far to the left. I tore out the camera, level loading, and even player movement. All that was left was a static viewport and a simple physics system that allowed the player to jump up and down.

Puprose and A Splash of Color

I also remembered the second issue: Why was the gorilla running? What were they stealing? The story about GameStop provided the answer. The gorilla would bust the cat out of jail after the cops framed him for illegal stock trading. The cat would ride on the gorilla's back.

Now I had to add a cat. Watching GelamiSalami's spriting process helped me understand how to color my sprites much better. Remembering the color theory I had read about earlier in the week, I decided to make the cat a golden-orange ginger to contrast with the sky blue of the cop shirts. I then animated the head and tail bobbing to give the cat some life. Giving the cat color also helped the formerly monochrome player sprite stand out against a monochrome background. The gorilla now had only one animation used in the game, and it looked like this:

Add a High Score and...

Oh, right. We can't do dynamic text. That means no high scores, which means no infinite runner. How do I make this a finished game with a sense of progress?

Once again, the reusable components I built earlier came to my rescue. I hastily implemented a randomized enemy spawner out of lerps, a timer object, and a few builtins. Enemy spawn rate slowly increases as the win condition timer nears completion:

            self.time_till_next.remaining = random.uniform(
                self.min_enemy_gap_sec,
                lerp(
                    self.max_enemy_gap_sec,
                    self.min_enemy_gap_sec,
                    self.global_time_elapsed.completion
                )
            ) 

I hastily tested the win state by temporarily setting a much shorter time-to-win, and verified that I could reach a win screen. I set a final time limit for the player to survive, and added text display in-game to reflect the player winning or losing. The game was now ugly but technically fully playable.

Those Labels Again
The same text rendering behavior that annoyed me earlier hurt me again by making it impossible to unblur text in the time I had left. Oh well. The viewport was locked to upscale and I decided I didn't want to try to upscale all the sprites as a hacky fix. Instead, I focused on the install instructions and getting someone to help test them. The game is uploaded and shipped, even if I'm unsatisfied with it.

What Did I Improve On?

This challenge helped me apply and refine my class hierarchy design skills, even if it was in a very limited fashion. The classes in this game are somewhat ugly, but they are effective as zero-thought tools for rapidly adding enemy types. The timer and stateful animated sprite classes I wrote ended up doing the brunt of the work of my work in this game, both before and after the pivot to a runner.

I am also grateful to GelamiSalami for showing me some of their pixel art process. I believe that I got slightly but visibly better at pixel art during this challenge by studying their techniques. Compare the cop, done first, to cat on the back of the gorilla below:

  

Although the cat is still imperfect and rushed, it reflects form and lighting better than the cop sprite and in a smaller amount of pixels. The cop looks flat and blocky in comparison to the cat, and I believe the better understanding of hue shifting I developed during this game jam is part of that.

Main Takeaways

These will be completely unsurprising to anyone with experience in game jams.

1. You need more slack in your plan than you think

As is often the case for many teams during game jams, we didn't have enough time to do everything we wanted. We had some smaller but unambitious ideas for games earlier that we probably should have used rather than trying to build a side-scrolling stealth game.  A larger team might also have made stealth gameplay more feasible, so we hurt ourselves by not recognizing our lack of room to shift work between team members.

2. All parts of your plan should be incrementally implementable

Ironically, we talked about this this principle before the competition started. I think we got too optimistic about what back-end we could implement in the time we had before we started adding incremental additions. If we had stuck with a simpler core gameplay concept like a runner to begin with, we would probably have had time to add things like throwing bananas. Going forward, I think I'll try to stick to very simple core gameplay loops. However, it seems to be hardest to keep gameplay concepts simple when you're brainstorming around the theme rather than core mechanics. I think other teams that built gameplay first and wrapped the theme around it better have a better sense of the game jam metagame, and I should follow suit.

3. A well thought-out framework can't completely prevent things from going off-plan

This is more of a supporting point to the previous two than a stand-alone. A good class or gameplay design can't protect you from things like hardware problems or other reasons people may have to stop work on a project. It also won't prevent you from making unfeasible game design choices. The only way to reliably deal with those sorts of issues is to stick to the first two principles.

Next Steps

After the submission period ended, I started contributing to arcade in small ways to familiarize myself with the codebase before working on  bigger ones. I've submitting bug reports, and made small quality of life pull requests, and helped debug issues with some unruly hardware. My main goal for arcade is to provide a solution for displaying rapidly updated numerical or text data so people don't have to worry about performance hits from trying to display scores in a way that cleanly fits into the UI paradigm pushed.

I've also started trying to understand the graphics primitives behind arcade. This might take a while as OpenGL is complicated, but I have  learned enough to at least follow discussion and explanations from experienced maintainers.

Maybe I'll write some more games eventually as well. I will try to keep it small in initial scope with room for polish as practice for future game jams.

I'm looking forward to the next PyWeek!

Current Record: 02:45:40

Proof: https://www.youtube.com/watch?v=KWQ-09ZFy5Q

Bugs or issues running the game? Follow this link and post them under the earlier diary entry.

I don't have too much to say about this entry. I wanted to take it a little easy, so I didn't try for anything too groundbreaking or unfamiliar, and I think it worked out all right.

My first idea involved using a copse to conceal something, and you have to place the trees so that there's no line of sight from the outside to the thing in the middle. This led to a sort of tower defense idea with creatures coming in from the outside and you have to plant trees to divert them back out, and that led into collecting them instead. I went with a hex grid instead of a square grid, because I wanted there to be plenty of crisscrossing paths, so more ways to travel through a tile is better.

A few years ago I made a game for the Zero Hour Game Jam that has some strong similarities. I was also inspired by my vague memory of the game Gondola from PyWeek 7. Building something that sorts items into groups can be a really satisfying mechanic.

The puzzles turned out harder than I expected them to be at first. I started by designing what I thought would be the final level, which I think is often a good place to start. My initial sketch had 21 rings, but I cut that down to 12, and it still took me much longer to complete than I wanted. I decided to leave it in as a bonus level after beating the game, and I made a smaller level with 6 rings to serve as the actual finale. I originally envisioned several more complicated mechanics, but these ideas did not last once I had a prototype and saw how complicated the basic mechanics already were.

I always have at least a couple graphical effects that require some work, and this is often one of my favorite parts, even though it doesn't actually add to the gameplay. I tried really hard to put that off until the end, to make all the levels and gameplay first, and then just use the last couple days for polish. But I got too excited thinking about it, and on Wednesday night I broke down and started working on the graphics. This turned out to be lucky, because the graphics took some work. Not the special effects, actually, but the basic images. It turns out that it's really hard to visually distinguish different types of trees when all you see is a cross section of their trunk. It also took a surprisingly long time to think of using a flower with six petals to indicate spawners. I think I need to remember that graphics involve design challenges as well, so it's not a waste to get started on them early.

As always, thank you very much to the organizers, and thank you to everyone who tries the game!

Bugs solved. Version 1.0 avaible.

If you play the game please let me know what you think about!