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 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'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

"Let the programmers be many and the managers few - then all will be productive."

I've only ever used plain old pygame in PyWeek, so I thought I'd look at some other libraries. Pyglet is popular, so I tried to learn that. After spending an hour trying to draw a freaking circle, I realized that you really need to understand OpenGL before you can use Pyglet for graphical primitives. So I decided to learn OpenGL instead.

I had no idea how easy it is to make a 3-D flight simulator! Okay, there's still a lot to it, but between GL_DEPTH_TEST, gluPerspective, and gluLookAt, half of the work I imagined is taken care of. Obviously, lighting and textures are huge topics for a beginner, so I decided to copy those bits from the tutorial and focus on what I know: solid geometry.

The game comes in one big file, strictly-platonic.py. I developed it on a 1.6 GHz Eee PC, so I can't imagine it running slowly for anyone, but let me know if you have any trouble or suggestions. Enjoy!

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

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

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

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

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