This was not a great game. Extremely repetetive, quadratic difficulty curve, (shaped like a U,) and boring enemies. Honestly, I'm not surprised by the bad ratings it got. (Except the part where it says 28% of 10 people marked it as not working. How is that possible?)
It seems that my predictions about this game were very accurate: "Might be extremely difficult for those that don't have ascii codes memorized" and "I highly doubt this game will win". (See earlier diary entries.)
One thing I learned: Making the player launch and move stuff is a lot more fun than having them (slowly) move so toggle bits and destroy stuff by doing that. This leads me to the idea that this basic game idea, with more animations and actually moving the bits would probably be pretty fun, except for the part where you have to match up with an unknown pattern.

In conclusion, I will do better next time!

When is that, exactly? Or where would I find out?

The rating comments suggest a general misunderstanding of my program's concept, therefore providing revised instructions.

Nexus Synopsis:

Nexus's virtual presence is supported by its data processing and integration. As Nexus's gatekeeper, guard the data flow to Nexus while removing flashing corrupt data. Ensure data transmission by confronting the infiltrating bots and repair the nodes damaged by their energy charges. To sustain the responsibility, manage power reserves used by energy pulses and node repair, the network current restores power and energy surges provide power boost while energy spikes drain power. Nexus's integrity depends on the data, if Nexus senses a threat of system failure it will initiate network shutdown.

Nexus Guide:

Protect the integrity of Nexus by maintaining data flow through the node network.

Controls

• Bot forward (UP/KP8/w)
• Bot reverse (DOWN/KP2/s)
• Bot left (LEFT/KP4/a)
• Bot right (RIGHT/KP6/d)
• Bot shoot (SPACE/KP0/z/LMouse)
• --directional (CTRL)
• Node repair (x)
• --directional (SHIFT)
• Start/pause (Escape/r)
• Panel toggle (p)

Status indicators

• -Nexus integrity (grey)
• -Bot power (blue)
• -Data integration (green)

Everyone else is doing it, so I will too :) (try to keep it brief) First of all congratulations to the winners of both the individual and team entries: these were both really top notch games, well deserving. As for Wizard's Data, I'm pretty happy with how it turned out. It was super cool to have a dedicated artist working on the game and to work on a team entry this competition. I'm pretty happy with the feedback we got; there really wasn't any really negative criticism and I'm most happy that we got 0% DNW. What I learnt from this competition: (1) Collision Detection/Management: Actually it wasn't so much collision detection that was a problem, more collision management. I went into the game thinking "how hard can this really be? I don't need to read about how to do this, I'll just do it ...". The game had a reasonable amount of collision management bugs (we got a nice award for it :) ), so before next competition I'm going to devote time to getting a better way of dealing with this aspect of games in a more principled way. (2) Time Management: I think I read in a past diary entry by Cosmologicon that his recipe for pyweek timing was 1/3 on developing the core game and 2/3 on polishing: I think I'm really going to try this genuinely next pyweek. We really didn't have a working game until day 5/6, and (unfortunately for me) I was quite sick on day 6/7, and became pretty unproductive here, so the race to the finish was spent finishing the game rather than polishing. I felt we had quite a few rough corners. If you have read this far, then congratulations to everyone who participated this comp; there were a lot of really great entries. I'm so glad this competition runs; this was super fun for me and obviously I don't do game development for a living so it's awesome to have an outlet to do this, and people who share a passion for games and are willing to give detailed feedback. Thanks to everyone who played and participated!

Thanks a lot for your comments and ratings!

Most of you commented that it was a difficult game, but hopefully it was not too frustrating. On the other hand, one of you solved a large board without using breakers. That's impressive: I found it very hard to solve a large board with two breakers.

It is difficult to balance this game properly. The randomness is a bit hard to control and I think this is the main issue with the game. I put the breakers because I couldn't really control having parts that are not reachable, at least not without spending some substantial amount of time on it. It's possible that you have a bad or good experience simply based on luck. There are probably impossible levels being generated, but hopefully in most of them every tile can be reached with some combination of breakers. The breakers turned out better than I expected, because now there is some strategy on the locations to add breakers if you want to identify lower tiles. I was also worried about another effect of randomness: I was hoping that the random configuration of pieces wouldn't induce the player to make a wrong choice in the beginning, leading to a hard time in the end. No one mentioned that, so hopefully that wasn't an issue.

About the theme: at first I didn't give it a high vote, but now I'm glad it was chosen. There were two ways to view "data" in this Pyweek. Most games chose the "digital data" approach. On the other hand, from a scientific perspective, it is very natural to see data as the information we collect to learn more about something. There is a lot of potential in that interpretation for a game idea. Here, you are doing experiments to discover the structure of the board. My initial idea was to make a mysterious object where you had to do some experiments to find out what it was, but it was too vague and I didn't manage to put it in paper in an interesting way. I decided to restrict myself to experiments that were concrete, specifically observing physics. The pachinko idea followed after I restricted myself to physics. I feel the theme naturally taps on this idea of exploring something unknown, which can lead to some good game ideas.

Speaking of ideas, one of the reasons I prefer Pyweek over shorter game jams such as Ludum Dare is that a week is so much better to think about ideas. This time I didn't touch any code or art for half of the week, partly because I was busy traveling, but partly because I wanted to find the right idea. It's good to let ideas stew in the back of your head. Sometimes the idea never comes, which has often happened to me in previous Pyweeks, but it's really satisfying when you finally get an idea that you are happy with. I knew that this idea would be at least cool to explore, despite not knowing whether it would be fun, and implementing an interesting idea is enough to make me satisfied with my submission (whether it turns out to be fun or not). In the end, this turned out better than I expected.

One last thing: this Pyweek, 20, marks about 10 years since Pyweek 1, back in 2005. Time flies very quickly and I definitely don't have as much time as I used to have back then. I didn't submit a game in Pyweek 1 (though I tried), but I still remember that the theme was "Power" and the idea I tried to implement (stop digital bugs from reaching a power core, which happens to fit in this Pyweek's theme). My first submission was on the second Pyweek. I'm glad that I caught it in the beginning -- it was timed pretty well with the time I was first dabbling in Python. My Pyweek user name happens to be generic because I didn't think Pyweek would end up being so important for me. 10 years later, I'm still here. I'm not a game developer, so I'm very glad that Pyweek exists so I have an excuse to scratch that game development itch that I occasionally have. I look back at the list of games that I made and there are so many good memories, not to mention the great community here.

As always, congratulations to everyone who created a game this Pyweek! Making a game in one week is always a feat. Special thanks to blakeohare for stepping up to host this Pyweek! Thanks to Richard for setting up all the other Pyweeks!

See you all next time!

The Name

“The Gödel Sentence” is a true but unprovable statement. It comes from Gödel’s incompleteness theorem that says that in any closed system there are things that are true but you can never prove them. The Gödel sentence is such a truth.

My game was about making decisions with incomplete data. There are truths about the world and the people that you cannot prove and yet you still need to make a decision; you have to decide who gets water, you have to decide who lives and who dies.

The name is also a pun on the word “sentence”. Your job, in deciding the fate of the five people, is a punishment. You are sentenced to choose. There is no right answer to the game, there is no way to win and so you are a prisoner to the role.

A Rhetorical Game

I read Ian Bogost’s book “Persuasive Games: The Expressive Power of Videogames” (https://kindle.amazon.com/work/persuasive-games-expressive-power-videogames-ebook/B001ITLCVS/B005VQ015W) . It describes a way of making games that are intended to give the player a deeper understanding of systems. Games designed around a “procedural rhetoric” allow the player to explore a model for how something is working.

I loved the idea and wanted to try to make this kind of game. I chose to base the “rhetoric” on the decision making process. In any decision you have a decision maker, a decision, a time deadline, some facts feeding into the decision and some outcomes that the decision maker is trying to optimize. I set up Gödel to have these very elements and pretty much nothing else.

In the game your only action is to decide who gets water and who does not. The facts come to you through the conversation and the occasional chart. At some point in the game most players will have to ask themselves what the basis is for their decision. Since there is no way to win the player may start to question and doubt the basis for their decision making. At the end of the game the player may reflect on how they came to the decisions and whether they would make the same ones again.

A Single Play Game

In order for players to have the experience I wanted I felt it was important that they knew they only had one go at the game and that they could not just save and reload and try again. It was part of the “procedural rhetoric” that a decision, once made, is permanent.

And here I cheated! Anyone who tried it knows that you can play the game again. About half way through I got worried that there might be a bug or some other reason that people had to run the game multiple times and in the context of the competition this felt like too big a risk.

So I bailed on the idea of enforcing the run-once feature but I continued to refer to this in the game load screen and in the help text. I apologise for this deception! I felt it was necessary to get people to approach the game in the way I intended and I thought that saying “it’s intended you play this only once” wouldn’t achieve the same effect.

World Building

World Building was a new technique for me and helped tremendously. I read Veronica Sicoe’s excellent blog (http://www.veronicasicoe.com/blog/2012/05/13-worldbuilding-questions/), which provides a list of questions to use to build a picture of the world your characters are living in. There are similar questions for your characters and their character arcs.

Answering these questions really helped me to build a clear picture of the world and who the characters were and who I wanted them to be by the end of the game. This made dialog much, much easier to write. Time spent in tuning aspects of the world paid back hugely when I got to writing specific conversations and monologues.

It’s not just about making it easier to write. Even though lot’s of the world building “facts” don’t make it into the game they tend to bring much more coherency to the experience.

The Characters

I wanted all the characters to be different and bring their own strengths and weaknesses to the group. It was important that there are no obvious heroes and villains since the player is supposed to have to find their own basis for decision making.

The facts reported to you, like the hydration level etc, are intended to raise suspicion but remain ambiguous. This is part of the “incompleteness” theme.

Has Amber found another well and is she keeping it to herself? Is Dax secretly eating more food? Is Brock trying to manipulate others and turn them against each other? Is Crystal going to endanger the group by bringing strangers in? Is Eva a disruptive force? Will her anger boil over?

None of these questions are resolved in the end. That’s partially by design but I would have liked to have resolved some of them because not answering any questions makes it seem a bit too loose.

The Music

I really got lucky with finding the background music on the Free Music Archive. I wanted something that would evoke the unnerving, unsettling world that the characters were in. The music had to be dynamic with highs and lows. And it had to last for the whole length of the game!

I’m so impressed that others achieved dynamic music in their games. I’d love to try this in a future game. I had to rely on the dynamism that was already in this piece.

There was a great quote from Philip Glass on making music for films where he says that he likes to create a distance between the music and the on-screen scene. Pair some sad music along with a relatively happy scene. Put some upbeat themes against a calm section of the film. He says that this creates engagement as the viewer needs to use their imagination to link the music and the action. “What is sad about this happy scene?”, “What is the underlying dynamic nature behind this calmness?”

Since most of Gödel is in the player’s mind I wanted this music to create some of the distance too. Just listening to the track on its own is a journey but not necessarily the same journey as the characters in the game.

Is There a Way To Win?

I think it is impossible to save everyone, which was by design.

You can save three people and it may be possible to save four if you immediately decide to sacrifice someone but it’s unlikely that anyone could find that in a single playing. Brock drinks quite a bit and his health drops quickly when he is thirsty. Eva and Dax don’t lose health so quickly so you can allow them to go thirsty.

This assumes your decision basis is to try to maximise the number of survivors rather than, who in particular, will survive. You can easily save one or two specific people. If you try to save everyone or prolong everyone, then you can end up with nobody alive at the end!

I built a spreadsheet model of the core health / water system and used this to tune the settings. This turned out to be immensely useful as the underlying model has lots of parameters and starting properties. The spreadsheet allowed me to play around with these very quickly to make sure I had the right balance.

Playing with the spreadsheet was quite a lot of fun and I wondered if I should expose that as an alternate play mode of the game, cutting out all the dialog altogether. I didn’t have time for this but I may think of this for the future.

Pygame and Pgzero

I used pygame and pgzero which turned out very well. Pgzero is quite mature considering its young age and takes on most of the heavy lifting with the sprites, sounds, and animation. The auto-loading of resources makes it quick to add content.

I had to add scaling, rotation, and visibility for pgzero’s actor classes and I built a Text actor to handle the text rendering in a consistent way. I needed dialogs and gauges but appart from that there wasn’t much work on the engine.

The animation system works very well with pgzero. I’m really happy with how the clock and water came out and this is mainly down to the animation. The core widgets are simple and the animation makes them look like they have some physics in there when they really don’t.

Overall

I’m very happy with how the game turned out. Thanks to all who played, ranked, and commented. I really appreciate that. People’s comments seem to indicate that the game achieved the effect I was going for.

As always it was a challenge to get everything done within the week. This time around I only had up until Thursday to work on the game and that posed a different kind of challenge since I could not rely on the final Saturday and so had to complete during the working week.

Project management and being ruthless about working on the most important aspects of the game at any given time are always key to completing.

See you all next time!

Paul

Now that the judging period is over, I'll go ahead and share some thoughts about the game and its development, both good and bad :)

Overall, I enjoyed reading all of the feedback, and I'm glad that most of you enjoyed the game. No game is perfect, of course, and many of you brought up several points that I agree with. Thus, let's start with the bad parts first and get them out of the way :p

One of the most obvious areas of improvement that can be made to the gameplay, at least to me, that could have been improved was the difficulty of the game. It could have been toned down a lot and still be fun. The last group of levels, which not many people reached, should have just been simplified or demoted to post-game bonus level status. What's an even bigger problem is that there are bad difficulty spikes in some of the 2-x levels that could have been easily smoothed out. I think I tend to make levels too hard instead of too easy, and it's probably because I like playing challenging games, so I make levels that would be satisfying to beat for me. However, a while after I uploaded the final version, I thought "this might actually be too hard overall", but by that time it was too late by then. My PyWeek #16 entry had this problem as well, but all the levels were unlocked from the start in that game, so it didn't really matter there. Of course, there could have been difficulty levels, but I think that's easier to implement and test for games that don't have fixed level designs. I really wouldn't want to test every level twice :p I suppose it's better to make levels that are a bit too easy instead of too hard while still maintaining a smooth difficulty curve, and if I have leftover time, I could put the really tough levels in some sort of bonus category. The ideal situation, I think, is that people are able to finish at least the main portion of the game.

Another way I could have made the game less frustrating was to shrink the player's hitbox so that the blue part of it only counted when collision with enemies or firewalls is being checked. Clipdeaths are not fun (just look at that award :p), and I wish I thought of that while developing the game, not several days afterwards. Little things like this can really make a difference.

Something that I should experiment with in future entries, which at least one person in the feedback brought up, is adding some acceleration or other physics to the player character. So far, all my entries have been either "the player moves x units or the player doesn't move at all," which can be rather boring.

There's also a few things on the development side that I could have done differently, too. When I was adding sounds to the game, I found myself searching through 1000+ lines for the right location to play the sound in, which was a waste of time. I could have easily avoided that if I put a placeholder print() statement that said something like "the fire burning sound would play here" or something like that. Then I could Ctrl+F later and find that line easily. Also, I was reading through PyGame documentation a few days after the week was over, and I realized that I forgot to call convert() on basically every surface that represents an opened .png. That would explain why the FPS on the title screen is so much lower than in every other screen in the game since the title of the game is a relatively large .png file. I have to remember to do that next time. Finally, menus.py is over a thousand lines long and I hope I don't have a file that big again, especially since there's a fair amount of copied and pasted code in that file.

With most of the bad parts out of the way, I suppose I should mention some aspects of the game that I'm proud of. First of all, the main difference between this entry and my previous ones is that the production aspect is much better, and that's mainly because I devoted a lot of time to searching for appropriately licensed assets and modifying them using my very limited GIMP and Audacity skills. Some of the work was a bit tedious, such as scaling those locked wall tiles from 16x16 to 32x32 or lowering the volume of most of the sounds. It paid off, though! I also added music this time around, and I have no idea why I didn't do so in earlier PyWeek entries, as it really makes a difference and doesn't take much time at all if you know where to look.

Also, I really liked how the Tetris-like puzzle sequences turned out, although perhaps I should have made the later puzzles a bit easier. It's my first time figuring out how to do something drag-and-drop-based like that, though, and I'm glad that I was able to implement it. If I resorted to an alternate keyboard-based implementation, it would probably be less satisfying to use.

As for the story, I'm glad that some of you liked it :) There's probably all sorts of newbie storytelling mistakes and plot holes in it due to it being written near the deadline, but at least it was entertaining enough. I personally don't like how the story turned out, but that's just me being critical of my own work :p

I suppose that's it for now. There's probably a few things that I forgot to bring up, but this post-mortem is long enough. Hopefully I'll be able to participate in the next PyWeek :) Maybe I'll try to make something that is more out of my comfort zone next time.

This is just a bunch of random thoughts. I wasn't able to edit it into something more coherent. Don't feel like you need to read it.

This entry was important for me. It assuaged the frustration I felt after The Forgotten Angel, my PyWeek 19 entry. That was supposed to be a plot-heavy action game, of limited difficulty, with a mysterious, unfolding storyline. Although the core mechanics were implemented, only about half the plot was there, and there were a lot of rough edges. I had voiceover planned, but I ran out of time. Beyond the Horizon had many of the same goals as The Forgotten Angel, but it was actually complete. Overall I'm happy with how it turned out.

One thing I always aim for is introducing material (both story and mechanics) as you go along, instead of one big dump at the beginning or end. This requires a lot of care: if you mess up, players don't have all the information when they need it. But I think it makes a big difference in immersion. Beyond the Horizon actually has a playable cold open, which is a first for me. It's great from a dramatic perspective because it means the player is paying attention for the title screen (and I put a lot of effort into the title screen this time).

Another thing I aim for (not always successfully) is economy of controls. I want to make the controls as simple as possible. Usually that means keyboard or mouse only, not both. When it is keyboard, arrow keys plus one action key, maybe two. Midway through this time I realized I was up to four action keys, but I was able to bring that down. I combined two into one by making hold and tap of one key do different things. And I eliminated another by making different ships each do a single action. I was happy with that. I don't know how much of a difference it makes in the end, but I feel like it's worth it. It's so easy to let controls get overly complex.

I had voiceover for the first time in PyWeek this time! Voiceover is great, because then people can't skip the story, and you don't need to write the later part wondering if they heard the beginning. I think it's also easier for people to absorb. But, obviously, it's a lot of work. When you're coordinating with different people, things serialize, which makes the deadlines that much tighter. I needed to have all the game mechanics decided on Tuesday, so the story could be finished by Wednesday, so the voice actors could be done by Friday. And of course it helps the artist to know what the characters sound like, and vice versa. By the time the playtester got the game on Saturday, there was absolutely no way to change the core mechanics in a way that would be reflected in the dialogue. (There was one minor thing I needed to change to prevent the game from getting into an unwinnable state, but it contradicts the dialogue. I just changed it and hoped nobody noticed that the dialogue was slightly wrong.)

So the game mechanics and story were a bit rushed. I originally wanted you to have to build a network of connections between the surface and objectives, and to fill in your map as you explore. I felt like this wasn't really coming together, so I dropped it on Wednesday in favor of simply locating objectives. And instead of you finding or placing things and having them added to the map, stuff just shows up on the map and you go to it.

That was probably the main thing I wish I could have spent more time on. The sense of exploration and discovery was not as great as it could have been. At one point in the game, you start locating what are called "convergences". Originally you would need to follow the pattern of bubbles in the background and look for where they come together. But, I was worried this was way too subtle, and I couldn't think of a good way to hint at it without running the risk of players completely missing it. So now convergences just get added to your map and you go there. (Actually, the follow-the-bubbles thing is still in there, and you can use it to find convergences that aren't on your map, but I'm guessing nobody noticed.)

So the gameplay didn't hold as much of a sense of mystery as I originally wanted, but I think the game still has that sense, with the storyline, the special effects, and especially the music. I think marybee did a great job on the music. The main game theme is accomplished with three channels of sound of increasing drama and fullness, all of which are looping throughout the whole game. Their volume is varied to crossfade between them, depending on how dramatic the scene is supposed to be.

As I said earlier, the storyline was rushed, but it's okay. I wanted to foreshadow the ending, so that it wasn't that confusing, but I think I overdid it and now it's too obvious. There's also a couple plot holes I didn't have time to deal with. One thing my playtester pointed out, that I feel dumb for not realizing, was the fact that I have two things called a "horizon" and it wasn't clear from the dialogue that they're different. It was too late to change the dialogue, so I just labeled them on the map. This alone made having a playtester worthwhile, for me, since something like that can completely confuse players. I also wasn't sure that people would know the astrophysical term "horizon" to mean a boundary. I figured people had heard of an "event horizon" but might not know what it is. Hopefully the title screen helped with that, but I don't really know.

The core teleportation mechanic and the circular geometry were pretty much unchanged from the very beginning. Even though I had to change some mechanics, I feel like I lucked out with the teleportation. Not only did it work from a gameplay perspective, but it complemented the storyline well. I wanted teleportation to feel liberating, while flying ships felt stifling. I wanted players, by the end of the game, to feel comfortable hopping from ship to ship quickly, so that you sympathize with the main character. The mechanic of different ships only having limited abilities is important here, as it forces players to teleport even when they don't need to move up. I always make it a point to start with my core mechanics inspired directly by the theme. Sometimes I wind up adding on enough other stuff that it's not obvious, but this time I think the connection to the theme remained pretty apparent.

On the technical side, I used two new libraries that I wrote since last PyWeek, enco and ptext. I really like them. I know everyone really likes their own libraries, but what are you gonna do? If you think the text in this game is well done, I do recommend checking out ptext. I thought of a couple features to add to each one, too. I'm pleased that I was able to support arbitrary resolutions. I think I've got a good technique for it now, but it definitely needs to be a decision you make from the very beginning. This was my first time supporting Python 3 as well. There's really not much to it, but I still haven't worked out a satisfactory import setup that works for both 2 and 3. Maybe by next time.

All right, like I said, that's just a bunch of random thoughts. Thanks to everyone who played!

Here's a handy play-through video: https://youtu.be/xiaiKwy975I

So, while reading my comments a week into judging period, I found out that my zips have no data folder in them. Since this contains one failry important document, it is a problem. As a simple fix for anyone that found this, go to levels.py in the BitstreamManipulators directory and comment out line 13. This will skip the instructions, but should allow you to play the game properly. Sorry for not checking before I uploaded!

EXAMPLES:

Example 1 [doc/art/sav/2.txt]:
!_<.>!~??~!_[..]!
First two exclamation points means between them you need to describe commands.
There is one description: _<.> which means that command _ is binded to first command (which is moving left/right)
~ means next part these two question points mean between them you need to describe scans.
There are no scans described.
~ means next part rest of it is real code
!_[..]!
these two exclamation points indicate that between it's command between them, command is _ (which we binded to first command in command section).
there is parameter in [] it's two (..) and that means that robot will go right (or turn right if it's flying robot).
When code execution ends it repeats.

Example 2 [doc/art/sav/1.txt]:
!_<.>:<..>-<...>!~?.<..>?~(<?.[..]?>||..)<!:!>:(<?.[..]?>||...)<!-!>!_[..]!
Command section is: _<.>:<..>-<...> which means _ is binded to first command, : to second and - to third.
Scan section is: .<..> which means . is binded to second scan.
Code section is: (<?.[..]?>||..)<!:!>:(<?.[..]?>||...)<!-!>!_[..]!
We have if at beginning. Condition is in ():
<?.[..]?>||.. <??> means between them is scan. It's . (which we binded to second scan in scans section and it scans things in front of robot).
there is parameter in [] it's two (..) and that means that it will return 1 if nothing is in front of robot, 2 if there is wall, 3 if there is enemy.
|| means ==, so if scan return 2 (..) it will be true that means if it's wall in front of robot.
If condition is true code between <> executes, so command : executes (command binded to second command - jump).
: means else and () is another condition (so it's actually elif)
In condition there is: <?.[..]?>||... which is like previous condition but has 3 on end so if in front of robot is enemy it will be true.
If condition is true code between <> executes, so command - executes (command binded to third command - fire).
After it there is command (note: that command will alway be executed):
_[..] command _ executes (command binded to first command - walk). It has parameter 2 (..) so robt will go right.