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

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

There's still a long way to go, but I have time now. I've just scrapped most of the code of IP Saints, though I'll probably scrap a few more pieces of code by the end of the week.

I'll be starting with redefinition of a basic UI. Once again using Simple Pygame Gui as basis for the code, though this time I might also take a look into version 2 of spg. Both seem to cover what I need, with the exception of (I don't know why), fixed-position windows.

For the next few days I'll be monkeying around with the styles and try to get something that feels right for the game. In my Pyweek entry it was kinda obvious that I had no time to worry about customizing the UI for my game and I didn't like that.

I'll be posting screenshots of my style experiments to the diary.