February 2016 challenge: “The aftermath”

Gas and Grass - The Good, The Bad and The Ugly

Posted by wezu on 2016/03/07 12:38

Time to sum up. As always some parts went fine and some not so.

The Good

Driving. I'm happy with that. It's fun to drive the car, it's easy to strategy and almost impossible to flip. There are sounds that change in volume and pitch as you change speed, crash, break or just go over bumps. The car also looks ok.

Rocket. You might be wondering what I'm talking about - there are no rockets in the game. The rocket I have in mind is the main character - I named her Rocket, but don't ask me why. She looks cool with a US flag bandana and red boots modeled after the boots Jake the Dog stole... and then there's the 'get out of the car via the window onto the roof's animation. I'm quite proud of that one. Use pview (shipped with panda3d sdk) to view the model and animal.

Grass. If I made the grass from individual objects I'd need 10 of them for every 1x1m square - the map is about 0.5x0.5km so that would be more objects then any modern $500 GPU can render. Without going technical I'll just say instancing, ping-pong texture buffers and dirty tricks are used to render the grass fast, animate it, cut in real-time and show it on the radar. But there's still room for improvement.

The Bad

Gameplay. There's none. The mechanism is there, but there's no goal, no win condition, nothing. As a game it's a epic fail.

Postprocess. I have shaders to make soft shadows, lens flares, heat distortion, bloom/glare and depth of field included but not used.

Character control. It's just bad. I don't wanna talk about it, wasted a whole day on it.

The Ugly

  • Wheels spin when exiting the car
  • Fixed camera angle
  • Almost no decorations on the map
  • Basic lighting (1 point light )
  • No idle animation
  • Configuration via a txt file
  • Character control (bad AND ugly)

Add a comment

Retirement of Diomedes - RoD Speed Runs

Posted by tactii on 2016/03/07 02:04

Can you beat my time?

Add a comment

Laion - Finito!

Posted by circusblatta on 2016/03/06 23:48

After long time we eventually finished a game. The last two times we didn't even start to make it, other times the games didn't work properly or they had other problems; this time the game work, it will be not the perfect one but at least it works in the way we've thought it had to work. i am satisfied.

Add a comment

Beam - Beam: Done

Posted by Tee on 2016/03/06 22:52

Due to life, I was only able to start Friday night this Pyweek, so I went with something very simple. Beam is a one-button runner-type game where you have to avoid traps based on the aftermath of other escape attempts.

I went through three iterations of decreasing complexity to get to the game I submitted, so I started over almost from scratch twice. The first iteration was a puzzle game. I scrapped it because I felt was too difficult to generate levels in the time frame that I had. The second iteration was actually very much like the current one, except that you'd have more freedom.

It's a simple game and it should take only a few minutes to beat it, but I hope it's enjoyable.

As always, congratulations to all who have finished their games!

Add a comment

Detention: The Aftermath - Day 8 - The packaging

Posted by gummbum on 2016/03/06 22:02

I had a packaging problem with Zip. When I tested my download I observed that the unpacked intro music was hiccuping. I tested many things and could not resolve it. On a lark I tried tar.gz and the issue went away. Sorry to those who prefer zips.

DR0ID made a Windows exe. Kudos. I am amazed. Please note the exe does not include numpy (issues with py2exe and numpy, apparently), so if you play that one you will be missing out on some gradient font rendering eye-candy.

We fixed a number of bugs. Hopefully all the DNW are now resolved. Many thanks to those who pointed them out early.

Congrats to everyone who finished their project! Looking forward to playing the games.

Add a comment

Picking up the pieces - Game done, but unhappy with distribution

Posted by telecoda on 2016/03/06 21:23

I have completed the game and uploaded it, but there are a few areas I could be happier. OSX sound support on pygame ======================= Using pygame on OSX presented a few challenges. I struggled to get .mp3 or .ogg support working so had to resort to shipping large .WAV files instead. py2exe on windows ============== I used the pylygon library for polygon collision code, which itself is dependent on numpy. When trying to create an exe on windows numpy was failing. Personal tip for the future, don't leaving packaging until the end of the project. I had to setup a python/pygame installation on a windows box from scratch. These are not excuses, just poor planning on my part. I hope people ARE able to run the game from source on their chosen platform. I was hoping to make the running a seamless experience for everyone. Oh well, thats pyweek 21 done for me, time for a beer.

Add a comment

.... - We finished... something

Posted by AjaxVM on 2016/03/06 14:08

We didn't finish the game, or get anything insanely awesome in.
But we did get some custom music and custom graphics. We also used more than we made.
We have a custom level loader, and 1 real level - which sucks and was made for testing on day 2 or something.
You can play coop (select host/play singleplayer and have someone join your ip in join game - either local or port forward instructions are in the join game menu).
You can bounce on each other's heads, and the zombies are plants that just race you to the end of the level.

But we had fun doing it and learned a lot. Cheers guys - hope everyone else had as much fun!

Add a comment

Towards the Platforms - Conclusion

Posted by knowledge on 2016/03/06 10:29

I create a game for PyWeek!

It isn't very good but it's OK

What went well:

  • many things delayed for Sunday
  • really made a game (with ending)
  • made 7 levels (never made more for a game)
  • made credits for the first time
  • made main mechanics 1st day

What went bad:

  • couldn't program entire Monday and Saturday morning
  • after making mechanics, working very slow on the game
  • fixing bug 2 days and not realising that I could dirty-fix it
  • few hours spent on attempt to make font
  • library too unstable
  • no time for music nor sound effects nor background
  • made no diary entries until this one

Add a comment

Stable Orbit - Stable Orbit: It Works!

Posted by LeopardShark on 2016/03/06 10:08

The bits which are important to read are in bold. Please read those if you are playing Stable Orbit. Everything else you can read if you want. I've done a lot better this time than last. The game does not cause you physical pain to play! I actually find it quite enjoyable to play. Last time sound didn't make it but this time I had time to add some in which is quite good considering my experience level with sound: zero.

I had two bugs on the deadline, which I fixed today so I've uploaded two versions. The two bug fixes are the only difference between the two versions. The bugs in the first version are:

-Lesser bug: The "Simulation speed increased" and "Fast-forwarding time" messages were displayed 60 (2.4 seconds) frames too early due to a fix I did to make them slightly after the beginning. I increased this, exaggerating the negative effect until it was 50 frames (2 seconds) too early. I changed this to be 10 frames (0.4 seconds) after. This is merely aesthetic: it makes no changes to actual gameplay.

-Greater bug: If you exit the game with ESC you gained 1000 bonus score. Considering that any score greater than 3570 is impossible, this is quite major. It is a side effect of the 1000 point bonus you get for completing the game.

These are the only changes that were made to the game after the deadline.

What have I learned? Check that fixes work and allow more time for testing.

The entire code for the game is just 588 lines (with fixes). Since a Terraria-style block game (very underdeveloped, more a plaything than a game at the moment) I've made is only 635 lines for the actual game but its world generator is 1035 I don't think (hope) lines of code is too telling about how good a game is. Additionally, I have a pong clone, Bouncy, that is 1477 lines. I think that it is more true to say that code lines ∝ number of times CTRL-V is pressed than code lines ∝ game goodness.

I am very pleased with the overall game at the end. The code for getting the collision point between the two bodies is wonderful. Here it is in case anybody else wants to use it in their future projects: location = [(a.position[0] * b.size + b.position[0] * a.size) / (a.size + b.size), (a.position[1] * b.size + b.position[1] * a.size) / (a.size + b.size)] a and b are the two objects. The graphics of the game, while simple, I think look nice. My favourite part of the graphics is the procedural starry background. I had a Background.png but I ditched it because I wanted to make the background scrollable. If you're wondering what the game is doing while it's initially loading it is generating the background. I am also pleased with the scientific accuracy and mathmaticalness of the game. I wish that Phobos & Deimos were created at 150 times their real size. That is how big I had to make them in the game. The orbits are quite realistic and everything attracts everything as it should. The time speed of the game is 2.5 days per second at normal speed and 50 days per second at hyper-speed ("Simulation speed increased" or "Fast-forwarding time"). This means that each simulation lasts 600 days, or almost one year and 8 months. This means that the entire game is set over 16 years, 5 months and 4 days excluding thinking, planning and simulation time.

My primary worry is that Stable Orbit will be too hard. It's a hard game. That's intentional. However, as the developer you naturally become very good at the game. I can beat anyone you ask at Bouncy: my brain has subconsciously memorised the way the ball goes after every bounce. If you find it too hard, read the tips in the README. Another worry is that the scrolling text gets annoying. It does take quite a long time to pass. You can change the text's scrolling speed (in pixels per second) by adjusting the variable "TDFPS" in line 20 of main.py

The game is only 3.9 MiB, over 75% of which is the background music (It was about 100 MiB before I reduced the image size for the planets and moons). I had some problems with it on Windows. It wouldn't play the MP3 file and came up with a confusing message about C++. I had to convert it to an OGG in order for it to play.

What would I like to do next time? My own sound. FreeSound.org is great, as is Kevin MacLeod's incompetech.com, but when you use somebody else's sound/music I think it seems to make the game less your own. I guess I could have recorded myself saying 'tk' for the menu clicking sound but it wouldn't have sounded that good anyway.

If you look at the code, watch out! It is a mass of tangled logic with may redundant lines and no comments.

A note: Venus's gravity is slightly lower than Earth's. Mars's is much lower.

Add a comment

Adrift - Day 6-7

Posted by mit-mit on 2016/03/06 10:00

OK it's finally in. Wanted to write this right after submission, but needed some sleep. Day 6: Finalised the graphical integration of the main game. Bit of work on cut-scenes. Day 7: Finished cut-scenes and story/intro. Developed "tutorial" system built into the first level to guide the player on how to play. Developed most of the game's level/puzzle content. Generally speaking, I'm pretty happy with what we got out. As always, there were things that got planned that didn't make the cut: The biggest thing that happened this time was the length of the game/number of levels/quality of level design: it got left a bit too late in the development (last hours of day seven) and it just wasn't enough time to do it properly. It feels like this is always going to be a problem with such a short dev time: this is the major area for improvement for me next comp (I think I said that last comp as well :) ).

2 comments