Boot Screen

GD

Story:
Workin' For The Man is a futuristic interactive computer simulation. The game puts you in the role of a crack Computer Forensics specialist in the local police bureau. Day in and day out it is your lot to pillage an endless train of broken and booby-trapped electronic devices and scour them for admissible evidence against the purveyors of vice and graft. Today is no different. The smashed heap unceremoniously dumped on your table by a mirror-eyed, burly COP clone is an inert hulk of metal, plastic, and rare earth for you to reassemble, jolt back to life, and torment for its secrets. "Do yer thing, doc," he jokes without humor. Some days it's a rewarding job, most others a curse to scratch your eyes out for. What'll it be today?


Important: Please see this discussion for the solution about the tar-gz download bug. https://pyweek.org/d/7153/#comment-14370

Important: This game requires a mic and additional software to play. Please thoroughly read readme.txt for software requirements, game instructions, tips, and tricks.

More important: The boss puzzle is very evil. There are progressive spoilers at the end of the readme. Go slowly, unless you're a shameless donut-chasing cheater.

Awards

Give this entry an award

Scores

Ratings (show detail)

Overall: 2.5
Fun: 1.5
Production: 2.3
Innovation: 3.8

60% respondents marked the game as not working.
Respondents: 4

Files

File Uploader Date
Boot_Screen.png
Boot Screen
gummbum 2021/04/04 20:19
Workin_For_The_Man_Team_GD-1.2_final.tar.gzfinal
Workin' For The Man v1.2 final
gummbum 2021/04/04 19:37

Diary Entries

Pyweek 31 - postmorten on the speech to text experience

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

uploaded final v1.2 - summary

I learned many things this pyweek: tts, stt, multiprocessing, subprocessing, queues...

.. but then the game part lacked a bit. But I think it was not the struggle about the technologies that slowed me down, but the lack of a clear vision for the theme.

In case you don't know what those abbreviations mean:

tts: text to speech

stt: speech to text (yes, you will have to talk into a microphone)

...and the other things can be read in the python help.
Here some hints about multiprocessing:
  • it uses 4 processes at once
  • it uses queues to commincate
  • logs are redirected from all processes into one
  • there is a watchdog mechanism in the main.py so when a child process dies it stops everything
  • something that I was not aware of: if a module does things during import then the import has to be in the method that is run by the subprocess (this was one bugfix for linux using the sounddevice module in stt.py)

But hey, the game has a puzzle besides all the audio fun. Enjoy.

Add a comment

Bugfixes - underway

Unfortunately we could not test our game on linux until today with the help of people from the discord channel. I turns out that we had some minor bugs. After this I think it will be the final version.


If you already have tried to play the game and got stuck in a loop where you can't get rid of the 'help' then please try to play our bugfixed version (>= 1.2).


If you still have trouble running our entry, please don't hesitate to contact us for troubleshooting.


We haven't tried it on OSX. It probably will work, but there is chance that it does not.


1 comment

Final 1.1 - cut the file size in half

I have re-packaged the game and removed some excess files.

Add a comment

Struggling with the technology

Still struggling a bit with the technology but getting slowly there.


I hope that tomorrow I will be able to start design the players experience and getting the user interface ready for play.

Add a comment

Day1 - Theme and game idea selection

We had no good ideas for the themes. Neither had we a good idea for a game either. Except for some vague 'it could this kind of game thing'. But even after knowing the theme, we are still struggling to find the game we want to make.

So my goal for today will be to collect all ideas an make a plan on how to implement them into a game.

Add a comment