Back in 2014 I took an online “Coursera” course called An Introduction To Interactive Programming in Python offered by Rice University. Before the course I hadn’t done any Pyhton so learned a lot and really enjoyed the language, unfortunately, since then I haven’t had the opportunity to use Python very much so I have forgotten most of it.
The final project of the course was to write a simple space shooter type game (very like Asteroids) called Rice Rocks. This was a lot of fun and I ended up adding a few additional features to the game (some additional weapons and the basis for a power-up mechanic).
All the development for the course was done using the provided CodeSkulptor web based development environment, which is pretty cool and I’ve used it since when I need to prototype small pieces of code or algorithms quickly. But I’ve always wanted to write a standalone version of the game.
So, my plan is to rewrite my version of Rice Rock as a standalone game using the PyGame library and the PyCharm Python IDE.
Refresh my knowledge of Python and learn how to write in a more “pythonic” style
Learn how to use the PyGame library
Learn how to use the PyCharm IDE
Improve my Linux knowledge (I’ve recently switched from Windows to Fedora on my my development PC)
Maybe inspire others to give Python a go too (I’d highly recommend the Rice University Course)
Have a little bit of fun
Oh and here is my Devember Contract
Contract
I, Shecks, will participate in the next Devember. My Devember will be a PyGame based game called Space Rocks. I promise I will program for my Devember for at least an hour, every day of the next December. I will also write a daily public devlog and will make the produced code publicly available on the internet. No matter what, I will keep my promise.
I think that’s it … as @Dynamic_Gravity has pointed out, I am a few days late so I’d better get started
Day 2 (Well still day 1 but I am behind by 4 days)
Lots more Googling and a little bit more done:
Fleshed out my ‘Scenegraph’ idea for the game a little more (May have to revisit this after reading up on PyGame Sprite module)
Figured out how to load and draw images with PyGame
Wrote a few utility classes to load and cache images as well as draw image sections from tile sheets
Tested my scene updating (the background scrolling debris works now)
Commited changes to my GitHub repo
Things to do next:
Learn about PyGames Sprite module, seems I could be re-inventing the wheel a little bit. For the original project I wrote my own scene graph code (a fancy ordered array) to manage all my scene objects and render the screen using the painter algorithm. But it looks like something similar might already be available in PyGame
Figure out how to do ‘imports’ in Python correctly. My idea is to have a simple game library with generic helper classes and I’d like to be able to reference classes like ‘gamelib.SceneGraph’ or ‘gamelib.TileSet’ but I can’t figure out how so there’s a lot of ‘scenegraph.SceneGraph’ and ‘game.Game’ references with seems very redundant
And the progress so far … space the final frontier
You’ll have to imagine the background debris scrolling to the right and the ship is currently experiencing engine difficulties
Day 3 (Still day 2 but I’m still behind so still cheating)
Another day of Googling, refactoring and trying to remember basic math.
But got some stuff done:
Read up on PyGames Sprite module and yes, there’s support for drawing sprite groups in layers so it will handle rendering the scene using the painter algorithm. The upshot is that my scene handling code had to go and I’ve changed my code to use the PyGame ‘Sprite’ class as the base class to all scene objects.
2, Spent a lot of time figuring out how to rotate sprites/surfaces in PyGame, ended up swiping some code from the web but I need to review it. PyGame doesn’t seem to have a way to apply a transformation during blitting and I don’t think it’s very efficient to be creating new surfaces on every frame update … more research required.
Started putting together the PlayerShip class and added basic movement and steering for the ship (currently Left, Right arrows and Up for the ships engines)
Refactored my TileSet class to make it a little more efficient and so that it fit in with the changed I had to make when I switched the code to use PyGame.Sprite based scene objects
Oh and pressing the ‘B’ key changes to a random background, just for testing
Apply friction/drag to the ship … yep I know there’s no drag in space but it makes the ship easier to control. Perhaps there will be a ‘Power Down’ later in the game to turn it off and make things a bit more tricky. I had some code in place to apply friction against the ships velocity but it’s not working they way I want.
Finish out the ships movement and start on the ships weapons, a simple single shot gun for the moment, more math , angles, vectors etc … yay
And the progress so far … Scotty has done sterling work and got the engines working!
Ok, you’ll have to imagine everything moving again … I don’t know how to make a GIF (or try the code )
Open Broadcaster is pretty cool and it turns out it was much easier to capture the video on Linux than the last time I did it on Windows.
Here’s a video of the ship movement and some of the space backgrounds I have. The ship still has no friction applied so it’s like trying to drive a shopping trolley with a broken wheel the only way to slowdown or stop is to turn the opposite way … although I guess that’s how spaceships without reverse thrusters would work.
Day 4 (Still behind schedule so day 5 will be this evening)
I really don’t like the PyGame documentation, ended up having to dig through the source code to find out that the ‘sprite.Group’ and family of classes don’t really do what I thought so I’ve had to re-think my scene management again (wondering if I should have stayed with my original ‘poor mans’ scene management)
Anyway, I did get some stuff done in between cursing the PyGame docs:
Added friction/drag to the player space ship movement. I know there’s no friction in space but the ship can get really out of control with out it (@Levitance I’ve included a toggle to turn friction on and off at the moment , it’s on by default but the ‘F’ key will toggle it. It’s still not working how I would like either but it will do for the moment)
Made a start on the player ship weapons. I have a rough idea in place and have implemented a simple single shot missile weapon just to see how to get it working with PyGames sprite and sprite groups
Clean up the player ship weapon code a little and add DoubleShot and RadialShot primary weapons
Start thinking about adding rocks to shoot at and collision detection
Think a little bit adding support for different scenes in the game. At the moment the game class just works with a single scene. I’d like to be able to create multiple scenes and have the game class run one depending on game state (e.g. Intro/Splash screen scene, game play or level scene, high score table scene etc …)
And the progress so far … FIRE!!! (those little green things)
Yep those photon missile thingies are pointing the wrong way … need to rotate them using the ships forward vector (or cheat and find round missiles )
Added basic single shot primary weapon. I think this will be the beginner weapon and will be improved by power ups (velocity, time to live and cool down times will be tweaked by collecting power ups)
Added a secondary weapon that fires multiple missiles in a circular pattern from the shop (I think this will be the first of a few different secondary weapons that can be picked up from power ups dropped by destroying asteroids)
A bit more code clean up, but there’s still lots of test code in there from trying different ideas.
Finnish the ‘DoubleShot’ weapon. Firing two missiles from the wings of the spaceship while it’s rotating is trickier than I thought.
Need to do more research … the game physics book might be out again
Get some sleep and come back to it tomorrow
There’s short demo video here. It demonstrates flying the ship with and without friction being applied and the two new weapons ‘SingleShot’ and ‘RadialShot’
There’s still a bug in the code to apply friction as the ship doesn’t come to a complete stop as it should.
Nothing to see here … just a lot of code feng shui today.
Refactored a bit of code
Abstracted the image cache (AssetCache base) because I will need a cache for audio files at some point
Did some re-working of the scene nodes and scene renedering code so I will be able to switch between different scenes depending on game state (E.g. Intro Scene, Level Scene etc…)
Think about getting rid of all those cheesy backgrounds. I’d like to make the window a bit bigger (or re-sizable) but scaling up background images causes performance issues (probably because I am blitting the entire background on each frame at the moment). Thinking about some sort of tile-able space background so the window is not restricted to size of the background image and I’d like it to scroll as the player ship moves … kind of like a parallax effect … just gotta find some free art.
Visually pretty much the same as yesterday … but I do have some fancy sprite bounding rectangles for when I get to writing and debugging collision detection.
Spent a bit of time today looking for royalty free graphics and reading the PyGame docs, but made a little bit of progress with the game.
Decided to get rid of the old backgrounds and went with a static background for the moment. I found some royalty free tile-able 1024x1024 space background so I am going to use those. That way I will be able to run the game at different resolutions by tiling the background.
Added animation support to my Sprite scene nodes so that I can have animated asteroids, explosions etc
Started work on the asteroid sprites and spawned a few for testing.
Turned off the FPS lock because I was getting lag (even though the game does nothing at the moment … not a good sign), it now runs at full speed but I need to do more research here. Locking at 100 FPS seem OK in the 1280x1040 window but at full screen it’s terrible.
Things to do next:
Finish the asteroid sprites and create an asteroid spawner (I’d like to have support for large, medium and small asteroids as when the large asteroids exploded I want them to break into smaller pieces)
Add sprites for a couple of different types of explosions.
Try to find some more graphics for the asteroids. I like the ones I have because they are animated in a way that makes them look 3D but they are too small and I only have them in one colour. I am not very good with graphics but might see if I can get away with tweaking them a little bit myself.
So here is how it stands now (haven’t done any work on collision detection yet)
If anyone knows where I can find some nice free graphics especially some animated asteroids please let me know (I might need to change the ship too, it’s from the art supplied with original Python course I took and I am not sure I can use it)
Look into using a joystick to control the game (and add WASD keys too)
Here’s a video of the current game play … just using the massive sprite bounding rectangles for collision detection at the moment … and I still can’t hit them
Not a lot of progress today. I am not happy with the hacked together physics I have been using for the movement of the various sprites in the game so spent most of my dev time reading 2D game physics and reworking my code. I really should know this basic math.
But I did manage to get the following done:
Added little helper factory classes for creating Asteroid and Explosion sprites to make the code a little cleaner.
Added a factory to create power ups when asteroids are destroyed (for test purposes there’s a power up spawned for each asteroid destroyed)
Looked into the availability of a small physics library for PyGame because my code sucks
I haven’t checked in any code today because it’s pretty broken
Things to do next:
Finish cleaning up the sprite movement code
Add code to have the asteroids collide and bound off each other
Add code to allow the player to collide with and collect power ups
Add code to handle when asteroids collide with the ship (need to think about how I want this to work, e.g does the ship get destroyed immediately, does it take damage based on the size of the asteroid, what happens if the ship has a shield etc)
Anyway here’s a short video of the power up testing
Oh, and there seems to be a problem with the first frame of one of the explosion animations I am using. There’s a strange square shaped alpha showing, if anyone knows how I can fix this I would really appreciate it.
Didn’t check in any code yesterday or post an update as the code was pretty broken while I did more refactoring.
Decided that using a 3rd party physics library would be overkill for such a small game so instead I refactored my sprite code and re-worked the small bit of 2D physics I need for the moment. I now have a set of base classes for the different sprites to handle movement by integrating forces and applying the resulting velocity to the sprite. The base class also handles simple frame animation so I don’t have to worry about that anymore. I still need to integrate drag into the velocity calculation but I am pretty happy that the code does what I need for now.
Fixed a graphical problem with one of the explosion sprite sheets I was using that was annoying me.
The asteroids and power ups now rotate … since I get that for free with my new KinematicSprite class (which I’ve just realized I’ve spelled wrong in the code)
Added a new ‘SceneText’ scene node so I can start adding some HUD elements (I’ve added an FPS counter to test it)
Since I’ve fixed my sprite movement (I think), I’ve gone back to having the game frame locked at approx. 60 FPS
I think there will be a bit of debugging required today … this is a really strange bug. I was just testing some new graphics for my games power ups and have managed to somehow link two completely separate scene objects together
I have no idea how the ships position is affecting the power up position.
Perhaps I can use this as an ‘interesting’ game mechanic … the elusive power up
the only way to slowdown or stop is to turn the opposite way … although I guess that’s how spaceships without reverse thrusters would work.
