PyWeek 31 challenge: “Cops”

GD - Pyweek 31 - postmorten on the speech to text experience

Posted by DR0ID on 2021/05/08 13:07

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
as if you would have spoken the words (just type the answer and submit it by pressing 'enter').

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!

Add a comment

Badge Blaster 2112 - Final Leaderboard

Posted by rdb on 2021/04/19 10:18

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 and will continue to be available for a while.

Add a comment

Copcake Caper - Closing Remarks

Posted by Chard on 2021/04/18 17:35

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!

Add a comment

Aquilam - Comments and Feedback!

Posted by pjrMakesPyGames on 2021/04/18 05:21

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

Add a comment

Halt! - Halt!: Postmortem

Posted by Tee on 2021/04/18 01:13

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.

Tutorial (or lack of)

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.

Balancing and game mechanics

I think the main risk factor here was balancing. Balancing can really break a strategy game if done poorly. I don't typically have much time to playtest in Pyweeks, and I didn't expect (but at the same time I'm not surprised) to see that so many people thought that the game was hard. There was a few people who initially had issues with difficulty but eventually were able to get the hang of it, which makes me glad.

When I finished the game, the balancing actually felt ok to me but I think it was because I was very biased. In particular, a good strategy here is to get as many guards as you can in the beginning, and focus on solving crimes in a later stage. The reason why guards are so important is that basically you can only do actions where there are guards, and finding a body after 3-4 turns of the kill is not very useful. Moving around is also very important to find bodies if you have few guards. The first crime should probably be left unsolved unless you happen to be particularly lucky. And don't add new cards, turns out that that's not a good strategy even though I wanted it to be. So when I tested, I was already playing with a good strategy and it didn't feel like it was too hard. I need to be more careful with this, but it's kind of hard to avoid. Maybe having a tutorial that made the player to play out a bit of this strategy would have benefited balancing.

Someone also suggested adding a few more turns before the first kill, which I did consider when balancing and I think is a good idea in principle but I didn't really want to do it because hiring guards is the only "building up" action available (besides buying cards, which doesn't really help, and the Curfew card). This would make the early game kind of boring (not to mention confusing if there is no tutorial) and I didn't want to risk that. If I had more interesting actions to let the player build up, I would have probably done it. Anyway, there are a lot of interesting balancing questions here.

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!

Add a comment

The War on Drugs - I didn't come last!

Posted by PyTM30 on 2021/04/18 00:57

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.

Add a comment

Cat Burglar - Post-mortem: How We Shipped After Everything Went Wrong

Posted by pushfoo on 2021/04/17 22:17

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 .

An inspiring image: three orangutans around table, one asking

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:

Gorilla animation played backwards to

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.

Drones sprited and spawning

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.

A world with fake terrain, and two enemies spawning

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:

A Cat on the Gorilla's Back

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(

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.
Ugly but 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:

Randy Walking Rightward  The Gorilla with the Cat On its Back

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!

Add a comment

Cool Cop - Escape Game - Speedrun Records

Posted by CabCon on 2021/04/09 09:13

Current Record: 02:45:40


Add a comment

Gnorman's Copse - Development retrospective

Posted by Cosmologicon on 2021/04/08 05:01

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!

Add a comment

Snake Cop - Version 1.0

Posted by GamerC08 on 2021/04/07 20:35

Bugs solved. Version 1.0 avaible.

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

Add a comment