Improvements in this version:

• It's not quite so easy to get your yarns tangled, although still possible if you're not careful.
• If you hold one arrow key and press and release another, you now continue moving in the original direction instead of stopping.
• You can now squeeze in between a ball and a wall and nudge the ball away, so it's no longer necessary for me to disallow pushing things up against walls. On the downside, you now have to be a bit more accurate lining up with a ball in order to push it. To make this easier, I've added shadows under the player and balls.
• There are two more levels, and a new kind of object. I won't spoil your fun by telling you what it is. :-)

By the way, if anyone would like to join me as a level designer, let me know! The biggest thing the game needs right now is ideas...

So far, I have done 0 lines of code for Pyggy. The "release" I have at my files is just something I've added for myself so I could have a more challenging level to play while I waited for the results. Wanna know the reason why I haven't done anything? The culprit here is code cleanup.

Are you doing a game? If your personality type is anything like mine, you should better be doing it right the first time. Programming is fun, learning from your mistakes is good and rewarding, looking at a horrible pile of crap that you have coded yourself and thinking about putting it in order? *YAWN*

Whenever possible you should do things right. There are very rare exceptions to that, and I'm going to list them down with as many restricitons as possible, because I really want to discourage people from trying out "quick and dirty" approaches to things.

When is it okay not to "do things right":

• You are in an algorithms competition. The programming phase of the competition is ending, you're unsure of what you're doing and submitting programs that do something wrong will not cause your score to be punished in any way. Under such circumstances you're probably not going to get the problem solved, but you might, which is better than the 0% chance of getting it right if you give up.
• You're trying to learn some new algorithms. Under such circumstances, it is kinda natural that you'll mess things up a bit in the way. Play a little with the algorithm while you do not understand it very well, but make a good, correct and well-tested implementation of it as soon as you're capable.
• You're learning a new programming language or library and you have no clue of what constitutes "doing it right". This is similar to the case above, play around a bit. Do not build a big project while you don't understand well what you're using. Instead, write small projects, enter mailing lists, ask questions, ask about programming standards, talk on IRC channels. Whenever there seems to be disagreements on what constitutes good practice you think carefully. Keep a a copy of the Zen of Python whenever you feel conflicted.
• You're intentionally trying to write bad code. Under such circumstances you should pray you're not my co-worker.

The main reason for that is that you don't want to build upon bad code. Things built over bad code very hardly become good. Things are going to be clunky, behave in ways you did not expect or simply not work at all.

Working with improper code disrupts your job in several ways. If you're adding features to a game in the last minute you risk breaking what could have been a perfectly functional game. If the design is stupid, the things you build over will have a higher likelyhood to be stupid too. Worse, they might depend on stupid design.

You do not want to build code that depends on something else in your program being stupid, because when you decide to "do things right", you'll see that fixing one thing breaks everything else.

So, there. I'll probably just scrap entirely most of what I've written for the game and start clean. I don't want to make fixes to what I've done, because if I do so there's going to be a huge overhead of making what I intend to be good code comform to the stupid code I wrote for the compo.

"Doing things right" takes a bit of practice, but it is in no way a time consumer, but a time saver. Think before you code.

So far this is just an improved version of my PyWeek entry. (See the changelog.)

It'll be some time before I have anything to show. So far I've just got a tray icon, and something that checks for the pygame version. (I thought about somehow getting the game to work in older pygame versions, but I use LayeredUpdate extensively, so I'd pretty much have to re-implement it. So I'm requiring pygame 1.8.0.) Mostly I've been brainstorming game mechanics.

My main plan is to have 15-20 levels (the PyWeek version has 5). No two levels should be exactly alike: each one should have some new or unique aspect, a unit or a hazard or something else. If each level lasts 3-4 minutes, that's an hour of gameplay, and hopefully it'll stay interesting for that long.

cyhawk suggested that rotation affect gameplay. This is a great idea, and some of the mechanics I thought of have to do with that. For instance, you'll have a couple seconds' warning of where lightning will strike, so you can avoid it to a certain extent by rotating out of the way.

I also want to incorporate placement as much as possible. It should matter not only how many structures you have, but where they are with respect to each other. I've got some ideas for how to make this happen, but nothing yet that will offer a rich strategy, where you have to make tradeoffs. Still working on it.

I realized I haven't played many video games lately. I'll have to find some strategy games to play that I can steal ideas from.

Here is how I want the new UI to look like:

The idea is that when you select an unit, you get the options of moving, attacking (if you have an enemy nearby) and checking the unit's status. Attacking an unit always ends your turn, canceling an action takes you to the image that has the previous menu, including the character's previous position (if you have moved but decided to cancel).

Right now as I think of it, it sounds like a complicated problem, but with the deadline far away and so many hours already spent thinking about the problem, the solution is probably going to pop into my mind as I have lunch, shower, confess my love to a girl or while I do all of this at the same time.

If you happen to be colorblind, I apologize for the terrible image. But this is just a mock-up and I'll try to take this into consideration in the game.

I'll post more about this when I start to define the new UI code's structure.

So, my first post on Pyggy. :)

Here's what I've been doing most of Pyweek 8.



I'm just a programmer and I'm far from being a pixel artist, so you can imagine how long it took me to draw all that. :) The heart in particular took me most of the first Pyweek day. I removed the attic because it's a dark secret. ;)

This game is a horror strategy and resource management game where you control a haunted mansion and do evil stuff to scare people out of it. The gameplay is basically using powers to make them scared, corrupt them, and even hurt them and kill them later on the game. Resources to summon these powers are clutched from their own fear. My intention is to have a very dark and grim atmosphere, typical of horror games.

I know the idea of the game is a bit heavy and it may make some people uncomfortable (I admit it even bothers me to work on it), but it should be an interesting experience, I have some interesting ideas. It's actually meant to make people a bit uncomfortable when playing, but I'll try not to overdo it. It's not often that you take the "bad guy" side on games, and it's not often that you play evil itself. So I thought that might be a good idea to play around with, and the "Get off my lawn" theme worked nicely with it. You might want to look at this game as an experiment - it's the kind of idea that would never work with the public in general.

I actually have much more design-wise, but I'll show it throughout Pyggy. Good luck to everyone. :) I hope I finish it this time.

I enjoyed doing IP-Saints a lot. But I was unable to make a full game. My Pyweek entry was buggy, had extremely poor AI and, with few exceptions, it was basically composed of placeholder images.

Here's my goals for this Pyggy Awards:

• Code cleanup: As Pyweek's deadline got closer, I started getting anxious about getting things done. It's hard to say whether I had the best strategy with the given time, but the current lack of quality in the code prevents proper bug fixing and makes extending the game difficult.
• Game rules improvement: The game's rules look almost like I want them to look like. However, there are some tweaks I want to try and they could result in the game being more fun.
• Graphic improvements: More on that later. I'll provide my diary with sketches of how I want things to look like.
• Voice acting: I think that voice acting would do good for those specials. I need to find a woman with a "stern diciplinarian" kind of voice for Justice. I'm not sure what to do with other characters' voices yet.
• Extend game: The game was not intended to be all about fighting pirates. But also bloggers, artists, nonprofit organizations, hackers... I'm planning to have a few more maps and battles. It'd be nice if I can make the main characters' quotes depend on the type of enemy they're fighting.
• Introduction, between-battle stories, proper ending: While it is nice to have characters be able to say something from within the battle screen, it'd be nice to have some story outside those battles too.

I hope that's not too much. 3 months sound like enough time, but that may cause me to slack off. And, well, I got other stuff to do as well...

I've decided to write down notes about the various characters in the game, both enemies and player characters.

First up is the game's star protagonist, Rose.

Rose's four attacks are:
Standing: A plain ol' slash
Running: A lunging slash
Airborne: A (cheesy) somersault slash
Crouch: A jumping uppercut
Projectile: Shuriken
(The melee attack used when wall-sliding or climbing a ladder is the same as the attack used when standing, just with different sprites. Similarly, the attack used when swimming is the same as the one used when airborne)

Rose looks a bit different this time around. Her stealth suit has baggier sleeves and legs, and she has foregone the full head-mask in favor of a face-mask and a ponytail.

Rose's stats are:
Health: Bad
Attack Damage: Average
Running Speed: Good
Jump Height: Good

I'll post a sheet of her sprites once I've got them all done! BooYeah!

-Akake

Oops! Mistook an error for not being able to post! My bad!

I thought maybe I'd share some of what I'm working on right at the moment.

I've got four characters, as it states on the entry page.

Each playable character has the following abilities:
-A flexible attack system that can attach a function to an attack, or to a frame of the animation for that attack
-A melee weapon or attack with four attack types
-A ranged attack which can be aimed up, up at an angle, forward, or down at an angle (And also straight down when the character is airborne)
-The ability to properly attack while wall-sliding, as well as while climbing a ladder or swimming
-Walking, running, swimming, climbing ladders, crouching, crawling, jumping, wall-jumping and wall-sliding
-Varying health, running speed, jump height, wall-jumping skill, and attack damage
-A unique set of sprites for all four characters! (No More Recolors!)

In addition, every enemy will have the same abilities, with the following expections and additions:
-Configurable difficulty
-The ability to sense hazards in their environment
-Basic pathfinding (Very basic)
-(Faked) Awareness of the effects of their attacks (Cooldown, Movement, etc.)
-Ability to recognize when the player is behind an obstacle
-Ladder recognition
-Five unique types, each with four unique sets of sprites (Again, No More Recolors!)
-Slightly randomized stats for each individual enemy (Every enemy will be slightly different)
-The ability to respawn after a while (The level loader/factory will place enemy spawn points in levels instead of enemies directly)

There's alot of spriting that has to happen, but it shouldn't be too much trouble. The coding might be problematic, though, but that just needs to be done one step at a time.

---Akake


Edited a couple times to refine the notes on the melee attacks with my abilities to carry them out :-P