September 2013 challenge: “Moon”
Gumm's Harvest Moon - Gumm's Harvest Moon - fixed memory leak
Posted by gummbum on 2013/09/15 23:51
Note: For judging please use the final uploaded to pyweek.org.
The zip at the following location contains a bug fix for a memory leak that begins to affect performance after many achievements. The leak results in accumulation of multiple achievement sprites in the same slot, eventually overwhelming the game loop. The bug should not be a problem for normal judging experience. But if you wish to play a marathon session, then get this fix...
Version 1.1
Cheers.
The zip at the following location contains a bug fix for a memory leak that begins to affect performance after many achievements. The leak results in accumulation of multiple achievement sprites in the same slot, eventually overwhelming the game loop. The bug should not be a problem for normal judging experience. But if you wish to play a marathon session, then get this fix...
Version 1.1
Cheers.
Eclipsed - Eclipsed - gameplay footage
Posted by Cosmologicon on 2013/09/13 22:10
I managed to make a gameplay video by modifying an old script of mine. Check it out on YouTube, if you want to see what the game looks like:
http://www.youtube.com/watch?v=TLvELC7wXGo
http://www.youtube.com/watch?v=TLvELC7wXGo
Loon - Bug fix for Loon
Posted by gcewing on 2013/09/13 21:46
To prevent occasional crash when a resource finishes getting mined, apply this change to Game/Code/missions.py:
--- missions.py.orig 2013-09-07 17:51:27.000000000 +1200
+++ missions.py 2013-09-14 09:41:07.000000000 +1200
@@ -45,7 +45,7 @@
return target.resources
def units_removed(self, unit, units):
- if self.target in units:
+ if self.get_target_unit() in units:
self.target = None
if self.next_mission:
self.next_mission.units_removed(unit, units)
--- missions.py.orig 2013-09-07 17:51:27.000000000 +1200
+++ missions.py 2013-09-14 09:41:07.000000000 +1200
@@ -45,7 +45,7 @@
return target.resources
def units_removed(self, unit, units):
- if self.target in units:
+ if self.get_target_unit() in units:
self.target = None
if self.next_mission:
self.next_mission.units_removed(unit, units)
Moonbase Apollo - Lepton on Linux
Posted by arnav on 2013/09/13 10:58
If you are facing problems trying to install Lepton on Linux, try installing these dependencies first (from Lepton README):
- python-dev (if not already present)
- xorg-dev
- libg11-mesa-dev
- libglu-mesa-dev
- libxext-dev
Lunar - Lunar: Post-mortem
Posted by reidrac on 2013/09/12 07:31
Not a "strict" plan
This time I didn't have a complete game idea but some notes in a piece of paper. I don't know if that's the reason why this PyWeek has been less stressful than the previous one, but in "For Science!" I had a clear roadmap from the beginning and in "Lunar" I had more or less a story I wanted to tell and basically I had to implement things to make it happen. It may sound like it is the same but it is not, "Lunar" approach is more flexible.
I wanted to make something in 3D and I wanted the story to be a central part of the game. I played a lot of point-and-click adventure games back in my day, and I tried to make one myself when I was 14 (gwbasic, CGA 4 colors and the confidence of a teenager) but I'm not an artist and the visual part of the adventures is quite important.
Also I read recently the SCUMM diary, so I thought that may be using 3D graphics (I've been practising with Wings3D; still a lot of things to learn, my texturing abilities are almost zero!) and using tiled I could implement a simple adventure... in a week.
The truth is that this kind of game is not a very good idea for PyWeek because you have to work double: make the game engine and then... make the game!
This time I didn't have a complete game idea but some notes in a piece of paper. I don't know if that's the reason why this PyWeek has been less stressful than the previous one, but in "For Science!" I had a clear roadmap from the beginning and in "Lunar" I had more or less a story I wanted to tell and basically I had to implement things to make it happen. It may sound like it is the same but it is not, "Lunar" approach is more flexible.
I wanted to make something in 3D and I wanted the story to be a central part of the game. I played a lot of point-and-click adventure games back in my day, and I tried to make one myself when I was 14 (gwbasic, CGA 4 colors and the confidence of a teenager) but I'm not an artist and the visual part of the adventures is quite important.
Also I read recently the SCUMM diary, so I thought that may be using 3D graphics (I've been practising with Wings3D; still a lot of things to learn, my texturing abilities are almost zero!) and using tiled I could implement a simple adventure... in a week.
The truth is that this kind of game is not a very good idea for PyWeek because you have to work double: make the game engine and then... make the game!
That's the main reason why the game is not too long. I had time to put some background to have a backing story, but then there was time only for a couple of puzzles really :(
Development
This time I went for just pyglet, and I think that was a good idea. I used a couple of things I have never used before, but pyglet docs are great and the source code is clear and neat so that was OK.
More or less the same with OpenGL. I had to implement a couple of things I didn't know how to do but reading the docs and with some luck I finally managed to get most things done. The only part I'm not entirely happy with is the positioning of the "attention" icon: I couldn't get the 3D to 2D projection of the character right and that's why the final result looks a little bit "wrong" depending on the perspective.
I had a couple of "crisis" though. As I didn't have a strict plan, I had just a vague idea of how to implement some things.
First big problem was when I was going to animate the doors and I realized my rendering engine was wrong and it didn't support animations... so I had to rewrite a big part of it. I was using ONE OpenGL list to render the scene, and I had to split the layers in different lists because redrawing the whole scene in each animation frame was killing the frame rate (more about performance later).
I didn't have time to investigate VBOs (or pyglet's batches, it's the same thing) and the code I had to load and render Wavefront objects was using lists (an example contributed by Richard to pyglet). I was already writing my own code to read tiled JSON files, so I had to workaround the issue having a different list per layer and re-compiling the foreground layer (the one with the doors).
That was difficult to fix, but I think I got it right at the end.
The second problem was that I misunderstood how tiled manages tile layers and I was setting properties in the tileset without noticing that it meant, for example, that all the doors had the same properties. So when a door was opening and its "z" coordinate changed, all the doors moved at the same time!
I fixed this in a "simple" way but I had more or less the same issue with other parts so I ended having an extra JSON file per map to add actions (doors), info points, and define the map exists. Also tiled only supports text properties and I wanted objects, so having the external file was easier to manage.
The approach to draw the scenes is a little bit too simple and that did hurt the performance. It works like a regular 2D tile engine, but my tiles were 3D objects and that's it. This approach has its limitations, but the worst part of it was just to split the "quarters" scene in two because there were too many things to draw. I tried the game in a 5 years old netbook and it did perform perfect, so it wasn't that bad.
I was willing to try a shader to have some shadows in the scenes, but I didn't have the time. I think it was for the best because using simple OpenGL stuff means the game will be more portable.
Finally I left the sound for the last moment and I was a little bit too tired. The end result is OK, but man... I had to repeat the door opening/closing sound effect a dozen times!
Another thing different this PyWeek was testing. At some point the engine was powerful enough to implement the story, but then there was a lot to test... and it was really tedious. At this point my wife helped me beta testing the game (when there was a game, last day by lunch!), and she found several bugs. So if you plan to make a game like this, add testing to your list of things to do!
Conclusions
As I already said, this PyWeek was less stressing. I spent 20% of the time modelling 3D objects, 20% tackling tiled and writing the story in JSON files, and just a 60% writing code. I think in previous PyWeeks I spent way too much time just programming... so I think shifting part of the work to high level tools (although loading tiled JSON files wasn't too easy) was a good idea.
I'm happy with the result, even if the game is a little bit too short because of the limited time for just one person to do everything. But well... that's PyWeek, isn't it? I'm happy I finally made my first adventure!
The approach to draw the scenes is a little bit too simple and that did hurt the performance. It works like a regular 2D tile engine, but my tiles were 3D objects and that's it. This approach has its limitations, but the worst part of it was just to split the "quarters" scene in two because there were too many things to draw. I tried the game in a 5 years old netbook and it did perform perfect, so it wasn't that bad.
I was willing to try a shader to have some shadows in the scenes, but I didn't have the time. I think it was for the best because using simple OpenGL stuff means the game will be more portable.
Finally I left the sound for the last moment and I was a little bit too tired. The end result is OK, but man... I had to repeat the door opening/closing sound effect a dozen times!
Another thing different this PyWeek was testing. At some point the engine was powerful enough to implement the story, but then there was a lot to test... and it was really tedious. At this point my wife helped me beta testing the game (when there was a game, last day by lunch!), and she found several bugs. So if you plan to make a game like this, add testing to your list of things to do!
Conclusions
As I already said, this PyWeek was less stressing. I spent 20% of the time modelling 3D objects, 20% tackling tiled and writing the story in JSON files, and just a 60% writing code. I think in previous PyWeeks I spent way too much time just programming... so I think shifting part of the work to high level tools (although loading tiled JSON files wasn't too easy) was a good idea.
I'm happy with the result, even if the game is a little bit too short because of the limited time for just one person to do everything. But well... that's PyWeek, isn't it? I'm happy I finally made my first adventure!
to-get-lucky - Post Pyweek Alpha: Tetris Tower Defense!
Posted by bitcraft on 2013/09/10 05:09
So, it turns out I really liked the game I created and felt bad that I was unable to really make it into something. I've made more changes and decided to release an "alpha" version of the game that is more in line with my initial vision for the game.
*** Please rate the pyweek version of the game before playing the alpha! ***
In fairness, please rate the pyweek "final" version before playing the new version. It really is quite different.
Thanks and have fun! I'm open to critique on the new alpha.
https://github.com/bitcraft/pyweek17
*** Please rate the pyweek version of the game before playing the alpha! ***
In fairness, please rate the pyweek "final" version before playing the new version. It really is quite different.
Thanks and have fun! I'm open to critique on the new alpha.
https://github.com/bitcraft/pyweek17
Spacen - spacen - Post-Mortem Diary
Posted by otus on 2013/09/09 13:32
First of all, PyWeek was fun and I hope to do it again sometime. Although I was
a bit exhausted on Sunday, I already feel like coding again.
On to the actual game. I'm quite happy with how well it turned up, considering
On to the actual game. I'm quite happy with how well it turned up, considering
it is the first game I actually "finished", ever. I did have to cut some planned
powerups (flamethrower, jet pack, armor) and enemy types (flamethrower, semi-
invisible), though, which makes it somewhat less interesting than I planned.
Deciding to do it alone meant I could jump to Audacity or GIMP when coding
became boring. However, it did mean I have little original artwork: almost
everything is adapted from OpenGameArt.
I think the weakest part, especially comparing to what other games I've already
I think the weakest part, especially comparing to what other games I've already
tried, are the controls. It seems quite weird that your only contribution to
moving are the jumps. May also lead to frustration if there was nothing you
could have done better in a certain situation.
In the end that was a design choice I made because giving the player free
In the end that was a design choice I made because giving the player free
control would have required actual enemy AI – now they simply move about semi-
randomly, raining down bombs if you get too close.
At first I also thought I'd need to come up with a win condition, but in
At first I also thought I'd need to come up with a win condition, but in
retrospect the game doesn't seem to be worse for having none.
--
--
Ps. Based on my diaries and git log, I spent about 35 hours of time in front of
the computer on this.
Space Squirrel - Space Squirrel: A Public Service Announcement
Posted by blakeohare on 2013/09/09 00:29
After you turn gravity on, running and jumping allows you to jump a height of 4 tiles, but you need to be running for at least 1 / 3 of a second. Otherwise you will only jump a height of 3 tiles.
If a jump truly seems impossible, you must do more terraforming in a different section first.
This seems to be a common point of confusion from early feedback.
If a jump truly seems impossible, you must do more terraforming in a different section first.
This seems to be a common point of confusion from early feedback.
Moonrays - A few notes on Moonrays
Posted by Tee on 2013/09/08 23:41
You know that I didn't have much time to work on the game when its title is completely generic. :)
This time early in the week I thought of an interesting idea that I wanted to try out. By now you may be tired of me saying that I had little time to work on my Pyweek game, but I do wish I had more time to expand on it. The result was a very short game very focused on what I wanted to try, with no other features. So in a sense, my game was made to prototype this specific idea. A tiny part of the game is to figure out what to do, which I think is fairly straightforward, but if you want to avoid the spoiler of knowing what you have to do you should play the game before reading this.
Here's a description of the idea and the game. The context was originally meant to be a horror game, though I didn't do much in that respect due to time. There's a creature hunting you who's invisible to your eyes (actually, in this prototype it is not fully invisible because I thought it would make it too hard to run away from it). However, a beam of moonlight doesn't pass through the creature. So the goal of the game is to use mirrors to create moonlight beams in order to track down its position. Once you've guessed a position, you can try shooting at it (shooting is limited).
I think I like the result. The beams turned out to be an interesting tool for a "being hunted" type of game: if you have some notion of where the creature is, a good beam construction creates safety. The prototype as it is is a bit shallow and short, but I can imagine that one could expand this idea to something more interesting.
As always, any feedback is appreciated. Congratulations to everyone who finished this Pyweek!
This time early in the week I thought of an interesting idea that I wanted to try out. By now you may be tired of me saying that I had little time to work on my Pyweek game, but I do wish I had more time to expand on it. The result was a very short game very focused on what I wanted to try, with no other features. So in a sense, my game was made to prototype this specific idea. A tiny part of the game is to figure out what to do, which I think is fairly straightforward, but if you want to avoid the spoiler of knowing what you have to do you should play the game before reading this.
Here's a description of the idea and the game. The context was originally meant to be a horror game, though I didn't do much in that respect due to time. There's a creature hunting you who's invisible to your eyes (actually, in this prototype it is not fully invisible because I thought it would make it too hard to run away from it). However, a beam of moonlight doesn't pass through the creature. So the goal of the game is to use mirrors to create moonlight beams in order to track down its position. Once you've guessed a position, you can try shooting at it (shooting is limited).
I think I like the result. The beams turned out to be an interesting tool for a "being hunted" type of game: if you have some notion of where the creature is, a good beam construction creates safety. The prototype as it is is a bit shallow and short, but I can imagine that one could expand this idea to something more interesting.
As always, any feedback is appreciated. Congratulations to everyone who finished this Pyweek!
Satellite Taxi - Satellite Taxi: Holiday Project
Posted by cyhawk on 2013/09/08 21:53
I thought I wouldn't be able to participate this time, because I am on vacation and have spent last week hanging out with family and swimming in Lake Balaton. I did end up taking a laptop, so I put together something simple in a few evenings.
It was nice working on such a relaxed project. But I missed my tools. No drawing tablet, no Internet (for the most part), no microphone, no instruments. I did make some original music anyway, but I apologize for it :).
It was nice working on such a relaxed project. But I missed my tools. No drawing tablet, no Internet (for the most part), no microphone, no instruments. I did make some original music anyway, but I apologize for it :).