September 2013 challenge: “Moon”
Moon of Blood and Steel - Working through the details
Posted by Caligari on 2013/09/03 15:43
I feel like we almost have all the bits in the design, but there are niggling details that people keep pointing out, and of course balancing a design is a different beast from creating it.
A soul-less chunk of today was breaking down the ui and trying to detail each screen. Luckily there's not a huge number (of interesting ones - I haven't done most of the dull parts completely), as it was tough going.
I also spent some time messing with the basic mechanic, thanks to some graphing from a team-member. It was good to do some coding again after all of the writing.
I'm going to have to start adding actual data to the game pretty soon, as that is going to be a long process, I fear.
But others are implementing things and the game is more and more real as we go.
Will we have something playable this week? Will I even finish the design this week? No idea! But I'm proud of what we're working on, and at the moment I reckon I'll want to getting working after the week is over. For me, that is "mission accomplished"! :)
A soul-less chunk of today was breaking down the ui and trying to detail each screen. Luckily there's not a huge number (of interesting ones - I haven't done most of the dull parts completely), as it was tough going.
I also spent some time messing with the basic mechanic, thanks to some graphing from a team-member. It was good to do some coding again after all of the writing.
I'm going to have to start adding actual data to the game pretty soon, as that is going to be a long process, I fear.
But others are implementing things and the game is more and more real as we go.
Will we have something playable this week? Will I even finish the design this week? No idea! But I'm proud of what we're working on, and at the moment I reckon I'll want to getting working after the week is over. For me, that is "mission accomplished"! :)
Wezu - The Good, The Bad and The LetsStartAgain
Posted by wezu on 2013/09/03 15:14
Got a prototype working and some assets done. Bad news is that the game seems lame. No fun at all. A day and a half down the drain, back to the drawing board. At least the assets can be reused. Got some nice asteroids with LODs, a lander, a space-box (like a sky-box, but in space) and some sounds.
The new idea is to make in 3d, with the lander driven by simplified Newton physics, or a Chi-Ting version of it. I don't think I'm going to make the landing part, just navigating via a asteroid field (there's no asteroid field near the Moon? so what? there could be...)
Should post some fancy screenshots but I'll do it tomorrow. Really. Trust me.
The new idea is to make in 3d, with the lander driven by simplified Newton physics, or a Chi-Ting version of it. I don't think I'm going to make the landing part, just navigating via a asteroid field (there's no asteroid field near the Moon? so what? there could be...)
Should post some fancy screenshots but I'll do it tomorrow. Really. Trust me.
Moon Protection - pyweek17 - diary entry - day 2, 3
Posted by 5hassay on 2013/09/03 14:51
day 2
welp, well we're starting to get into the issue of code elegance vs just getting stuff done, as we are doing as much as we can from scratch. Of course, with elegance we can increase productivity. Then again, we can't be putting so much of our time into essentially making libraries.
basic menus and buttons are implemented that work well enough. We're getting to the point of integrating the moon orbit simulation into a game screen. On that note, the simulation of a moon's orbit around a planet is looking great--thanks multi-var calc! hue.
day 3
still some issues of code elegance vs getting stuff done. A good amount of reformatting with how menus, screens, buttons, text work, et cetera. Looking pretty good atm, considering how basic it is. Day 4 should see some integration of the game simulations and menus.
some conflicts between coding styles among team members, lol. My idea of "necessary" in the context of "commenting when necessary" seems to be much more "casual" than my teammate's. Something like that was bound to happen without agreeing beforehand on a style standard! (Of course we both follow PEP, but there can still be differences.)
welp, well we're starting to get into the issue of code elegance vs just getting stuff done, as we are doing as much as we can from scratch. Of course, with elegance we can increase productivity. Then again, we can't be putting so much of our time into essentially making libraries.
basic menus and buttons are implemented that work well enough. We're getting to the point of integrating the moon orbit simulation into a game screen. On that note, the simulation of a moon's orbit around a planet is looking great--thanks multi-var calc! hue.
day 3
still some issues of code elegance vs getting stuff done. A good amount of reformatting with how menus, screens, buttons, text work, et cetera. Looking pretty good atm, considering how basic it is. Day 4 should see some integration of the game simulations and menus.
some conflicts between coding styles among team members, lol. My idea of "necessary" in the context of "commenting when necessary" seems to be much more "casual" than my teammate's. Something like that was bound to happen without agreeing beforehand on a style standard! (Of course we both follow PEP, but there can still be differences.)
Steel Moon - Starting Out
Posted by TheMrFarquad on 2013/09/03 14:41
Ok, so I just found out about this today so I'm a little late to the game.
I've already got a plan but depending on time I may have to cut bits, I'm working all this week.
So here's the basic idea: The Earth is under attack from aliens who've decided to try to bombard it with asteroids. In response scientists have shrunk the Earth and fitted it with rockets and coated the Moon in a layer of steel. The object of the game will be to maneuver the Earth in such a way as to affect the gravitational pull of the Moon. By swinging the Moon you'll be able to deflect the asteroids back at the aliens.
At this moment I can't decide whether this should continue forever and be score based or if it should be wave based. I'm thinking the former just due to time constraints though.
I've already got a plan but depending on time I may have to cut bits, I'm working all this week.
So here's the basic idea: The Earth is under attack from aliens who've decided to try to bombard it with asteroids. In response scientists have shrunk the Earth and fitted it with rockets and coated the Moon in a layer of steel. The object of the game will be to maneuver the Earth in such a way as to affect the gravitational pull of the Moon. By swinging the Moon you'll be able to deflect the asteroids back at the aliens.
At this moment I can't decide whether this should continue forever and be score based or if it should be wave based. I'm thinking the former just due to time constraints though.
Moon of Blood and Steel - Day 3: making great progress!
Posted by richard on 2013/09/03 12:18
Caligari has been beavering away adding more and more to the spec document for this game - a ridiculous number of pages have been written, but they now include actual user interface specs. All we have to do is implement them all :) korg has been helping out with the spec work - even producing graphs analysing the model behind the game!
I've started putting Caligari's UI ideas into code, including the overview screen which has this ("placeholder" in his view, hah!) art. It represents one of the "zones" in the game. No more will be said for now about that :)

Moon of Blood and Steel - Technical Specifications gone wild
Posted by bobsmith on 2013/09/03 11:37
I would just like the world to know that Caligari did not mention that the design document has ballooned out to 37 pages -- it has also spawned offspring/variation/alternate versions (which have been told firmly that they're not going to get any love until next week).
There is so much detail and opportunity! This game is definitely bigger than the week but hopefully at least a simplified version will get out!
Don't let him tell you his graphics aren't amazing. I wonder if dispensation can't be sought to add a sampling as a screenshot? Amazing I tell you :)
In other news we think we may have picked a name. Maybe. Watch this space.
There is so much detail and opportunity! This game is definitely bigger than the week but hopefully at least a simplified version will get out!
Don't let him tell you his graphics aren't amazing. I wonder if dispensation can't be sought to add a sampling as a screenshot? Amazing I tell you :)
In other news we think we may have picked a name. Maybe. Watch this space.
Moon Expedition With A Lunar Rover - Game development diary: Day 2
Posted by Master47 on 2013/09/03 10:49
Day 2
On day 2, I managed to finish creating the control panel in Inkscape. There will still some fields for text missing. As soon as that was complete, I began working on the class for "Sample". In a level, samples from the moon have to be collected.
I then started working on the class "Level", through which a map, that is saved as a text-file, can be loaded. Through this map, I can now design some levels with obstacles, samples and scenery.
I made a simple "Sample" image in Inkscape to test a level. Worked. I added a collision helper function that tracks collisions between the lunar rover and all the objects of a level.
If the lunar rover now went over a sample, the sample would disappear.
Afterwards, I began working on the class "Text", with which I can display text on the window and change it throughout the game.
I first implemented the class "Text" in "Lunar_Rover_Health", that shows the health of the lunar rover.
I implemented the same class in a new class "Lunar_Rover_Sample_Meter". This class is used for tracking the samples that have to be collected in a level and have been collected.
As soon as all samples in a level are collected, the level ends. Since there is only 1 level now, the game ends.
And that was it for the 2nd day of the challenge :).
On day 2, I managed to finish creating the control panel in Inkscape. There will still some fields for text missing. As soon as that was complete, I began working on the class for "Sample". In a level, samples from the moon have to be collected.
I then started working on the class "Level", through which a map, that is saved as a text-file, can be loaded. Through this map, I can now design some levels with obstacles, samples and scenery.
I made a simple "Sample" image in Inkscape to test a level. Worked. I added a collision helper function that tracks collisions between the lunar rover and all the objects of a level.
If the lunar rover now went over a sample, the sample would disappear.
Afterwards, I began working on the class "Text", with which I can display text on the window and change it throughout the game.
I first implemented the class "Text" in "Lunar_Rover_Health", that shows the health of the lunar rover.
I implemented the same class in a new class "Lunar_Rover_Sample_Meter". This class is used for tracking the samples that have to be collected in a level and have been collected.
As soon as all samples in a level are collected, the level ends. Since there is only 1 level now, the game ends.
And that was it for the 2nd day of the challenge :).
Moon of Blood and Steel - Bad UI sketches and biting the bullet
Posted by Caligari on 2013/09/03 01:58
I didn't manage to get back into the game as I wanted yesterday, perhaps the initial enthusiasm ran its course and exhaustion set it, or perhaps I knew I was wrangling with important and hard decisions about the task resolution mechanics which will underpin the gameplay and was trying to avoid them.
I spent lots of time kicking mechanics back and forth during the day, but wasn't willing to commit anything to the design document. By the end of the day the rest of the team needed something tangible from me, so I turned to some ui sketches.
Boy am I not an artist. I can visualize things, but I'm pretty much unable to reflect those images on paper. I tried using some iPad drawing software, but I think you probably have to be me in order to make real sense of it all. :)
Having broken my reticence to add to the design by putting in the ui sketches and describing them, I was able to turn my attention to the task resolution mechanics and put down a starting point. As we don't have much time, I think we'll have to end up staying with these unless they really don't work (which I'm fairly certain isn't the case).
Working through the mechanics further broke up the logjam in my mind and I found a definite in-game condition we will need for the the 'endgame'; I've been trusting that I can find these triggers as we need them, but getting this one in place really helps to understand what the player is going to be doing throughout the game (what the end goal is, specifically, and why).
So, today I want to test the task resolution mechanics, clearly define the needed ui screens for the whole game, and resolve some of the final parts of the mechanics (really just reflections of the game state).
I spent lots of time kicking mechanics back and forth during the day, but wasn't willing to commit anything to the design document. By the end of the day the rest of the team needed something tangible from me, so I turned to some ui sketches.
Boy am I not an artist. I can visualize things, but I'm pretty much unable to reflect those images on paper. I tried using some iPad drawing software, but I think you probably have to be me in order to make real sense of it all. :)
Having broken my reticence to add to the design by putting in the ui sketches and describing them, I was able to turn my attention to the task resolution mechanics and put down a starting point. As we don't have much time, I think we'll have to end up staying with these unless they really don't work (which I'm fairly certain isn't the case).
Working through the mechanics further broke up the logjam in my mind and I found a definite in-game condition we will need for the the 'endgame'; I've been trusting that I can find these triggers as we need them, but getting this one in place really helps to understand what the player is going to be doing throughout the game (what the end goal is, specifically, and why).
So, today I want to test the task resolution mechanics, clearly define the needed ui screens for the whole game, and resolve some of the final parts of the mechanics (really just reflections of the game state).
Loon - Made a start
Posted by gcewing on 2013/09/03 00:45
I've decided on a concept. It will be a peaceful RTS-style game based around building a lunar colony.
Resources: water, silica, metal ore, sunlight (for solar power)
Fixed units: habitat, smelter (turns ore into metal and silica into glass), factory, farm, solar panel, hydrolysis plant (to produce oxygen from water), transport tube
Mobile units: worker, rover
I started on the coding last night, and I made a bit of artwork today:

A loon (any resemblance to a Kerbal is entirely coincidental).
Resources: water, silica, metal ore, sunlight (for solar power)
Fixed units: habitat, smelter (turns ore into metal and silica into glass), factory, farm, solar panel, hydrolysis plant (to produce oxygen from water), transport tube
Mobile units: worker, rover
I started on the coding last night, and I made a bit of artwork today:

A loon (any resemblance to a Kerbal is entirely coincidental).
Werewolf Sonata - Werewolf with opposable thumbs
Posted by jerith on 2013/09/02 23:34
Today was a work day, which meant much reduced pyweek productivity. Hodgestar spent the day sick in bed, so we're all hoping he recovers swiftly and gets back to game writing soon.

Despite this, we've made some solid progress:

Despite this, we've made some solid progress:
- Prettier pictures. The protagonist's werewolf form shown in the screenshot above is actually older than the human form from yesterday. The tiled floor has been excised from the exterior of the level as well.
- More things to do. There are pressure switches (which existed in a very primitive form yesterday), indicator lights, a bunch of behind-the-scenes plumbing to hook them up and crates to push around the place. These are some of the building blocks we'll be using later to make the game interesting.
- Our level serialisation format changed and tumbleweed wrote a kind-of-YAML parser for it. (This is the kind of crazy thing one does during pyweek. He looked happy, so I didn't want to stop him. The results are good, though.)
- The level editor does more stuff and is easier to use. drnlm is our resident toolsmith and has built this kind of thing for most of our games, so he knows what he's doing here.
We're not quite as far along as I'd hoped we'd be, but we already have a thing we can play around with and try out various ideas. Having that kind of rapid feedback really helps maintain momentum and enthusiasm.
I think we'll focus on tools and puzzle components a little more tomorrow before we start on level design and all that stuff. But right now I need to catch up on my sleep.
I think we'll focus on tools and puzzle components a little more tomorrow before we start on level design and all that stuff. But right now I need to catch up on my sleep.