After getting nothing done on day 1, and deciding to abandon my original idea and start again this morning, I've spent the evening learning OpenGL for doing 2D stuff, and have to say, it's pretty damn sweet. Hit a few brick walls along the way, and it's taken me a while to get my head around the way the API works, but I've now managed to write (completely from scratch) a set of 2D routines to handle fonts, scrolling backgrounds, sprites (with rotation, scaling, alpha blending, automatic movement and inertia) plus a handful of bits and pieces which will be generally useful for games. I'll probably get around to optimising it all tomorrow, but for an evening's worth of work it's actually looking pretty tidy. I'm probably not actually going to need a lot of the stuff I'm coding for this game, but I really want to make sure I understood all the important stuff now, rather than it causing me problems when the time starts to run out. And anyway, it may be useful for adding eye-candy if I have any time left towards the end of the week. I'd like to add a basic particle system, a simple animation system and some intelligent path following for the sprites before I call it a day, but I'm just reaching that point where tiredness is starting to make it all somewhat less fun, so I may leave it until tomorrow. Aside from a font which I'll probably keep, and a bunch of abstract test bitmaps, I've not really gotten around to doing any artwork, so once I have today's libraries tested and optimised, and I've worked out how to use py2exe (how hard can it be?!?), I'm going to sit down and draw a few odds and ends so I can post up at least some screenshots of version 0.1 before the end of tomorrow. That's the idea anyway.

With some hints from Phil, I've implemented better player movement controls. They're much smoother and less flakey.

I've also tweaked the visuals a bit, changing the background brickwork to look a bit more like brick, and darkening it a little. The two vertical girders are there to stop the player, and will most likely be replaced.

I've added a download for my progress so far if people are curious.

Next up, the first part of the actual gameplay: destroying the boilers! Mwahahahahaha!

I was planning on making this project all by myself, but now it looks like I have some helping hands now after showing the so-called game to a few friends. JDruid made me an awesome song to use with the game, and Hectigo tweaked some of the code and graphics so the game is looking better than ever! Hectigo was interested in redoing some of the graphics too, so hopefully the game will look awesome when it's done.
The next things I'll probably be adding are scoring and naval mines. Probably some more enemies. Also, I'll probably start making some audio samples and adding them into the game as well as the music.

i don't have much time to write too much (maybe we'll have friday-saturday to write the code) so here is the idea for our game (email format, read from the end, up):

--------------------

hi

after talking to you today, i came around with the following (surprisingly it matched your questions):

1) tough question, but i thought about it a little:
for every 'pixel' in the target picture, compare it to the color that is there. while painting, the steam will move it's 'centor of mass' to the center automatically.
yes, it will be a complicated algorithm (the whole thing) and that's why it would be fun to do it.

2) i had in mind two gameplay modes. in the first, the mouse will smear the particles (like kai power goo) or something similar. in the other, the mouse will change its direction (like worms 3d. remember?) and will shoot out air (or steam) from its end (with a miniature gun barrel).
i guess the second one might be easier to implement.

also, i want the whole game + interface will be completely without text. the rules should be self-understandable.

i have a little design in my head of how the code should be separated into several different parts, but that is not important at the moment.

anyway, good night and send me more questions about important details that are not thought-through (: like how the particle simulation will be. and the shape comparison. and stuff.

nir

--- Cobra wrote:

> Great idea!
>
> but I have a few questions:
>
> Do you know how to compare shapes?
> How will the user move the steam around - will mouse
> gestures 'push' the steam?
>
> ~Cobra
>
> On 3/26/06, Nir Hershko
> wrote:
> > here's my idea:
> > along 100 meters, the camera goes up, following a
> > metal pipe. after about a second, it ends end
> steam is
> > released from it. then you have X seconds to move
> the
> > steam around (while it goes up) with the mouse and
> > make a pre-determined shape (say, giraffe) out of
> it.
> > the score is gives according to how close the
> shape of
> > the steam to the original shape.
> > at the end the steam is crashed into a ceiling or
> > sumtin'
> > RFC?
> >
> > nir
> >
> > --- richard@pyweek.org wrote:
> >
> > > From richard@pyweek.org Sat Mar 25 16:22:12 2006
> > > Date: Sun, 26 Mar 2006 11:22:12 +1100
> > > From: richard@pyweek.org
> > > To: Squirtler_2001@yahoo.com
> > > Subject: PyWeek #2 has started!
> > >
> > >
> > > THE CHALLENGE HAS STARTED! W00T!
> > >
> > >
> > > The theme is "It runs on steam!"
> > >
> > >
> >


---------------------------

sorry for the unclearness of the text..

We started yesterday with a meeting over Team-Speak. I had an idea in my head, that I had written down on our wiki, which we decided to go for. The design changed quite a bit during the discussion though, which is cool. :)

The concept is, and I quote: "The concept in Steam Empire is to build a network of railroads between industries in order to make a lot of money."

In other words, Railroad Tycoon Light. :)

We started coding yesterday. Decided to use PGU because it had a hex rendering engine, which is just awesome for games like our game. Although I was afraid we would have to use something else last night, cause I couldn't get it working properly. I solved that this morning though, so now (we just managed to add GUI widgets too) there should be no more technical problems left, I hope.

Today I've mainly been working on the rendering of the railroad tracks. I had to draw hex tiles for a lot of different situations (where a rail comes from the top left and goes to the bottom, for example). I finally got it working a couple of hours ago, and you can see the screenshot in our entry home. It's pretty cool, clicking out rails and watching them connect automatically. :)

Now comes the tricky part I guess (even though it hasn't been all easy getting here): implementing the game logic.

Day 2 is over, and we've got a working prototype. It allows you to play until the end.

Day 2 Result

Post your highscores here!

I finally managed to get started on my entry. Work has progress pretty well in the four and a half hours I've managed to put in today.

So far you can pick up and drop pieces on to the game board. You can also start the boiler and increase the pressure of the steam. The steam flows through the pipes based on the pressure in each pipe. When the steam reaches the green box it is counted in a simple scoring system.

The graphs on each of the pipes indicates the current pressure in that pipe. Ideally I'll replace the graphs with actual blobs of steam, but I'm not sure if I'll have the time for that.

Balancing the physics of the flow of the steam could prove tricky. While I'm at work tomorrow I need to think about whether this really is the best way to simulate the flow of steam, and to think about the additional elements that I want, beyond pipes.

Overall, not a bad start.

I decided not to go 3D this time, to see exactly how hard/easy it is to create a game using *just* what PyGame itself provides (i.e. no PyOpenGL, no 3rd party graphics engines or GUI libraries, etc), coupled of course with the features of Python's standard libraries. I also decided upon an isometric game.

However, I've never done any "pixel art" before; subsequently, I have spent far, far too long trying to draw a little train facing in eight different directions - not to mention wasting most of the first day struggling to come up with an idea. I'm also beginning to realise that I'll need either a more complex system for calculating offsets of mobile objects, or yet more drawings (fortunately just shifted versions of the existing viewing angles; I'll probably opt for the brute force option). Suffice to say the game won't be particularly heavy on eyecandy.

I'm also realising that isometric graphics engines aren't as simple as I first thought. Creating the landscape tiles wasn't a problem; nor was the algorithm for rendering the ground itself. It also took much longer to draw the train tracks than it did to get them depth-sorted and overlaid on the ground. However, getting the train properly depth-sorted, not to mention actually following the track, is proving challenging.

Currently, the train makes it to the third bend (with various popping artifacts as assorted track pieces are incorrectly drawn over the top of it) before disappearing into oblivion, a result of failing to find the next link in the track; this is the result of drastically underestimating the requirements of a robust track-following algorithm. Rethink in progress.

In all, I probably should have stuck with OpenGL, as used in my entry for the first challenge; I suck at 3D modelling, but overall it probably would have been far less time-consuming - and much more fun - modelling & rendering a 3D steam engine than drawing eight separate sprites by hand with more to come.

I'm not going to tell you what gameplay will be like, but it won't involve actually driving trains - neither directly nor through signals, anyway. :)

Today I started coding the rules of the game, so no screenshot today also.

What I'm doing is making sure that the rules are followed by the "engine" before working on the graphic interface. I'm doing it by following the test driven development:

In each module I have a class that is a test case for unit testing. When the module is run instead of imported, the test case is executed and lets me see if the rules are followed or not.

When all the rules have been implemented I will start with the graphics (and making screenshots, I hope). If nothing goes wrong I will start it on Wednesday.

I only hope I didn't make a wrong decision on taking this path, up until now it seems that I made so very little progress. I hope that seeing screenshots I will feel progressing faster :-)

We got off to a bit of a late start, but the basic design for our entry is now pretty clear. It will be a dexterity game of navigating an obstacle course with a steam powered ship. The steam power isn't just a visual effect though, it will cause several quirks on how you have to control the ship.