Well, it's that time again!

The month-long road to the compo, which will be traveled by way of four practice games.

The first of these will be a brawler made without a theme.

I'll give more details when I have something working. :-)

(As an aside, I'm curious about whether I could host my practice games on this site so that I have somewhere to share my work with the community)

So, practice run number zero begins.

Start Time: July 31, 9:00 AM Eastern US Time
End Time: August 7, 9:00 AM Eastern US Time

I've decided to make a platforming shoot-em-up.

I don't have a story yet, but I do have some ideas.

The player will be able to choose between a handful of characters. (At least two)
Each character will have different weapons. A couple of normal weapons, a sidearm, and possibly a heavy weapon.

I'm trying for a nice, fast pace and plenty of action.

I'm going to be implementing both (basic) pathfinding and hitscan weapons.

The hitscan weapons will be a good thing for me, I think. With them, I don't have to have loads of bullets flying through the air, slowing everything down.

The pathfinding will be tricky, but it will hopefully work well enough to provide a sense of the enemies being vaguely intelligent.

----

The real test for me, I think, will be whether I can stay interested in the project after the week is over.

In fact, I'm confident that I can get at least the code and sprites in place inside of a week, and probably a level editor and some levels.

The real test for me is the long term. I'd like to not have a repeat of the last Pyggy, where I got really excited, but then lazed out and got bored with my game.

Hopefully, I'll be able to stay interested in the game for at least a month.

----

In the end, I'm hoping for a game that will be presentable as a high-quality piece of software.

Or, I suppose, at least something I will work on for more than a week. ^o^

I set out to have a demo by today, but alas, I've fallen behind.

Still, I'm near one. I have all the sprites I need for now, and I've almost gotten entities working.

I'm kind of disappointed, though. I was hoping to have something today.

Oh well. I guess I'll need to work harder tomorrow. :-)

I probably should have focused more on getting the demo running than fooling with data loaders and factories!

Still, I've got some foundations for what I need. I also have up to Friday morning to get it done, too!

---Akake

It doesn't look good for my first practice game. I... spent two days player Custom Robo.

Ah well, live and learn, am I right.

I'm debating about whether I want to continue with this run. It looks like I may have something of a demo, but it's not likely. If I do, it'll just be a little car driving around on the screen. Not very fun. :-P

----

I've learned something about myself, though.

I learned that my forte isn't crazy ideas, but solid code and reasonably well-polished gameplay.

That said, I also learned that I want to give genres other than side-scrollers a chance.

I think my next game will be a shoot-em-up. I like top-down shmups, and I think that's fertile ground for me. :-)

My thought is to challenge myself to develop something ambitious in a week.

I have a concept for my game, but I'll reveal it when I've got it fully articulated.

---Akake

I've decided to call the first run done. It's not going anywhere fast. :-/

I've decided that, on my next run, I'll take two weeks and try to make something nice and polished.

I'm thinking of making a fighting game.

I dunno. I'll share more when I've figured things out.

---Akake

Edit: Updated because I came to a terrible realization about what I'd gotten myself into

I have run into a roadblock with my third practice game.

For the record, my second was an eight-hour Robotron 2084 clone that can be found here.

My third practice game was going to be a fighting game, but the sprite count is starting to reveal what the time frame and overall size of the game would be.

Instead, it will be an experimental game, but I have not yet worked out what exactly it will be.

It's been a learning experience for me. X-D

---Akake

Some Thoughts on Minimalism
-OR-
Why I Believe Less is More

I've had some time to think this over, and I think I have some good ideas here.

I'm currently making a game in a minimalist style. It began simply with me making my first set of pixel sprites for it, then finding that I liked them better solid black than colored in.

Then I started thinking: Most of the games that I love are simple ones.

I love Bejeweled, I love Tetris, I love Super Mario, heck, I love Pong!

Then I thought about the games that really disappointed me.

Command and Conquer, Oblivion, Half-Life 2, Metroid Prime.
I've played Second Life. I, like many people, quickly ran out of things to do.

This is interesting to me, because we often think that more features, more content, more open-ended gameplay make a game better.

I propose that this is not always the case.
Certainly, these are games that benefit from complexity. RPGs need to be complex, otherwise it deteriorates into "Press A until you win".

That said, even puzzle games can benefit from simple mechanics.

Complexity naturally arises from simply system. Chaos theory has shown this.

So perhaps we need to put... Less in our games.

Leave out all that is unneeded. Keep everything that is necessary, and discard everything else.

This is expressed in most engineering communities, the UNIX and hacker subcultures, and even as a principle of lifestyle by some religions.

Certainly Pong would have been worse off if it had all of the rules of ping-pong (Outs, Faults, etc.), Tetris would never have become a classic if it had items, and Super Mario Bros. would have seemed stupid if it had a shop between levels.

This is a philosophy I have been happy to see come forth from Pyweek. I've found that the best titles are often the ones that include the least.

In fact, it seems to spring naturally from having only a week to develop an entire game.

This makes me happy. It has given me a way to make fun games over a timeframe that I can work in.

I guess... It's something to think about. What we need to ask when designing... No, when making a decision is "What can we eliminate? What do I not need?"

---Akake

I've been working on another practice game. This one's going fairly well, too. :-)

The game is titled "Rabbit Hunt".

In it, you play as a fox who must catch rabbits and avoid dogs. (Hence the title of the post)

There will also be bushes that you can hide in so that neither can see you.

I have currently gotten the fox working, and I'm working on the terrain.

The game uses separating axis collision detection, provided by retrogamelib's geometry module. While I'm not using anything else from it, I have found the geometry module to be a joy to use.

After I've gotten the terrain going, I'll put in the rabbits, dogs, and bushes.

Finally, I plan to use a random world generator. This will be the most challenging part of the game to code, I think, but should not be too much trouble.
I haven't decided on an algorithm for it, but I'll probably use a fairly stupid one. :-P

That said, I'm happy with how this is progressing, and admit that whether I make my deadline or not, I'll probably take some time after that to polish it up a bit.

If anyone would like to check it out, I'd recommend checking out a copy of the source at:
https://henrys-compo-practice.googlecode.com/svn/trunk/pyweek-practice/pw-9-practice/rabbit-hunt

You can also pick up my first demo release here, but there have been major improvements since I released it, so I highly recommend the SVN snapshot if you are reading this before I've uploaded version 0.1.

I'll upload version 0.1 once my terrain system works, and I'll post a comment here when I do. :-)

I'm happy with how this is progressing. I think I've finally gotten into my groove.

---Akake

Quick Edit: Changed title to something more clever :-)

Today will be a day of intense work. It'll be rough, but I hope it'll pay off.

I will definitely be making factory methods for building terrain objects such as slopes, beveled boxes, and hills.

Rabbits will also be implemented, and they will be used to fully test my spatial hash.

Bushes will then be added, as will amendments to the rabbits' behavior to make them not react to the player when they are hiding in a bush.

Dogs will be the final probable addition for the day.

The AI for both dogs and rabbits will be fairly simple.

Both types of animals, not having spotted a predator or prey, will simply wander around back and forth, turning around when their height (Y coordinate) falls to or past ten below their initial height since the last time they lost their alerted status, or if they have not been alerted before, their height the first time they hit the ground. This keeps them from simply wandering off of a ledge unless they are chasing or being chased.

Rabbits will run away when they spot the player, and will jump when they are below the player by about five pixels or more. They jump at that point because all of the terrain pieces will have some amount of beveling, so it can make rabbits at least try to jump gaps. Or, at least, look like that's what they're trying to do ;-)

Rabbits will occasionally sit and graze for up to three seconds, where they will neither move nor turn.

Dogs will run after the player when they spot them. If the player is above them by at least ten pixels, they will plan to jump. They will record where the player was horizontally when they went upward, and when they are within 5 pixels of that spot, they will jump.

Dogs that have not spotted the player will randomly fall asleep for five to fifteen seconds.

Also, dogs will run away if they player pounces on them while still undetected. (IE: The dog is looking the other way, or is asleep)
When a dog is scared like this, it will run in the same direction, jumping when its downward velocity increases and it is still on the ground, so it will appear to try to jump gaps. If it reaches the edge of the world while still frightened, it will disappear.

If the player leaves an animal's field of view for about two seconds, and the animal isn't going to jump, they calm down, and "Think they lost him".

Animals will not reach that status in the air, however, for the purposes of the AI system, which, as noted earlier, records their elevation at the time they calm down.

Dogs will treat rabbits like they treat the player, but will prefer chasing the player. Rabbits will treat dogs the way they treat the player, without exception. This creates a certain amount of interaction between creatures.

The animals' fields of view will be represented by a pair of polygons that extend in either direction from the animal. The front polygon (Whichever points in the direction that the animal is facing) will always be checked.
The exception is sleeping dogs. When a dog is asleep, it does not check either of those polygons.
The other polygon will only be checked when the animal is still in "I'm being chased" mode.
This makes it possible to sneak up behind an animal, to pounce on it.

--

As for tomorrow...

Tomorrow will be a day of polishing dog and rabbit behavior and physics (Things like jump height, running speed, etc.)

I will also use tomorrow to start work on the scoring system, which will be very simple, as well as lives.

I'll be making numerals and an icon for the lives.

Over the course of the back end of tomorrow and the time I have left tomorrow I will make a title screen, and if I have time, possibly demo screens.

And then... I can hope for...

BLUE SKY :-D

Moments ago, I tested Rabbit Hunt with a bunch of testing entities.

The frame rate tanked, falling from 30 to around 5 with just five entities on-screen. :-(

It seems that separating axis collisions are much, much more intensive than rect ones. I knew that, but I underestimated just how much more time it takes.

I can't really salvage this one. There isn't really anything I can trim off of it to make it go faster. It's a shame, because I had high expectations for it.

On the bright side, my spatial hash worked beautifully, and with minimal bug-fixing. :-)
The performance clearly varied depending on how many entities were on the screen, running fine with none, and deteriorating as the number grew.

I've learned a few things from the experience, as well.

I've learned to not underestimate the cost of techniques that I haven't used before, and also that I enjoy making minimalist pixel sprites.

I came into this knowing that failure was possible, and it seems to be that it occurred.

----

Rabbit Hunt -- Post-Mortem

Rabbit Hunt began with minimal progress, but quickly grew into a functional platformer.

I made terrain sprites, but they looked really awful, so I eventually scrapped them.

I only wound up with the sprites for the player and a ! icon that mobs would have displayed when they detected something interesting.

The collision detection was fairly easy to work with, but proved to be too much for the game to easily handle.

I initially wanted entities to check for collisions a few times every frame to keep the speed up while minimizing the amount of that bouncing that separating axis seems to cause when collisions effect velocity, and the tendency to fall through things that entities seem to have when non-tile systems are used.

This created staggering performance hits with only the player entity, so I moved on, changed it to one collision check per frame, and put in a load of test entities.

After hitting my world cells with a hammer a bit, they worked beautifully. The only problem was that the performance hit from having more than one collision check per frame reared its ugly head again.

This did not prove to be fixable, and seems to be a characteristic of separating axis when used with highly sub-divided terrain.

Attempts to group terrain into larger chunks would likely only mitigate the problem somewhat, and would not have helped significantly with a full environment, where there would have been numerous entitities, and complex terrain that could not be reliably sub-divided.

Ultimately, I've learned that if I'm dealing with numerous entities, I should use rect-based collisions, because they are simpler and much, much faster.

Separating axis was a joy to work with, though. I will certainly use it in future projects.

Projects with fewer entities. :-P

Lessons Learned:

* Complex collision systems take lots of processor time in Python
* World hashes greatly improve performance, and are fairly easy to implement
* Minimalist pixel art lends a game a graceful look that even an art-impaired programmer like me can create
* New techniques should be tested for performance impact before a project is fully underway, to determine whether something simpler would be a better option.
* SVN is a very handy way to back up code, as I discovered a few times during development

Overall, the experience was a good one. It was the first project I've had in a while that I could detach myself from healthily that was more than just a super-simplistic shmup.

It was fun, and I'm satisfied, even though I ultimately failed.

---Akake

As the title (And my previous posts) suggests, I've decided to take my final practice run in a somewhat different direction than I had previously taken.

I have decided to deviate from Python and Pygame, and, for the first time, develop in C++ using plain SDL.

I've never written a full application in C++, and in fact have only written small terminal programs for an introductory class on the subject.

So far, I have a blank window, and a bunch of background code. I still have yet to get the window to display anything, but I'm working on that currently.

My theme, given to me by the same friend who gives me all of my practice themes (She enjoys seeing what I come up with), is Console-Style.

I've decided to take "Console" as meaning a command console, such as DOS or a *NIX terminal. From this, I get to the VGA shareware of the early 90's. (Such classics as Jill of the Jungle and Commander Keen)

My game is entitled "Bazooka". In it, you use a bazooka to blow things up.

It is a turn-based, tile-based sidescroller.

Each turn consists of each character, both the player and the baddies, either moving or firing.

Each character has a given amount of speed, which represents the distance they can move in a turn.

Otherwise, a character can fire their weapon. Weapons being fired travel as the characters do, and a character gets hit if they are not at least half of a tile away when the projectile reaches them.

This should (I think) give the game a bit of tactics, which is something else I've not done before.

I have a good bit of the content planned out, as well.

The game will depend on SDL, SDL_image, and SDL_mixer.

To play it, you need to have the development files for those libraries, as well as either make or some other method for compiling and linking a C++ program.

That said, I will likely produce a Linux binary, because it is convenient for me to do so, but unless someone wants to provide me with one, there probably won't be a Windows binary.

The source doesn't depend on anything OS-specific, though.

And if anyone's interested, I would be more than happy to put up my Code::Blocks project files for download.

I have a good feeling about this one. I think this will be the one. :-)

---Akake

I've made some definite decisions about Bazooka, and I'd like to share them.

First, I'm going to store levels as images, much like Pymike did for his PyWeek 7 entry.

Default screen dimensions will be defined at compile time (As constants which can be supplied to make), but will (hopefully) have entries in the configuration screen.

On the art side, I've been inspired by this thread, and will be using the old EGA white/black/aqua/magenta color palette.

Also, I will be drawing my sprites in a super-deformed style(IE:Chibi). This includes characters, items, and even projectiles.

Between the player characters, Ricky will look like a soldier, and Suzy will look like a commando.

Ricky will wear a uniform, sans helmet. Suzy will wear a jacket and baggy pants, and she will have pigtails.

The baddies will look like generic enemy-type people.
Larry will have a pot on his head, and no shoes. (He looks dumb)
Marry will wear a jumpsuit and have a bob. (She looks like a mechanic)
Barry will wear no shirt and will have a beard. (He looks tough)
Garry will wear body armor and have a mullet. (He looks crazy)

The terrain will have a slight sci-fi look, as that is fairly easy to produce. Each tile will have four variations, including the entrance and exit.

I have decided on the characteristics of each character, as well.

Each character will be able to move, fire, jump, climb ladders, climb ledges, and push boxes.
In addition, the player will be able to pick up items, exit the level (By reaching the exit), and also has limited ammunition.

When a character tries to move off of a ledge, they do so with the intent to either jump or drop down. The player is given this choice while deciding their move.

The two player characters will have the following attributes:
Maximum Health: 20 for Ricky, 10 for Suzy
Maximum Rockets: 20 for Ricky, 10 for Suzy
Spaces Moved per Turn: 3 for Ricky, 6 for Suzy
Spaces Covered in a Jump: 1 for Ricky, 2 for Suzy

The controls are as follows: (Items following a slash are controls in the menu, and the third entry for escape is for the main menu)
Arrow Keys: Plan out Movement (Consumes the entire turn) / Select Menu Item
Space: Fire Rocket (Consumes the entire turn)
Tab: Switches between normal rockets and super rockets (Done at any time)
Enter/Return: Confirm plan for turn (Ends turn) / Confirm Menu Choice
Escape: Exit Level (Brings up dialogue frame) / Previous Menu / Quit Game

The enemies will build on these base characteristics:
Hits to Kill: 1 (Barry: 2)
Spaces Moved per Turn: 2 (Marry: 4)
Spaces Covered in a Jump: 1 (None Improve)
Damage per Shot: 1 (Garry: 2)can either do so with the intent to jump, or
Respawns After: 25 Turns (Larry: 10)

As a note, there are two types of enemy spawner: Those that allow their enemies to respawn, and those that do not. Which is which is decided in the level editor.

Items will come in three flavors:
Med Kits, and Rockets, and Special Items

Med Kits and Rocket Pickups each come in three sizes: Small (Restores 1), Medium (Restores 5), and Full (Restores All)

Small items respawn 5 turns after they are taken, medium items after 10 turns, and full items after 25 turns.

The special items are as follows:
Stim Pack: Doubles move and jump range for 5 turns, and respawns after 15 turns
Super Rockets: Gives 5 rockets that do double damage, and damage anything within 1 square of where they hit, and respawns after 30 turns
Supply Kit: Restores full health and rockets, and respawns after 50 turns

The terrain will include the following:
Empty Space
Solid Ground (Cannot be destroyed or moved)
Cracked Ground (Destroyed when shot)
Slightly Cracked Ground (Becomes cracked when shot, or destroyed if 2 damage is done to it)
Ladder (Can be climbed)
Box (Can be pushed)
Teleporters (Linked in pairs, up to four pairs in each level)
Entrance (Where the player begins)
Exit (Reach this to beat the level)
Enemy/Item Spawners (Invisible, displayed as background)

I know it's a bit much to plan this out now, but I want to get this all down, because I'm slowly but surely approaching the point where I'll have entities on-screen.

Here's hoping that's the case :-)

---Akake

I've decided to make some amendments to my design. This is mostly refinement, and little of it is adding or removing.

First, I'm taking some liberties with the 2-bit color palette I'd decided on.

Because of my... Sub-par spriting skills, I need to use a different palette for the terrain to get contrast.

That said, I've decided to use a dimmed Aqua/Magenta/White/Black palette for the terrain.

This means a roughly Teal/Violet/Gray/Black palette.

It's technically one of the IBM/PC 2-bit palettes, but a second one. But hey, it's not running on an 8-bit chip, and certainly not in 2-bit mode!

Also, I've decided that the characters will have different sprites for when they are facing right or left.

This is so that characters' weapons are always on the same side of their bodies (IE: Suzy's bazooka is always in her left hand, etc.)

This does double the size of my character sprite sheet, but I would probably have held sprites for left-facing characters in memory separately anyway.

Character sprites are 20 pixels wide and 25 pixels high. I decided this how I usually do: Make the first one, round the size off to a multiple of 5, and it's there.

Board tiles will be 30 pixels square. This is to give a good ratio to the character sprites, and give spaces a spatially balanced feel. (IE: Tiles are evenly sized, and don't give the odd feel that oddly dimensioned tiles do)

I haven't yet decided on the dimensions of the item sprites, but I'm thinking something like 20 pixels square.

On the gameplay side of things, I've also made some decisions.

The player can carry half as many super rockets as normal ones.
Normal rockets move twice as fast as super rockets.

That's all I've got to add right now, but you can expect more as the day goes on. :-)

Oh, and before I forget, once I've got a demo going, I'll be making a GoogleCode project page for this game, and will be making additions every now and then. (For example, extra levels, possibly with extra mechanics)

But that's for another day. Today, I just want to get some spriting done, and maybe get something on my screen. :-)

---Akake

I've decided that I need to do something off-the-clock. I'm going to eliminate my self-imposed (Well, friend-imposed, self-enforced) deadline on Bazooka, and try to develop some ideas alongside of it.

I'm still going to be developing Bazooka, but I want to do something alongside it.

I need a break from it for the time being.

It's kind of embarassing, really. I didn't work on it very much at all.

It'll be released when it's released. I need to allow myself the freedom to make games at a more mellow pace.

I need to relax, especially with school (And the compo!) coming up.

Here's hoping I can de-stress a bit.

---Akake

I... I don't know quite why I'm writing this, because it's not really technical, or even remotely related to the compo, but here goes...

I've hit a creative roadblock.

There's a feeling that I want to express in a game. It's been eating me from the inside out.

It's hard to explain. The longer I go without expressing it, the more it bothers me.

The problem is that I haven't yet been able to get it out effectively. I had a bit of progress with Rose, but I'm still more or less at a loss.

I can't seem to create the assets I need, both graphical and sound-wise.

I can get the code to do mostly what I want, but the assets elude me.

It's very frustrating. I need to express this feeling, but I can't do it any way but to show it. Nothing else captures it.

I know this must be coming across kind of whiny, but it's really eating at me.

Where can I go to learn to make better assets?

What can I do to get less frustrated with things?

How can I become more patient with ideas?

I... I know this is kind of a weird thing to post here, but I really need help, and I don't have anywhere else to go.

Any feedback is appreciated.

I've decided against making another game before the compo.

Instead, I'm going to relax for the next few days, think about the themes, and practice with Pygame's OpenGL bindings.

I'm going to be working with OGRE3D in C++ after the compo is over, but not until then.

I'm thinking of going the perilous route of the 3D game this time around. It's kinda risky, but I think I can make it work.

I'm prolly going to use Blender3d and an OBJ WaveFront parser, alongside Pygame/OpenGL.

This will be fun. It'll be my first 3D game. :-)

Yatta!

---Akake

I've thought about this alot over the course of today.

I may or may not decide to use OpenGL. It depends on which theme is chosen, and where I choose to take it.

I realized not but a few hours ago that I'd probably spend most of the week dickering with OpenGL, and have next to nothing by week's end. Better off leaving it for another day.

I want to focus on interpreting the theme in a different way. I can't promise unique-ness, as there are lots of folks who will be doing the same thing, but I'll try something different.

I will try to keep to my strengths. I will try my hardest to make an action game, an arcade game if possible.

That said, I'll actually be keeping tabs on the difficulty of my game this time around. There will also be more of a strategic and/or explorative aspect to it, provided I can fit it into the game's concept.

I'm not sure about the genre. I like platformers, but I also like the idea of a first-person arcade game. Then there's the thought of a fighting game. Or... Maybe a shmup...

I don't have any solid ideas yet, but they'll come, I'm sure.

That said, I'm happy to be taking a break.

I have an idea that was mostly brought to mind by recently deciding to get back into playing Nexuiz.

Well, and RB[0] bringing it up.

I may (As the title of the entry suggests) make a shooter of some sort.

I'm definitely thinking of using PYGGEL, because it was designed for this sort of thing.

Besides that, it depends on the theme.

Well, that and what others are doing. Wouldn't want to make a duplicate game, now would I?

----

That said, I have some concepts in mind.

Feather:
First-person Joust, yo!

Flagging:
There are several colors of flags. You can only hurt enemies of the same color as the flag you are carrying.

Reception:
It resembles dodgeball. You are a player in the futuristic sport of Smackball.
You have a gun that can catch the ball and fire it at other players. Your gun only has a certain amount of power, which is consumed both by catching and firing the ball. It recharges over time.
To catch the ball, you must be facing it and using your gun's catch function.

Scissors:
You are a soldier who has been dispatched to the (Evil Guys) flying fortress, (Evil Place)!
You have been equipped with the (Good Guys) newest weapon, the "Slice Gun"!
You must use it to defeat the (Evil Guys) and destroy (Evil Place)'s structurale supports, which are conveniently pieces of steel cable which tie the whole thing together! Hoo-ah!

What Big Eyes You Have:
You are NINJA's most skilled soldier!
Use your stealth and cunning to destroy the evil (Allegedly) forces of PIRATE!
But be careful! PIRATE has been training LOOKOUT soldiers who can see through walls!
The LOOKOUTs are your most dangerous opponents, and nearly every PIRATE encampment has at least a few.
Beware as well of rival agents from the nefarious ROBOT and VIKING groups.
ROBOT units can see through walls, as well, and can even fire through them!
VIKING units are slow, but make lots of noise when they run, alerting everyone around them!

After your first operation, PIRATE will be after you, first and foremost. That said, you should probably let ROBOT and VIKING soften up PIRATE. Just be careful! You don't want them to get you first!

Your objective is to defeat the CAPTAIN of each PIRATE base, and destroy the reactor core, sinking the base under the waves!

----

Those are just rough ideas, though.

I like the NINJA one, m'self. Dripping with internet culture.

Looking forward to this one. :-)


---Akake

I've done some thinking.

My first thought is thus: While only one other entry is likely to be a first-person shooter (RB[0]'s team), I still want to be unique.

I think I can readily accomplish this by making a tank game instead of a standard FPS.

I can fit it into "Flagging" fairly readily, my original idea works just fine.

"Reception"... Radar jamming as a central mechanic somehow? Re-establish communications to allow an air-strike to commence? Something along those lines.

"Feather" would require me to re-think this. I'd probably make the first-person Joust idea.

"Scissors": Scissor tank, yo! Not sure how to make it a game, though...

"What Big Eyes You Have" is a tricky one. A stealth tank game, perhaps? Not sure how that'd work...


I'd probably use the mouse to control the turret. WASD or arrow keys would steer the tank. (IE: A/Left and D/Right would turn, W/Up and S/Down would make it go forward or backward, respectively)

I'd probably do collisions based on bounding boxes, which would mean that my tanks would be a bit on the super-deformed side. I like that anyway, though.

Bounding rectangle along the ground, that is. Unless I decide to have multi-level maps. Even then I'd probably fake it.

Well, that said, the meshes would probably be fairly simple, but they'd have fairly nice textures to make up for it. (Nothing award-winning, but pretty good, I think)

I like this idea. It's (somewhat) unique. The only other (Extant) first-person tank game I can think of is BZFlag, and that doesn't have tanks with turrets.

I think it'd probably be pretty fun if I did it right. I mean, what's better than blowing crap up with a tank?

I'm curious what others think about this. Could a tank game do well in PyWeek?

I like this idea. :-)

---Akake

I'm back from Ludum Dare! I finished my game! In C++!

Now I'm ready for PyWeek. And hey, I know that if all else fails, I can finish it in under 48 hours, 'mirite?

I don't have a concept yet, though. I've decided to scrap the tank game idea, and stick with 2D.

I'll be thinking about this later today, though.

I have classes today through Thursday, so I probably won't get to do much until Friday. But that's okay. More time to think about write out my boilerplate.

So... Hello again, PyWeek!

I'm ready to rock. :-D

---Akake

I've got a very basic concept.

It's a revival of Rabbit Hunt.

Instead of rabbits, though, you are hunting ducks.

Ducks are different than rabbits, by virtue of the fact that they can fly.

There are still dogs, and there are still bushes.

I will be using retrogamelib's collision detection again, but I'll be optimizing it heavily.

(Bounding boxes, spatial hash, maybe even slightly nested bounding boxes!)

I liked Rabbit Hunt alot, so I really wanted to revive it. And I don't have any better ideas, frankly!

Here's hoping...

---Akake

I've got the basics of my entities built, as well as the layout of my main loop.

I'm planning to use arbitrarily-nested terrain pieces that are defined by bounding boxes. The extent that this will be done will (hopefully) supplant the need for a spatial hash.

Well, actually, I'm going to nest the terrain pieces to such an extend that they will effectively comprise a spatial hash anyway.

I've set up the entities to use groups of terrain pieces transparently.

Essentially, the collision offset calculated by a given terrain group will be figured recursively.

In addition, I've decided against the tiered environment I had planned for Rabbit Hunt. Instead, the terrain will be one long stretch, with multiple levels in only some areas.

It will be generated semi-randomly. There will be a set of pre-made segments of terrain which will be chosen randomly, and inserted as a strip of terrain.

Tomorrow, I will make some sprites, and then terrain, and then... A demo! 8-D

Heck, if I really put myself to it, I could finish most of it tomorrow. But that would be intense.

Er... I've been implicitly talking about LD alot... Sorry about that. ^_^;

It was kind of an eye-opening experience. I found out that I could do it. That was a weird feeling for me. To be able to accomplish that much that quickly.

I feel like I can do this. And rather quickly, no less.

This will be a good one, I think. :-D

---Akake

I'm really sad to do this, but I have to forfeit.

I'm very sick at this time, and feel really awful.

I hate that I have to do this, but I need to give up. I need to rest and recover.

This is a shame. I was really looking forward to this, but between school and now being sick, it's just not going to happen. :-(

There's always next time, I suppose.

I'm not going to write a post-mortem, because there's no game. Just a page or so of boilerplate.


This is really sad for me. I'm sorry.

It was fun, and I look forward to the next one, but I'm just too sick to continue.

I... Don't have anything to say, except that I'll be back next time, and I'll try my best to finish.

Here's hoping.


---Akake

I have very, very good news.

My Acer Aspire One arrived at my school's bookstore today!
And my mom's demo (She hands out samples at the store, and manages the people who do the same) got cancelled, so she had time to drive me out to the bus stop so I could go get it!

I've got CrunchBang running smooth as ice, and am posting from the wee machine, in fact!


Also, I've decided that though I won't enter into Pyggy, I will be having my own, personal Pyweek one I'm well.
No theme, just a deadline of one week, and a requirement to use Python.

I'll be doing this once I'm well, and I'll host it on my GoogleCode compo practice page!

I'll also make blog posts here, if that's okay.

I'd like to do this, even if I have to do it late. :-)

Today was a pretty good day, overall. I got my dream machine, amidst the sniffles, sneezes, and wooziness, I got the machine of my dreams. That makes me more happy than words can express.

---Akake