I uploaded version 3 of Eclipsed, which you can download here. The only changes from the PyWeek version are:

1. graphical depth clipping bug fixed
2. final cutscene added
3. ability to set window resolution added to in-game options
4. for Linux users, a process for recording gameplay videos

If anyone who experienced the graphics bug during PyWeek tries it out, I would be very interested in a confirmation that it's actually fixed.

I did mention when I announced that my game has been uploaded that I wasn't as satisfied with this entry compared to my previous one, so I was pleasantly surprised by the majority of the feedback that I got. Firstly, I'm really glad that many of you found it enjoyable to play. That's probably the most important part of a game, in my opinion. :)

I was a bit disappointed to read that the game crashed for at least two people, but that's what happens when I implement most of the actual gameplay in the last two days of PyWeek. In particular, I didn't even get the shop done until about four hours before the coding deadline, and I just finished adding sounds about an hour before it, too. If it does crash for anyone in the future, feel free to post a traceback in the comments.

In the end, this PyWeek was even more fun and interesting than the last one, particularly since I felt that I learned even more from this one. I'll go over a bunch of thoughts and lessons that I have collected now that the judging period is over.

The parts that were never realized

I think the main reason that I was initially not as satisfied with the result was because there were so many things that I had to remove due to time constraints. Now that I look at how many .py files there are in the source code folder, I kinda surprised myself with how much I actually implemented during that week. Despite that, there are a lot of unimplemented things that could have made the game better.

The pacing of the game, which several of the comments alluded to, did suffer partially because of a “scripted” event that I did not have time to implement. It was going to occur on the third level, and it would have spawned a few enemies that you had to run away from after you got the coordinate data on that level. In retrospect, however, I should probably just cut that level out altogether since people probably understood the excavation mechanics after the second level, if not the first one. If I had done that, the player would have seen the enemies a bit sooner, which would help the game's pacing.

Related to that is that I was also going to put some story elements in the game. I was going to have log files (that were buried for some reason) that the player can read, an introductory wall of text when the game started for the first time, and an ending wall of text that explains just why that mysterious red crystal was so bad. This does sound ambitious, which was probably why it never made it into the game.

I was also going to make the first level be the tutorial, but I settled for writing a manual instead. I'm glad that the manual helped people understand the gameplay mechanics. A tutorial would still be ideal, though, since playing is more fun than reading instructions.

Many people also pointed out the lack of music, and that's one aspect of the game that I simply did not have time for, unfortunately. I agree that it would really help the game out a lot.

There were a lot of other things that I wanted to include, such as optional levels, but I can't have everything. Well...I can always work on this game more now that this PyWeek is essentially over, right? :)

The learning process

I implemented many new things for the first time during this project, and some of this stuff turned out to be tricky. I think I spent the first day or so just implementing a scrolling camera. Some stuff turned out to be much easier than I thought, however, especially save games. The pickle module pretty much did the work for me in that case, although I'm a bit aware of its drawbacks. For something like PyWeek, though, it's fine :p

Also, my collision detection code is awful and inefficient. Just take a look at this snippet of code from terrain.py:

  def process_bullets(self):
    for bullet in self.bullets:
      bullet.update()
      bullet_rect = bullet.get_pos_rect()
      player_hitbox = self.player_vehicle.get_hitbox()
      
      if not bullet.friendly and player_hitbox.colliderect(bullet_rect):
        self.player_vehicle.on_damage(bullet.damage)
        bullet.hit = True
      
      elif bullet.friendly:
        for enemy in self.enemies:
          enemy_hitbox = enemy.get_hitbox()
          if bullet.friendly and enemy_hitbox.colliderect(bullet_rect):
            enemy.on_damage(bullet.damage, self.player_vehicle)
            bullet.hit = True
            self.enemy_hit_sound_play = True
            break # Only one enemy should be hit per bullet
         
        if bullet.hit:    
          alert_rect = pygame.Rect(0, 0, 500, 500)
          alert_rect.center = bullet_rect.center
          
          for enemy in self.enemies:
            enemy_rect = enemy.get_pos_rect()
            
            if alert_rect.colliderect(enemy_rect):
              enemy.aware = True
              enemy.aware_timeout = 5 * FPS

This code was actually a bit problematic towards the end of the week. During the second-to-last day, I started creating the levels, and the level sizes were so big that stray bullets were inevitably everywhere, slowing the game down to as low as 40 FPS instead of the 60 that I was aiming for. As soon as I realized this, I got a bit discouraged. Reducing the level sizes did help to cloak this problem, and it also made it easier to populate the levels with enough enemies instead of having vast, empty spaces, but it was still annoying to deal with. If I ever make another game that depends heavily on collision detection, I will need to implement some more efficient techniques.

The menus were also painful to write, although remembering that functions can be assigned to variables really helped a lot. The shop system is just...bad. Please don't look at it :p

Finally, unlike the last entry, I wanted to have some graphics other than rectangles, and so working with those graphics was something that was new to me, too.

For next time...

I think I should probably try to have an idea that doesn't depend too much on level data, since I'm kinda tired of making one-off level formats. I did that during the last entry too, and it was annoying to have to write code to parse my hand-rolled level format and to make sure that the levels were actually how I intended them to be. In fact, during the hour or so I spent playtesting, I found a bug where one of the weapon blueprints didn't spawn because I typo'd the item id number.

Either that, or I should use formats that already exist. I saw that one entry used JSON(?) or something like that.

Also, as mentioned above, I definitely will have to research better methods of collision detection and practice implementing them. I can't be using the naive and inefficient method forever :p Quadtrees, anyone? (or anything else?)

And I should put some music in already...

In conclusion

This was a fun PyWeek, and I enjoyed creating something for it. I feel bad admitting that I only played roughly one-fourth of the other entries, but many of them were quite fantastic, and I still have no idea how some of you manage to make 3D-based games in a week!

Also, I might work more on this game and on my last entry as well, so I might announce updated versions (and hopefully Windows builds) later on. I can't promise anything though since I am a college student, after all :p

Finally, thanks goes to the PyWeek organizers and to everyone that played and gave feedback on my game. :)

Thanks everybody for playing, rating and commenting for my game. My game's ranking is low. But it is good thing. I've learned important lesson because of that: gameplay is the king.

During the development week I have spent most of the time drawing art. And somehow I can draw. I think it is the most beautiful thing I've ever done. But it does not matter. Because my game has almost no gameplay. Yes -- it has some interaction. But that is it. Because of bad priorities and because of fulltime job I had not enough time to do actual programming.

So. In this gamejam I've forgot the most important rule of game creation. Gameplay goes first. Gameplay is the king. Other stuff can help gameplay -- but they are not as important as gameplay itself.

Thanks Pyweek and all participants for teaching me this lesson.

P.S. For anyone who were confused with my game's strange endings and strange achievements. Both are random. You need to play it three times to get message explaining it:
https://bitbucket.org/petraszd/pyweek-17-shrooms/src/4912d32de97aa120daceb4ddc1c600ca028c93da/shrooms/cfg.py?at=default#cl-84

It was inside joke. Just for me. I thought it was funny. I still do and I do not care that actually it is not funny at all.

P.S.S Sorry for broken English.

Congratulations to the winners and to all who competed. I was blown away by the quality and diversity of the entries.

A big thanks to everyone for the feedback on my game. Everyone was very generous, particularly since it seemed that so many people had issues getting the game to work as intended. It looks like there were some significant physics issues.

I'm interested in hearing from anyone that had physics issues which platform they were on so I can look into it. I'm thinking it may be a framerate issue but it may also be platform related. I didn't see this kind of thing (Helium rocks getting stuck in other objects) at all on my Mac mini so I'd like to investigate further because I'd like to use pymunk in the future.

It is very kind of everyone who still rated the game high despite these issues really making it unplayable.

Some people mentioned the mouse scroll wheel not being a good control scheme - it was slow for some and for those on laptops it was unusable. Yes! I should have tested this better. I'm using a magic mouse which seems to be very unrepresentative in terms of how it generates scroll events. 

Music too large? Yep - I noticed this to my embarrassment when downloading other people's games! Mine was huge but it didn't need to be.

Gerty obscuring the action - aargh. Yes, I thought this too when I was playing through after the submission. This is one of those things where you have a design idea and find it hard to get away from it. I really wanted Gerty to be a big part of the game but I needed to find a better way for him to pop-up without being annoying or hiding the screen.

I'll do a bit more of a detailed post-mortem later but I just wanted to thank everyone again for the great comments. This really helps me a lot.

Paul

Well thanks to everyone who played my game 'moonlander' and gave useful feedback.  And congratulations to the winners.

Overall, I was pretty happy with how the game turned out.  In the ratings, I scored significantly higher for 'fun' than last time round, which was one of my aims, and a little bit higher overall.

The controls were maybe a bit sensitive, as some comments pointed out.  Also, I had hoped to implement a radar to show where the moon actually is, but time constraints got the better of me.  Again, adding extra things like moving asteroids etc. had to be shelved to ensure that I finished in time.  Finally, yes there is a 'bug' of sorts where one can reach the moon despite having crashed the rocket into a nearby asteroid!  This is because I used bitmasks for the collision, and the explosion images are a bit bigger than the rocket (oops).  I've now fixed this with a single line of code setting the self.mask attribute of the rocket sprite.

Next PyWeek I hope to
- Devote a bit more time to my game (like most people, I am sure)
- Go for something a little bit more ambitious in terms of gameplay (time permitting)
- Write more regular diary entries during the competition

See you all next time!

I uploaded a few pages from my notebook here, if you want to see what it's like.

Feeling

Unsurprisingly, with this game, the "feeling" came first and the gameplay followed. I started with a specific experience in my mind: the surface of a small world covered with activity, with machines bustling and whizzing about. I thought, "how can I make this experience happen?"

The most obvious example is the satellites. There's no benefit to the gameplay for the satellites to be visible. You can more easily keep track of how many you have by reading the HUD. During the game you pretty much ignore them. But it was important to show them, because it created the feeling I wanted to evoke. The idea of connections between structures also came about this way, because building a web encasing the surface helped achieve the feeling I wanted.

I got really lucky with one simple trick: the building animation. I originally had structures appear by growing up out of the surface and twisting, but so many of them are radially symmetric that the twisting didn't add anything and it didn't look as good as I'd hoped. Instead, they now appear piece by piece. This is achieved when I call glDrawArrays. When I pass the number of polys to draw, I simply multiply it by a number that increases from 0 to 1 during the first second. It wound up taking about two minutes to implement.

This feeling is close to an idea I had a couple of years ago. For a short time in 2011 I tried to learn Flash. I eventually decided to go with HTML5 instead, but the Flash game I started on was an RTS where you covered the surface of a small world. Basically the same feeling, just 2D and a bit more cartoonish. Here's a concept sketch, and apparently the early prototype I made is still online. If you play that for a minute you'll see a couple ideas that made it into this game.

I feel like I did a good job capturing the feeling I had in mind. The only minor things is I would have liked a couple more structures to have moving parts.

Gameplay

So that worked. What about the gameplay? Was it fun? Was the strategy interesting? Was the challenge level right? This is where feedback is going to be the most helpful. Let's see....

Short and not much of a challenge to finish

I wasn't really able to work out how to progress through the game

the ramp up in difficulty to the last level is a bit steep

The game is relatively easy to get into.

It's complex and hard to master

The levels introduce the concepts effectively

marred only by how confusing it can initially be to play

the first levels were not challenging because there was no threat

I couldn't really get very far

intuitive interface

I just couldn't quite get to it because it wasn't very clear what to do

Huh. That's.... inconsistent. Ha, just kidding, at first I didn't understand how there was such mixed feedback, but actually it makes sense in context. First, a lot of people who had trouble figuring things out were dealing with a pretty severe graphical glitch, which cyhawk brought to my attention and jerith provided a one-line fix for. I should be able to provide a fix version shortly, so these people can check it out if they want to. For others, I think I see what they're saying. The game probably is too challenging in some ways and not challenging enough in others.

I decided not to spend time on an interactive tutorial, instead just adding information to the Help menu. If I'd had more time, a tutorial would have addressed some of these concerns. Also I didn't decide on the number of levels until very late. I think 6-8 shorter levels would have been better than the 4 that are there. That would have allowed for a little more gradual difficulty curve, but of course would have required more playtesting.

Balancing

Going into the last day, I had most structures implemented but I didn't have level objectives or any balancing done. I had two problems. First, there were too many things to introduce to the player all at once. That's easily solved, I'll unlock new structures each level. I just need to choose the objectives so that they can be completed without some of the structures. Second, I worried that it would be boring if the first 5-10 minutes of every level were the same. This was solved by increasing the resource availability with each level, so that earlier structures became less important or obsolete.

Early on, I planned to use a balancing cheat that I learned from recent resource-gathering games like Candy Box, A Dark Room, and Cookie Clicker. This is to make the amount of resources increase exponentially as you progress through the game. I call this a cheat because it masks mistakes in balancing. If your resources increase linearly and you accidentally double the price of an item, you double how long it takes to achieve it. If your resources increase exponentially, however, you only add a constant amount of time that's relatively small. This works best if you have several resource types; you can trade many of one resource for a few of another, keeping numbers from growing astronomically.

Anyway, I wound up not using this cheat, at least not to the extent that I planned. The fact that I had so many resources probably did hide some mistakes, though. I didn't see anyone complain that the game dragged on or got monotonous, so while I definitely could have spent more time testing strategies, I think this was good enough for PyWeek.

Other stuff

For this game, the music, sound, and story were "other stuff".

I usually use Kevin MacLeod for music. I still highly recommend him, but his music has appeared in so many PyWeek games I was hoping for something new. I happened across a website by some German musicians this time and their music fit my needs really well. They seem really prolific, so I hope to use their stuff in the future. The only things are, I think their early stuff is not as good of quality as their recent stuff, and they don't have downloads available so I had to rip the oggs from their YouTube videos.

I like writing engaging stories for games, but it didn't happen this time. The story was more or less thrown together during the last day. My original idea was activating ancient alien artifacts, but that's the same story as my last PyWeek entry so I wanted something different. The story I used was fine, but I didn't really have a chance to edit it or tie it into the gameplay. Like I never renamed "artifact" to something more appropriate. At least I got a game title with a double meaning out of it: the game was nameless until about an hour before the deadline.

The Future

I'll probably upload a version with the graphical bug fixed, and I may try to make a Windows port. I think the game has potential for further development, but I'm not going to work on it right now. I'm in the middle of learning webGL so there's a possibility of a JavaScript port in the future. If anyone else wants to take a crack at it, go ahead. :)


Thanks richard for another great PyWeek, and congratulations to everyone who submitted a game. See you next time!

I didn't do too well this time round, but I totally deserved my score and the feedback was actually quite positive.

The game was definitely lacking a sense of achievement and this has made me appreciate traditional adventure/point and click games a lot more. I think there were a few elements of the game that really didn't work -

• All the areas are the same and available from the beginning
• Few items to collect
• Can't see or interact with items you have
• With only one way to interact with things, it's easy to accomplish things by accident

I didn't really appreciate this at the start but all these things contribute to a feeling that you are not really progressing in the game and lack of control. The nonsensical story could have been developed more as well, if I had more time.

I was quite shocked at how awful my code got in so short a time. but thankfully it mostly worked for everyone who rated it (I didn't realise mp3s were a problem in pygame, I'll stick to ogg next time).

Despite the final result, it was fun making it and hopefully I've learned a little from my mistakes. Thanks for playing and see you next pyweek!

Thanks for the feedback, everyone.

It seems that most people had trouble with the controls. I apologize for that. I completely forgot to fix them as I was rushing to put the (small amount of) gameplay in. I've just spent now a few minutes fixing the controls and adding a restart button (I wish I had done that before) and I've uploaded a new version. If anyone who had issues with controls wants to try it again, feel free to play it.

And, yes, I think this is one of my shortest Pyweek games, if not the shortest one. As always, the only reason I didn't expand on it was time. But I think this idea could be quite interesting if expanded on.

Congratulations to the winners! See you all next Pyweek!

I got to the point where I had a game concept and it looked achievable. That in itself was pretty awesome. But, I was still putting my full-time job ahead of this game, and unfortunately the job spiked a bit near the end of the week. So, I ended up with a render engine and that's about it. I bet there is a better way to do what I ended up doing using an existing framework, so I will have to do some more research on that before the next time. 

Also, I might consider taking some time off.

Thanks for all the pleasant comments. I'm glad my effort could bring a little joy to you. Sorry to all those who didn't find it fun. I guess you can't please everyone, even with a cheeseball gun and a lassoo!

I wasn't going for an intense, or even particularly challenging experience with this. It was just a endless pointy-clicky, harvesting the moons to some relaxing tunes.

I played this just beyond 10K cheeseballs. I agree with the person who found it addictive, though I would call it "mildly" addictive. This was important to me, that I could pick it up to scratch the itch to play without it being an armchair gripper that consumes every ounce of brainpower.

I also agree with the others who said it needed more, and the awards are lackluster. Alas, having started less than 48 hours before closing time I had no time to polish the game or even find sounds to fit the mood.

To the lone soul who called it a lassoo: you win! =) Incidentally, this was the only way to win. You are a head above your peers. You all didn't know this was a puzzle game in disguise. ;)

The music was a windfall. I web searched and it fell right out into my game. What a great find. If you lasted long enough to hear all the really cool music once I am pleased. There are many, many more great compositions at http://incompetech.com of a quality suitable for plain old listening. I am not affiliated with the author, the site, etc.

If you took the time to view the credits I am especially pleased. May the good Lord bless and keep you.