The files here pin/bundle the Pyglet dependency, which is not compatible with Python 3.7+.

An update is available on PyPI:

pip install jrti-game

Or on GitHub: github.com/encukou/jrti_game

If the game does not run for you (on Python 3.6+), you can let me know via a GitHub issue. (I'll be happy for other bugs as well, but I don't promise to address them – this game was a week-only effort.)

Thanks to everyone who played the game and left feedback! I’m really happy with how it turned out; I was pretty nervous that perhaps people would have trouble with PyOpenGL, but it doesn’t seem to have been a big issue. Apologies up front for the slightly long post :) just felt like I wanted to write down some of my thoughts. Congratulations to the team winners Larry and Dan, and congrats to everyone who participated for the first time and managed to finish a game! There were some really cool and quirky games this comp, I thoroughly enjoyed playing them.

I thought I’d write a few notes about the game development:

Using PyOpenGL and 3D models:

This was my first time using OpenGL 3D in a game, so it was a bit of an experiment, but I found it was relatively OK to understand. Two past pyweek games that I studied a lot to help me understand PyOpenGL were Bouncy the Hungry Rabbit and Eclipsed (I am still amazed that Eclipsed generates all of its 3D models in the code using no external resources). In order to generate the 3D models, I started off trying to teach myself to use Blender, but quickly found that the learning curve was too steep, and time was too short. In the end I fell back on some tools I’d previously used: I used Sculptris to generate the (randomish) asteroids (and followed a Blender tutorial to put a simple texture on it). I used OpenSCAD to do all the other models. I used Wings3D to colour all the 3D models (was using this for the first time this competition, and it was really nice and easy to use) and Meshlab to convert model formats.

One thing I never got to work properly was dealing with semi-transparent objects: I couldn’t understand out to depth filter all of these properly with the blending, so there are a few strange artifacts when the player’s view intercepts with a shield for example. 

Gameplay:

I think I got a bit lucky with the gameplay/balancing on this one (although some people mentioned the game was a bit hard), because I was rushed at the end, and spent relatively little time trying to tune this. I left the level development until pretty much the last day. The good thing about a stealth game is that there ends up being lots of ways to get through, and in a lot of cases, most of them probably make the player feel like they are doing to right thing, even if the game designer didn’t intend for the player to be able to get through a certain way. I also feel like I could have added a bit more variation in terms of different types of sentries, different objectives etc. if I had more time.

3D aspects of gameplay:

Probably the most challenging part of this experience for me was figuring out all the vector/rotation coordinate systems and working out how to make the controls feel natural and liberating instead of difficult and unintuitive. I spent pretty much a full day (I think around day 2) figuring out how the control system would work: in the end, the direction the hackerbot moves depends on the view: the ASDW keys map to camera-centric moving that are parallel to the vertical/horizontal directions of the screen. One issue here is that when you are standing on the “horizon” of an asteroid, the up/down keys probably feel more like they should move into/out of the screen, rather than up/down: I experimented with a system that blended between these modes based on how close the hackerbot was to the horizon (based on camera view), but I found the result made the controls feel even more confusing.

In terms of viewing angle, I made the decision early on to stick with camera perspectives that are fixed to the horizon i.e. the camera can pitch and yaw about the OpenGL XY axes, but not “roll” about the axis that sticks into the screen. I think this helps with visual orientation (which some people mentioned got a bit confusing anyway) but it gives the unfortunate side effect that the controls have “singularities” around the poles of the asteroids. I studied games like Super Mario Galaxy to see how they handle the camera perspective: there’s definitely a much more “fluid” feeling with this game, but the gameplay in this case is focussed purely on the “planetoid” you are currently on. In Hackerbot, I wanted the player to be able to have a “synoptic” view of the whole game space at any time, so they can plan where they will jump, navigate around, watch out for sentries etc. so this was my reasoning for keeping the camera this way.

Boss Battle and Future Work:

To me, when a game has a conclusive boss battle it adds so much: this gives a sort of “story arc” by creating a distinctive climax to the experience. I worked hard on trying to get a good boss battle for this game, but I only got about halfway through what I wanted to achieve. To be perfectly honest, it’s pretty much a stretch to implement this sort of thing in a pyweek with such a short time timeframe. My original concept for the “Juggernaut” was to have it slowly move around the play space and to create a situation where you had to “lure” it to certain asteroids and then jump away to create a situation where you could lead it’s laser fire into destroying shield generators. Then would come the “missile hacking”, after which hitting it with a few missiles, the Juggernaut would become “disabled” for 30 seconds, giving you an opportunity to “jump” onto it, crawl around and hack into a data port mounted on it’s back which when hacked would allow you to trigger a 10 second self destruct sequence. With another day to spend on it, I could have possibly got this all working and tune the difficulty so it wasn’t too hard. I basically ran out of time on the last day, so just ended up implementing the missile hack with a static Juggernaut (which was probably the most disappointing part of the final game for me). This is something that I might try to work on and include in an update for the game.

If you have actually read this far, thanks again, and hope to see you in six months for the next pyweek! I’m super happy that this comp exists and at the amount of time and effort people put into it!

Thanks to all who played and ranked my game.

I'm glad that quite a few people had fun with the game. It was a "clicker" and so the usual downsides apply. Sorry for those that don't enjoy those games and had to break their mouses (and fingers) to play!

Because I had only half a week I made an early decision to simplify and go for a clicker. I reviewed about 10 of the top rated ones I could find and highlighted the features that I felt would be fun. This resulted in the core feature-set of,

1. Attacks in waves

2. Boss battles to gate the progress

3. The different kinds of player-character power-ups

4. Creating a solid feel for the clicking with good sound and visual animation (never achieved this last one!)

I'm pretty happy with the core game but there were several areas that I really needed more time as mentioned by a number of players.

The balancing

Someone mentioned that they got killed out-of-the-blue. This was probably the snake, that deals a ton of damage with a very slow wind-up. But the player is right. The idea that different beasts would have different characteristics and so you would have to choose which order to kill them was quite central to making this more deep than just a clicker.

However, I didn't have enough time to balance this part. With so many different beasts, power ups and dimensions I got quite lost in how to adjust the attack, cost, damage, AC elements to create a compelling curve to the game. Most clickers get around this by just making things really "expensive" and using the players time (and boredom level!) to balance. I wanted to avoid this but this needed more polish.

Fun

I wanted the game to be fun and to play with the Sharknado theme but I didn't get to scratch too much below the surface on this. I was looking to have splash screens when side-kicks and bosses entered the game and also an ongoing storyline that was revealed as you levelled. 

I also needed some animation.

The beast graphics and side-kicks were generated from stock photos and the lunar pic online tool (https://www298.lunapic.com/editor/). This allows you to use neural network models to apply artistic styling to photos. It created a really interesting effect but I wanted to go a bit further with animation too.

Anyway, overall another fun Pyweek. Thanks to the organisers and all the other competitors. Your games were awesome. I'm always amazed at the quality and diversity of entries.

See you next time.

Paul

 

First of all, I thank pyweek hosts for giving me this opportunity.

Many guys felt my game too hard. I admit it's hard even for my standard. I really had no time to adjust the game balance. There should have been a moderate learning curve.
As I was a die-hard core gamer, I used to play games at the maximum difficulty setting. I still like tense and pressure. It easily makes me misjudge the balancing. Thus I learned the importance of testers. I should keep it in mind. I may choose to make a puzzle or AVG to avoid the problem.

I failed to deliver a complete game again. That's sad. I spent 3 times more effort on it than the last time. I estimated at least 1,000 lines of coding would be necessary for a complete one, and I cleared it. What I underestimated was making game data. Making sprites and maps almost got me killed. The game theme was taken from "Pummel the chimp" tutorial, and I planned to make title & ending images like that. I was so pressed for time, I gave up the idea. Eventually none noticed it.

When I judged other entries, I read through their source files. Some guys really composed it well. I learned many from it. I remembered many coding rules. I know mine is too messy, and needs refactoring. When my motivation is back, I will renew my game, and publish it at some other places.

Looks my game pissed some of you guys off, in that case, I did my job correctly.

I screwed up big time on a lot of things:

1. Yeah, my physics engine could've been better, I realized you shouldn't be able to run into walls (Usually on other physics engines I use for games, I fixed this, but not this time I guess.) and I realized the gravity was horrible, and the jumping seemed pretty weird.
2. I really should've done better on sound-effects. Even if I had got them from some free online site instead of trying to make them (not saying I did.), then I think I would've done a little bit better.
3. The "DerpCat" level was kind of odd, and I think I didn't put enough time and effort into it.
4. I didn't spend enough time on animations and special effects, I could have added some more things here and there, like that little gray dot nobody was able to identify (it was a laser cannon), I should've found a way to make it seem like it was shooting you. Problem is I really don't know how to do all of this. But I'm working it out.

I don't think I had a problem with the storyline or the plot really, I think I did pretty good on that considering how much time I put into it.

And yes, the game was supposed to piss you off, I intentionally did that just to try to make it a little more addicting, and to try to make it a little more tricky and fun. I also did for the sake of just pissing you off (I had some friends try it, they got kinda mad at it.).

I know all of this sounds very pessimistic. But at least I was able to identify what I did wrong and how I can do better, and what I need to keep doing and what I need to stop doing. I'm really glad I did this so I get to know what people really think about how I made this, and not a couple of my friends using sympathetic voices to say "Uhh, yeah, it's pretty good.". Thanks so much for all your input, and see you in a couple of months.

Check it out if you have trouble running the game and want to see what it looks like:

https://www.youtube.com/watch?v=jCwXWXOrQgU

I think I've finally figured out how to reliably capture video on Linux. Hopefully this will make gameplay videos for future games much easier.

Because of travel and work, I had less time than usual for PyWeek. I decided to go solo, which I haven't done since PyWeek 18, because coordinating always takes a lot of time, and scale back the scope. Given that, the game turned out okay.

For the core mechanic I focused on the word "behind" and what it means to be behind something in a game. I had just watched a Super Mario World ROM hack where there were platforms in both the foreground and background, and I thought, what if there were a platformer where things that were behind something in the foreground didn't exist, and what the player can see is reality. (I was also inspired by a popular indie platformer game Closure, where things that cannot be seen effectively don't exist.)

My original idea was a lot like the popular indie game Fez. In a way it was the reverse of Fez. Instead of an apparently 2D world that was actually 3D, I was imagining something that seemed 3D, but behaved like it was 2D. In fact, it was so much like Fez that I decided I had to change it (the entry I was on for PyWeek 12 was criticized for being too much like Braid, after all).

My first day of design was me asking myself, how can I make this less like Fez? I avoided a square grid and pixel art (which I generally avoid anyway). I switched the idea from a puzzle platformer to an infinite runner, and removed the ability for the player to control the camera directly. This meant I had to give the player the ability to move forward and back. With the infinite runner mechanic, the only way to "move" certain foreground elements in front of certain background elements is to change the moment at which you interact with them. This turned out to be a very crude method of achieving what I originally had in mind. I wanted the player to have to figure out where to stand for different challenges, but this is far too hard to do given the pacing, so I put up arrows to just tell you where to stand. I also realized that the ability to go left/right opened a long jump mechanic, but rather than try to design around that, I made it an explicit part of the game.

I always say that for a platformer, more than any other genre, you have to spend a lot of time getting the feel just right. The responsiveness of the controls really makes or breaks the game. I spent a little time replaying Canabalt, which is widely considered to define the infinite runner subgenre, and this inspired me to go faster and "heavier". I gave the character a lot more inertia than I normally would for a platformer, but that seems appropriate. I'm still a little unsatisfied with the character motion on slopes, but overall it's okay.

I made two subtle changes that hopefully you didn't notice. If you press "jump" while falling through the air, but within 0.2 seconds of landing, you'll jump as soon as you hit the ground. Also, if you press (and hold) jump while running, but within 0.2 seconds of reaching the ledge, your jump will be delayed until you reach the ledge. Playing it myself, I can't tell that it's this way, but it makes a big difference on how often I'm able to make jumps.

The graphics are not great, but as usual I was able to make it work with arbitrary resolutions by using procedural generation. Each hill is an image that gets generated as needed. I found a pretty effective way to draw hills as needed as the game goes along, while spreading out the work to multiple game frames so there's not a noticeable lag when a new hill is loaded. I'm thinking about extracting this part into a separate library for future use. Overall I'm getting 30-60 frames per second on my Intel NUC. People keep saying there's a limit to pygame performance, and I believe it, but I've never run into it during PyWeek.

I made the character have a dress so I wouldn't have to animate legs for the walk cycle, and I wound up swiping the overall character design from this animation.

I didn't have a musician for the first time since PyWeek 18, so it's good to see that Kevin MacLeod of Incompetech is still making great royalty-free tracks. I wanted to use ChipTone for sound effects, but it kept crashing my Flash plugin, so OpenGameArt came through. You think you'll save so much time by using pre-existing assets, but it's never as true as it seems like it should be.

I had a great time participating, as always! Thanks to everyone who made it possible, and the community!

This is a maze game that you must find your way out of. In each maze there are two mini-games which require some skill. One is matching words and colors. If the word matches the color, click true, otherwise click false. The other game makes you put all the numbers in a sequence. They are both negative and positive forcing you to count up or down. The minigames are times.

The idea came from an ideation session with our team. The game seems like a very good tool for children ages 6-12 to match words with their meanings quickly, and to sort numbers from least to greatest quickly. the maze requires some thinking and memory to get through, especially at the higher levels. And remembering the four digit pin will require a little work while trying to find your way through a complex maze.

The levels get more difficult as the game goes on, so the game is progressively more challenging. There are 70 maps and they are semirandomly chosen so the game is different every time. The mini-games give you less time and have more questions to solve.

Good luck and have fun!

Thank you all for your support!  I'm really doing my best to play through all of the games here, I love it!

I just tried to run the executable in a different version of Win7 and it did not execute successfully.  If you are a windows user you may need to simply run it from source, my apologies!

To do the compiling I used PyInstaller, which seemed to be working just fine, but there must have been something I've overlooked.  If anyone has tips hit me up, I'd love to hear them!

Otherwise, enjoy the new executables, and be sure to vote and award as generously as you see fit!  I'd like to do a lot to the code, but this was enough to get it working and really convey what the whole idea of the game was.  It's not supposed to be perfect, like pygame it's supposed to be pretty okay.

"My Sincerest Apologies" runs on Windows!

To make it easy on everyone, we've made a ZIP file containing a ready-to-run version for Windows. Just unzip this zip file somewhere and run the "main.exe" you'll find inside. You can download the ZIP file here:

https://github.com/larryhastings/pyweek24/releases

If you prefer to do the install manually, using an unmodified "my-sincerest-apologies-1.0.2.zip", here are the steps you'll have to follow:

1. If you haven't already, install Python 3.6.3 for Windows (32-bit), making sure to put Python on your PATH.
   
2.  Download the zip file for "My Sincere Apologies" and extract it to a new directory. I'll assume you name that new directory "my-sincerest-apologies-1.0.2".
   
3. Download and run the AVBin 32-bit Windows installer from here: http://avbin.github.io/AVbin/Download.html
   
4. Manually copy the file C:\Windows\System32\avbin.dll into the "my-sincerest-apologies-1.0.2/src" subdirectory inside the "my-sincerest-apologies-1.0.2" directory (where you extracted the game to in step 1).
   
5. Download and install GLEW for Windows: https://sourceforge.net/projects/glew/files/glew/2.1.0/glew-2.1.0-win32.zip/download
   
6. Open that zip file, and copy "glew-2.1.0/bin/Release/Win32/glew32.dll" into the "my-sincerest-apologies-1.0.2/src" subdirectory inside the "my-sincerest-apologies-1.0.2" directory (where you extracted the game to in step 1).
   
7. Download the AppVeyor-built lepton wheel: https://ci.appveyor.com/api/buildjobs/god4mlfk5y42se8q/artifacts/dist%2Flepton-1.0-cp36-cp36m-win32.whl
   
8. Install the lepton wheel by running "python -m pip install lepton-1.0-cp36-cp36m-win32.whl" in the same directory you downloaded the wheel to.
   
9. Download the AppVeyor-built lepton wheel: https://ci.appveyor.com/api/buildjobs/52tjrnjug61lo41d/artifacts/dist%2Flightvolume-0.1.3-cp36-cp36m-win32.whl
   
10. Install the lepton wheel by running "python -m pip install lightvolume-0.1.3-cp36-cp36m-win32.whl" in the same directory you downloaded the wheel to.
    
11. Install the other packages you'll need, by running this command: "python -m pip install pyglet pymunk six tmx"
    
12. Finally! Run the game by running by going to your "my-sincerest-apologies-1.0.2" directory and running "python run_game.py". Or, I think double-clicking on "run_game.py" will work.
    

We hope you have fun playing "My Sincerest Apologies"!