Blatently Unoriginal Entertainment
Awards
Diary Entries
Procedurally Generated Map Plan
I quickly wrote up an article on my blog about how I am going to try to procedurally generate maps in my game. It's just a basic run-down that doesn't fully explain everything everything, but it does show enough about how interesting maps can be made.
Now I need to figure out how I am going to use this along with the theme. I also needs to actually start coding, as I already wasted quite a bit of time.
End of First Day
After writing up that blog post about how I might do procedurally generated maps I sat down and did a few hours of coding. I was taking things pretty easy, as I did not want to overwork myself. I am satisfied with what I had accomplished, though. I have a start on a nice foundation to build a game on top of. The list of today's accomplishments include:
- A game state manager that easily handles switching, updating, and drawing game states along with event handling.
- An entity management system that can add, remove, update, and draw entities along with grouping entities by category and sorting them by their y value for proper layering when rendered.
- Loading of values from a settings.txt file, so game players can easily adjust the game to their liking.
- Scaling the game's screen size for people who might want to double or triple the size of the pixels.
- Thorough testing to make sure everything is working right.
Some things to do tomorrow might include
- Entity collision and response.
- Animation system.
- Media management -- sound, images, music, etc.
- Effects system, so effects like explosions, for example, can be easily triggered.
- Actions system for flexible and reusable entity behaviors.
End of Second Day
Today I did not accomplish as much as I hoped I would, but I did still make pretty decent progress. The things I finished today were:
- Resource management (images, fonts, sounds, animations, etc.)
- Sprite animation system.
- Slightly better sprite drawing system.
- Input system with customizable keyboard and joystick button mapping.
- Start of an actions system. Example: target_object.action(actor_object, "action_name") will call whatever action is assigned to that action name. For example, wood might have a 'catch fire' action assigned to "burn", where dynamite would have an 'explode' action assigned to it's "burn" action. These actions are reusable for any object, so, if I wanted to, I could on a whim add one line of code and reuse the 'explode' action on other objects with other actions. Deadly exploding signs that are dangerous to read for no explicable reason? Why not?
I haven't gotten around to working on any graphics, procedural map design, or any actual game-play, so I still don't really have anything to show. I just have a test with old sprites moving around on screen and basic interactions.
Bits and Pieces
I have a lot of little bits and pieces of a game that needs to be pulled together. Also, there is a lot of stuff still unfinished. Tomorrow I need to accomplish (if at all possible):
- Finish random dungeon generation (I put this off a little too long.)
- Build tile map from this data.
- Create a few enemies.
- Create a few interactive objects.
- Populate the world with game objects.
- Music.
- Sound effects.
- Menu.
- Create items and weapons.
- Create item selection menu.
- A lot of graphics.
- Title graphics.
- Finish main character's animation.
- Etc.
Ugh. It almost looks like I haven't done anything! I do have a nice core game engine with most of the functionality I need. If I had started with an existing game framework a lot of time could have been saved.
A lot of time was spent on graphics, and a lot of time will still be spent of even more graphics, along with other media. If not for all the graphics and animation I need to do I could be done lightning fast! The way my game engine is designed I could code up a dozen new game objects in under an hour, but the graphics and animation for them will take so much longer. Maybe I'm trying to be a little to neat with my pixel art.
Can this be PyWeeks (plural) instead?
DNF and here's why.
I was really hoping this would be the PyWeek where I actually finish something. Most of the week, however, was spent working on core engine functionality instead of actual game-play.
If, perhaps, I programmed my game in the style of a Ludum Dare (direct, game-specific, quick hacking, etc.) maybe I could have completed a game. Instead, I programmed in a way that might have been better suited for a longer development time -- general, flexible, and potentially reusable source code.
Also, due to an old computer, I was using a 320x240 screen resolution with PyGame. At such a low resolution pixel art is necessary for clearly identifiable sprites, where a higher resolution could have more easily used 3D rendered or hand-drawn sprites. Unfortunately I tend to become more of a perfectionist when working pixel-by-pixel on graphics. To give you an idea of how I was overdoing it, I made 28 frames of animation just for my main character, and that was just standing, getting hurt, and running -- I didn't get around to weapon animation.
I am incredibly impressed with PyMike's BubbMan 2. Looking at his source code and data it looks like we might have done close to the same amount of work, however his use of the Retrogamelib and simpler art-style were definitely an advantage. For the next PyWeek I should look into the use of some library thats more than just PyGame. I could have saved a lot of time not writing this functionality myself during the week.
Perhaps I should go through my code, clean it up, and release it as a game development library. It has systems for handing resource management, frame-rate independent animation, an input system allowing for easy and seamless keyboard or joystick, entity management, sprite depth sorting, collision detection, tilemaps, game states, simplified entity interactions, flexible configuration file loading, etc. It would save a lot of time for future competitions.
I also made great progress on my procedurally generated map algorithm. The maps it generates is great, but I was only able to do about 2/3 of what I originally planned for it. For example, actually converting the data into a tilemap wasn't really finished. Also item and door placement wasn't really done (though I haven't actually gotten around to really making a lot of items anyway.)
If I had one more week I know I could have finished it. I will continue working on this game (perhaps after extracting a reusable library from the code), so I'll tell you guys about it when/if it is done.
Maybe next time I'll have a finished game by the end of PyWeek.