Release 0.0.8C

Got a quick chunk of time to play around with this again.  The minimap is now working properly, and that memory fix I talked about is now in.  The tileset may also have been tweaked, I’m not sure on that one.  Grab it here!

Advertisements

Memory, Python, and You.

Rather recently I learned about a handy little program called Valgrind. I get to use it to debug some C++ code that works with dynamic memory to fix any leaks that occurred. As it turns out, this program can do a lot more.

Something I’ve noticed for a while now is that Graff takes up a pretty significant amount of memory–around 40 megabytes of RAM. I never really thought about it too hard until now, but I discovered that with the command:

valgrind --tool=massif python Start.py
...
ms_print massif.out.** > output

it takes snapshots of Graff’s memory usage. The first time running this and opening up “output” gives this result:

mem1

So currently I get ~43MB usage of the heap (or in python terms, plain memory) by just opening up the program and running around. Later in that output file, I notice a lot of calls to “SDL_CreateRGBSurface (in /usr/lib/libSDL-1.2.so.0.11.2)” seem to be eating up the most memory percentage-wise.

Doing some digging, I find out pygame converts images into a .RAW format for fast blitting–unfortunately, the file size is pretty hefty. Looking through my code, I notice that within Entity.py, when an entity is initialized, it loads up a file called “tiles.png” to pull the entity’s picture out of that and use it. After that, that loaded image is just kept there, permanently until the program quits. Tiles.png is only 42.3KB, though, which seems a little weird.

I decide to see just how many times entity loads up this image and stores it away forever. It turns out that this file is being loaded around 200 times, and is then saved as a member variable “self.sheet”. Since we don’t need it anymore once the entity’s image is ripped out of that sprite sheet, I decide to add one extra line to my code:

delete self.sheet

, after the entity’s image is set. What does that memory chart look like now?

mem2

15.64 MB is now used. By adding one extra line of code to delete an unused part of the code, I cut memory usage by 2/3!

Tinkering around some more, I find the pygame init routines take up a total of about 5MB, which means the code portion that I wrote takes up about 10MB of RAM. Perhaps now I’ll start paying attention to where memory ends up in Graff.

Map generation #4.5 – tidying up some ends

In my last post about this map-making process, I seemed to have left off at the part where the image itself is generated in its own separate program. Converting this image into a matrix for use in Graff was relatively straightforward. Pygame’s surfarray module allows one to access a surface (the screen) and treat it as a matrix of color values. From there I pulled out the color, used a dict datatype to convert that color into a tile type, and then write that into a matrix for use with the Graff; that wasn’t much of a problem.

However, one glitch I’ve noticed is that often the map would have some holes in it–it seemed like the algorithm would skip over a tile, perhaps because it couldn’t find a properly-fitting tile, so sometimes you get things that looked like this:

glitchy tiles

As it turns out, that was the case. I simply did not make enough tiles to cover each possible combination. After thinking that I’d have to make a mind-boggling number of additions to the 6×6 tile pieces I already have, I edited the code so that if the tile it needed could not be found, it should spit out that key combination and then I’d see where that would take me. Altogether, only about 30 “impossible” combinations of tiles ever seemed to come up, so I just added those extra ones onto the tileset.

After doing that, the results are much cleaner. Some glitches still remain (mainly I missed a few combinations, it seems), and I’ll probably adapt this to work with a smaller scale (say 3×3 instead of 6×6) or make changes to it to develop other areas, but I think I’ve just about exhausted the usefulness of posting about this process.

Still a little glitchy, but better!

Oh, there is also the problem of the map not always being one complete piece. I still haven’t decided in what way I’ll solve that one yet, but there are some more interesting questions about Graff that I think I need to find an answer to first.

0.0.8

Release here!

This’ll probably be the last update for a few weeks. Trying to go back to Python after spending a few weeks of working with C++ feels so..different. I might switch this project over to C++ if I get equated well enough with it, or maybe I’ll just start working on a C++ project instead and keep this around too. Busy busy busy. Either way, more activity will come in December or so.

The only glitch I’ve noticed with this release is the minimap is a little screwy. I know why it doesn’t work, but if I hold off on this until I fix it, it’ll be even longer before this post comes up.

CHANGES:
   Added a (barebones) title screen.
   Custom keybindings via title screen.
   Added “Key” py file and an ini file for manual editing if need be.
   Digging function cleaned up somewhat.
   Integrated new map generator.
      A fully glitch-free version is finished, I just need to update it.
   Changed scrolling/grass behaviors for more natural movement.
   Automatic screenshots placed in the Screenshots directory. Use the SCROLL LOCK key.

Additionally on that page under Misc, I’ve added in a dialog.py / dialog.txt file to show how my dialogue system will hopefully work. Run it through the terminal

Brief update.

Got some feedback on how the player movement worked and so I decided to switch it to the original idea I had–when the player gets too close to the bounds of the screen, then the screen recenters itself on the player, as opposed to re-centering every single time the player moves. Likewise the grass is now drawn so that it looks “attached” to the tile, instead of before where the grass appeared to just float under the screen like an odd parallax effect (see image; night sky is what the grass looked like if anyone hasnt tried out this thing).

Also, I’ve worked in the map generator into the game itself. It looks a bit weird, to be sure:
ingame map generator
But I feel like currently that’s due to tileset issues and not necessarily the code. Don’t mind the odd looking minimap, still have a few kinks to work out.

Also, now I’ve got a way to output screenshots (properly labelled to boot) into a ‘screenshots’ directory when you press the printscreen key. Saves time when I’m on Windows, thats for sure.

Still alive here.

For the time being, that is, what with college looming and all. Got a fancy title screen implemented in Graff, and by fancy, I mean it’s a plain blank page with the text “[S]tart [K]eybinding [Q]uit” on it. I’m thinking eventually I’ll try to make up some little ascii art thing to give the title page something worth looking at, but what’s somewhat more important about the title page is now… I have a title screen!

As a person mentioned to me, on a laptop you can’t really use this thing because of a lack of a numpad. I’ve rectified that now by setting it up so that, before the program runs, you can press K at which point it’ll run through the 10 or so keys to bind. Once you’re done, you can press S to go right into the main game, using those newly bound keys. In addition I’ve made it so the keys are saved to a file via ConfigParser–as a result, technically it is human-readable, though keys are listed as numbers (up = 97, etc). The idea is that when I feel the need to create an options menu, one could either edit the options in the game, or they can pull up the .ini and play with the options there, too.

Funny thing, too. Raw python seems to not have a way of capturing numpad inputs (and differentiate them from the regular keyboard keys), at least with the raw_input() method. That tripped me up for a bit since I was hoping to implement this title screen in the terminal, but no big deal. There’s probably a package somewhere that fixes this, but the fewer external dependencies I have, the better.

My list tells me that the next things I’ll be working on will be inventory systems. Following that, NPCs and shops. Fun fun. I should probably toy with equipment first, though. If I remember right my armor system needed to be retooled a bit.

0.0.7

Release 0.0.7

Release 0.0.7

Changes:

Added in a custom building to the town
There is a healing item in the center of that building
Combat formulas have been changed and somewhat randomized
Entity definitions have been reworked into a separate file and streamlined
Monster statistics have been reworked to adjust by level
Multiple monsters have been added
—Some creatures are slower and hit harder, etc
Turn system is now in place to give creatures different speeds
Stairs take you to and from the caves
—Topleft of the town is the entry point to the caves
—Bottomright of the caves is the exit point
The town is now persistent until the game quits; caves are still random
Health and mana are now displayed on the GUI
—Health changes to red as you lose it; mana currently does nothing
File structure has been cleaned up: all code files now reside in the “code” folder
Graff’s display icon is the gelatinous cube until something more appropriate is found

Link is here.

Decided to hold off on an inventory and release what I’ve got so far.