My first OpenGL game just had you fly through space and land on a few shapes. I randomly made one shape almost black, and the only way to find it was to notice it blocking out the background stars. I loved this part. Staring at the screen, catching a star winking out of the corner of your eye, and then racing to catch it before you lost it and it disappeared again. I found it thrilling.

Later I tried the game on a different monitor, the black shape was much easier to see, and it wasn't fun anymore. An impossible to notice difference between black and almost black on one setup can be clear as day on another. Even the viewing angle for LED displays makes a huge difference: the game went from hard to trivial just by tilting the laptop screen a little.

I think this might be why you don't see this mechanic in video games, at least I don't know any examples. But I've always wondered if there was some way to use it reliably. So this game is my best attempt at making this black-object-on-black-background mechanic work. We'll see how it turned out.

Clearly I needed a way to adjust the prominence of the background. It took some tweaking but I got something I'm happy with. But then how to choose the right setting for any given player? I went the route of trying to describe what it should look like, and asking the player to adjust it until it looks right to them. One alternative I implemented but abandoned was a calibration minigame, where the player has to click on a black box as a background gradually brightens. Different approaches have different issues, which I'm sure you can guess some of.

I'm definitely interested in any thoughts you have on ways to make this idea work better. Thanks for trying the game and thanks for putting up with this little experiment!

So the answer to the question we posed to ourselves in the last blog, could we get the final boss programmed in the final hours? Sadly, the answer was no :(

But thats ok! We still think we got a nice concept out there for people to waste some time on :)

What else did we not get to do?

Well, the elephant in the room would be how almost all the assets being used are resources included with the Arcade library, haha. And the backgrounds are free resources provided under creative commons - see readme for credits. We would have liked to use some more unique assets, but we are programmers first and artists second :)

Lastly, one of the big gameplay hooks we wanted to implement was getting an upgrade to your ship after defeating a boss. Unfortunately, we just didn't have time to implement that. The ultimate goal was to make the game similar to Mega Man where you can freely choose which boss to engage and beating a boss gave you a unique weapon that would help you against other bosses.

We've also finished our game!

As we never mentioned it: The premise of our game is that you, the player, are a dark matter mage. You shoot orbs of dark matter and utilize the power of black holes to fight your way through hordes of enemies. If you manage to survive, you can challenge the sungod himself.

In the end, we had a bit of a struggle with panda3d and performance issues... but problems and challenges are what make PyWeek fun :)

Both of us are super excited to see what everyone else came up with.

And as this is our last diary entry: Goodbye to everyone, and we are looking forward to seeing everyone again in the next PyWeek!

In practice, though (especially, in US time zones), it's not as much time as it sounds like. Especially depending on how many work emergencies come up during the week, and how burned out you feel (and what degree of a headache you have) by the time you're ready to switch to Video Game mode...

It doesn't seem like our entry will be particularly playable in time, but it's been really nice to get back into a creative project! And it seems like we do want to keep working on it beyond the end of this challenge (if only so we're more prepared for next time...)

I am impressed with all the new features that Tiled has added since I last used it, though the UI continues to be challenging. (Lots of submenus you can accidentally close, and then have a hard time finding again.)  I wasn't expecting to be able to use it to  generate random terrain, and was especially pleased with the Tile Transformation system - being able to generate a full "blob" tileset from only 15 hand-drawn tiles is really cool! I just really wish they hadn't dropped support for expressing those rotations in the output files, which kind of defeats the purpose? (Unless I'm missing something, which is totally possible...)

Sadly it wasn't until Saturday afternoon, hours away from the due date, that we were actually getting close to something playable, and cranking out some decent (placeholder) sprites and animations... But I am looking forward to doing more justice to this concept in the future!

Sunday - We got a late start and then spent some time talking about what kind of game we wanted to even make in the first place. We settled on a shoot'em up and we decided we would shoehorn the theme in around killing enemies to charge up your "dark matter" drive for your space ship :)

Monday - Basic programming of player and regular enemy movement and weapon firing added

Tuesday - Audio added, menus, logic for different boss encounters added

Wednesday - More gameplay conditions added as well as proper collision detection

Thursday - More back end gameplay mechanics added/refined and one of 4 boss fights implemented

Friday - 2 more boss fights implemented

Saturday - Refinement to enemy and the 3 boss behavior added, package rounded out with readme, requirements, instructions, etc.

With only a few hours left on the challenge will we get the final boss fight added? Find out in our last blog entry to see what we missed out on wanting to add as well!

Hello there,

I'd greatly appreciate any feedback regarding potential bugs or suggestions. If you have any insights, please visit the linked GitHub repository to share your thoughts.

For those who'd rather not run the software from the source, I've uploaded separate binaries for Windows. Additionally, I've bundled the embedded-python-zip alongside the source, and provided shortcuts to launch the game with various options. Rest assured, there's no compiled code from my side.

While instructions for running the software from source are documented in the README, I'll reiterate them here for your convenience:

Installation & Setup:

To install the necessary packages:

pip install -r requirements.txt

For Linux users:

sudo apt-get install libopenal-dev
pip install modernal==0.9.0

To launch the game:

python run_game.py

Command Line Arguments:

--no-fullscreen: Launch the game in windowed mode.
--no-audio: Mute the game audio.

Game Controls Without a Mouse:

Move: W A S D
Turn: Q E
Shoot: CTRL

However, I strongly recommend playing with a mouse, as it offers a vastly different and immersive experience.

Additional Tip:

If you find yourself wanting to explore all the ships but don't want to grind through the game, feel free to modify the score.txt.
Deleting it will reset the game. Enjoy!

Yesterday, I rolled out a release and confidently labeled it as "final" (oh, the irony of that "final" tag).

Today, while testing the code across different platforms, I discovered a significant audio glitch that affected Linux users. It resulted in lags and, in some instances, outright crashes. I promptly turned to the pyglet documentation and adjusted my code, hoping that letting pyglet handle the main loop would solve the issue.

Alas, it didn’t. Tweaking the audio backend offered no relief. And pivoting to pygame.mixer? Not a feasible solution.

In the end, I had to resort to a less-than-elegant quick fix, inserting an ad-hoc patch specifically tailored for the affected platform.

Allocating an extra day before the deadline proved invaluable. The fix was implemented successfully 10 hours before the deadline.
While I uncovered numerous bugs in my dependencies, in reality, these are minor inconveniences. They include:

• I could not record video of the pyglet fullscreen window on windows (it should be borderless fullscreen, no option for that).
• I could not make an audio loop with pyglet.media
  
• I had to do my audio handler, for some reason audio was playing out of range. To detect such I had to look for playing time > audio length.
• I had to hack wav format on raw data to play it with pyglet.
• PyGLM objects are not immutable.
• PyGLM quaternions passed to GLSL has a messed up x, y, z, w components
  

After testing on multiple platforms, I had the impression that a linux environment is hostile to gamedev.
From my perspective all the issues I found are really easy to fix, maybe just no one addressed them before.

Having learned from this experience, I feel motivated to create an out-of-the-box solution for the window + audio.