It's not easy finding time to work on software projects when one works alone and has to support one's self delivering pizzas, but slowly I'm thawing out again.
I've written an Inkscape-svg-to-pyglet tile conversion script to make working on tiles easier. Currently it only works on solid-color shapes (am working on gradients), and only quads, but it does the trick. Importantly, it handles multiple layers, so a single vector tile can contain foreground and background elements at the same time.
I keep looking for ways to improve performance. Here is a round-up of the methods I've investigated, variously and tried to get working recently:
* Psyco was what I used before. It worked with Pygame. But Psyco hasn't been developed for years now. This was the source of the first great delay for the project. I've given up on using it.
* Cython is a system that will translate a Python script into a C extension. I have trouble getting it to work though, a problem sourced in stock Python's insistence on a specific development environment for extensions and the need to maintain a whole C-compiler and set it up. My current issues with it: I can't get it to produce a workable extension, it keeps erroring out with "C:\Python27\libs/libmsvcr90.a: file not recognized: File truncated".
* Pypy, Psyco's successor, is a Python JIT compiler, and looks like it'll be very promising eventually. There's an issue of how to package it as a standalone interpreter, and currently Numpy, which I use for building buffers for pyglet, is only partly and experimentally supported. It seems like it has no problems with pyglet itself though.
Those are the two major non-stock libraries I use, pyglet and Numpy. If it doesn't support those, it's not useful to me.
Wednesday, August 6, 2014
Saturday, May 3, 2014
Tile editing progress
After some aborted attempts at writing a tile editor, a friend pointed me to a really obvious solution. Use Inkscape as an editor! It outputs to SVG, which is an XML-based format ripe for interoperability. So after being stymied for a while, I've suddenly got a good amount of a tile file converter written. Huh.
Monday, January 6, 2014
Today: Worked on tile storage format
Today, I planned and worked on the tile storage format. I didn't conceptualize the problem appropriately though, and so I'm having to spend a bit of time thinking about how the data stored by the editor will be referenced and unpacked for quick access by the engine. It is difficult keeping all the bits of data and their representations straight in my head.
Mood: weary.
Mood: weary.
Friday, January 3, 2014
Working on a visual editor for In Profundis tiles
Trying, bit by bit, to work my way through the things that make working on the game harder, on the infrastructure of its construction. Lately this has taken the form of a visual editor for designing the vector-based tiles the game uses.
You see, the tiles the game uses are constructed out of OpenGL graphics quads on different "layers." This provides many subtle advantages: we can arbitrarily scale up or down the graphic size, most of the quads are stored on the graphics card and displayed as needed "for free" and so we only have to change those quads that are both visible and have changed since their last display, we can have larger-than-grid-size tiles if need be, the layering system, where each tile can have components on different layers, gives us free outlining and neat effects, and so on. I honestly don't think I've even exhausted my idea space for what the system can be used for.
The catch is, I can't design tile graphics in a graphics editor. At the moment, all the tiles are stored in the source code as sets of coordinate and color values, which reminds me uncomfortably of coding up large DATA statements back in C64 BASIC 2.0 days. The idea is to use the visual editor to design them, then store them in an external file, probably as a Python pickle, at run time. Of course I'll release the editor too for modding purposes. Since realtime performance isn't such a priority I can use Pygame for it.
Well, that's the update. So you see I'm not completely idle, there are things being done. I'm churning away, although keeping everything straight in my head is a formidable problem I am nowhere close to giving up on this.
You see, the tiles the game uses are constructed out of OpenGL graphics quads on different "layers." This provides many subtle advantages: we can arbitrarily scale up or down the graphic size, most of the quads are stored on the graphics card and displayed as needed "for free" and so we only have to change those quads that are both visible and have changed since their last display, we can have larger-than-grid-size tiles if need be, the layering system, where each tile can have components on different layers, gives us free outlining and neat effects, and so on. I honestly don't think I've even exhausted my idea space for what the system can be used for.
The catch is, I can't design tile graphics in a graphics editor. At the moment, all the tiles are stored in the source code as sets of coordinate and color values, which reminds me uncomfortably of coding up large DATA statements back in C64 BASIC 2.0 days. The idea is to use the visual editor to design them, then store them in an external file, probably as a Python pickle, at run time. Of course I'll release the editor too for modding purposes. Since realtime performance isn't such a priority I can use Pygame for it.
Well, that's the update. So you see I'm not completely idle, there are things being done. I'm churning away, although keeping everything straight in my head is a formidable problem I am nowhere close to giving up on this.
Friday, October 11, 2013
Gonzo skill system trials
Rather than taking it for granted that my weird skill system idea will work as hoped, I'm taking a small detour to make a simple game testbed for it, so I can get some picture of what it'll work like in practice. I am considering making this available to backers as a bonus, something to play around with. That is, when it's written.
The past couple of days have been mostly spent designing it further, and looking into the capabilities of the IGraph software, which has a Python package interface, to this end.
The past couple of days have been mostly spent designing it further, and looking into the capabilities of the IGraph software, which has a Python package interface, to this end.
Monday, October 7, 2013
Native AI, crawling
Slow going as I go through and try to figure out how to implement these things. For native pathfinding, I'm considering a variation of the kind of pathfinding that ants use in the real world (and in fact is used in Will Wright's SimAnt). Before that though is crawling. Since the player is an entity in the world, although one composed of multiple tiles, crawling actually changes his shape.
In positive news, the interaction cursor works fairly well.
In positive news, the interaction cursor works fairly well.
Crawling
The main character can now crawl. It sounds like a minor thing, but now that the character is actually an entity in the cellular system, the system has to be able to resize entites, check to make sure there's room, and things like that. The analogue in the platforming system is all those problems with handling wall embeds and ejects, which is one of the trickiest parts of programming a platformer, so trading these problems, which are now solved pretty much, for those, which I never could get to work right in the prototype's dynamic world with a sprite overlaid, is a good trade I think.
I'm going to have to modify the display engine now to display multiple possible actor states. After that, more inventory work, then maybe actually putting in new entity types, like growing plants, the beginnings of an ecosystem, and other actors.
I'm going to have to modify the display engine now to display multiple possible actor states. After that, more inventory work, then maybe actually putting in new entity types, like growing plants, the beginnings of an ecosystem, and other actors.
Monday, September 30, 2013
Multiple sized actors, menuing, interaction cursor
- Multiple-sized actors means, the creatures you interact with can be different sizes, to a single block, to human-size (three blocks high), to bigger. This also means multiple-sized players, which will come in handy for things like crawling through low passages... or shrink rays?
- Menuing is working now. The beginnings of inventories (both player and other) are in. Item classes are progressing.
- The interaction cursor, which never did much in the prototype, is back, and has a wider array of movement than before and is more flexible, and easier to control.
- Up until now, world generation has been accompanied by flashing colors, just to indicate that something is happening and nothing has crashed. Now it displays a log-style progress report.
Step by step, inch by inch....
- Menuing is working now. The beginnings of inventories (both player and other) are in. Item classes are progressing.
- The interaction cursor, which never did much in the prototype, is back, and has a wider array of movement than before and is more flexible, and easier to control.
- Up until now, world generation has been accompanied by flashing colors, just to indicate that something is happening and nothing has crashed. Now it displays a log-style progress report.
Step by step, inch by inch....
Tuesday, September 24, 2013
Working menu
I got a menu working. The difficult part of this isn't creating a menuing system it's making it work with the overall state machine, which affects display, setting up its own state machine, and so on. I'm not real used to this frame-based, event-driven business, dangnabit.
Menu coding continues
Trying to track down some state bugs in menus. Also, menus are appearing (in their clumsy current form), but the selector arrow doesn't appear to be moving.
Saturday, September 21, 2013
Menus
I haven't done a whole lot of menus in a state machine driven kind of design before. I keep trying to design something sensible and modern, and I keep noticing how my idea for approaching the problem are deficient. The perfect is the enemy of the good, I know, but I'm just aiming for fairly acceptable at this point. I'm going to describe what I'm designing right now, not just to stay public about things, but also because it'll help me keep it all straight.
At the moment the program tracks what state its in in a global variable called basis. basis is actually an object that links to almost everything about the program's progress for easy saving and loading later, but it tracks overall state too. Two of those states, and probably more in the future, involve menuing: the title screen, and the inventory screen. Additionally, some of the menu entries may spawn additional menus according to what's chosen: does the player want to pick up an item, or drop it, or use it, or equip it?
So we actually keep a stack of menus; if we open a submenu, we create a new Menu object and push it onto the stack. That part is fine. But the code that actually does things with menus, that is still in the state handling routine that is called every frame, and so that's got to track which submenu it's in. It seems like I should be able to design this in some better way (maybe the code for handling the menus should be part of the item itself?), and that possibility is distracting.
At the moment the program tracks what state its in in a global variable called basis. basis is actually an object that links to almost everything about the program's progress for easy saving and loading later, but it tracks overall state too. Two of those states, and probably more in the future, involve menuing: the title screen, and the inventory screen. Additionally, some of the menu entries may spawn additional menus according to what's chosen: does the player want to pick up an item, or drop it, or use it, or equip it?
So we actually keep a stack of menus; if we open a submenu, we create a new Menu object and push it onto the stack. That part is fine. But the code that actually does things with menus, that is still in the state handling routine that is called every frame, and so that's got to track which submenu it's in. It seems like I should be able to design this in some better way (maybe the code for handling the menus should be part of the item itself?), and that possibility is distracting.
Thursday, September 19, 2013
Hard drive replaced
Well it came down to it, and I had to replace the laptop's hard drive. Fortunately full backups were already made, and it just took time to do it all. A surprisingly large amount of time: I apparently have one of the few laptop brands that doesn't make the hard drive easily accessible, and I damn near had to take the whole thing apart! Here's the step-by-step video I used to do it. How tiresome. Thanks a heap, Dell.
Tuesday, September 17, 2013
Recent progress
Still churning away, although admittedly slower than I like the past week and a half. Most of that is working in the pizza mines, but it doesn't help that I'm in the part of the coding where I'm implementing the menu system.
One of the things I learned about doing over what I'm going to call the Hiatus Project is designing and coding state machines. Most games these days are implemented so that they have to call a loop that draws the display every frame, and because this routine has to run regardless of what else in the program is doing, it means implementation of the main loop pretty much requires some sort of state machine, to do the displaying then continue working on whatever else the program has to be doing at that moment. There are alternatives, but this seems to make the most sense here. (Python has an alternative called co-routines that presented an alternate design strategy, but other than a generator used during map generation, I've avoided them, because they are a feature that Cython does not yet support, and I'm still aiming towards using that eventually.)
Well the menu system is part of that. And another thing is ideally the menu should allow for being recursive -- if you've got the inventory open, for example, it'd be nice if there were submenus for determining what you can do with a specific item. And what's more -- and this is where it gets a little weird -- it'd be nice if this happened while the sim is going on in the background. That is, I am strongly considering having the inventory window open not pausing the game.
Why? Well the thing is, while I'm not trying to develop an action game, it is still what I'm going to call a tension game. Not about performing a sequence of controller or keyboard inputs as fast or accurately as possible, but more about, sometimes, having to decide what to do and get it out of your virtual pack in an expeditious period of time.
There will still be game pausing, of course. And encounters with NPCs will necessarily pause the simulation portion of the game because it could be a subtle form of cheating if it didn't. But the inventory window being open, I am considering, might not pause the simulation.
I'm still thinking through the ramifications of this. What if something important happens while the window is open? I'm considering popping up an alert message, or if it's particularly serious auto-closing the window. Well, I admit it's a weird idea. I might just forget about it. But I figured I should say something about it.
One of the things I learned about doing over what I'm going to call the Hiatus Project is designing and coding state machines. Most games these days are implemented so that they have to call a loop that draws the display every frame, and because this routine has to run regardless of what else in the program is doing, it means implementation of the main loop pretty much requires some sort of state machine, to do the displaying then continue working on whatever else the program has to be doing at that moment. There are alternatives, but this seems to make the most sense here. (Python has an alternative called co-routines that presented an alternate design strategy, but other than a generator used during map generation, I've avoided them, because they are a feature that Cython does not yet support, and I'm still aiming towards using that eventually.)
Well the menu system is part of that. And another thing is ideally the menu should allow for being recursive -- if you've got the inventory open, for example, it'd be nice if there were submenus for determining what you can do with a specific item. And what's more -- and this is where it gets a little weird -- it'd be nice if this happened while the sim is going on in the background. That is, I am strongly considering having the inventory window open not pausing the game.
Why? Well the thing is, while I'm not trying to develop an action game, it is still what I'm going to call a tension game. Not about performing a sequence of controller or keyboard inputs as fast or accurately as possible, but more about, sometimes, having to decide what to do and get it out of your virtual pack in an expeditious period of time.
There will still be game pausing, of course. And encounters with NPCs will necessarily pause the simulation portion of the game because it could be a subtle form of cheating if it didn't. But the inventory window being open, I am considering, might not pause the simulation.
I'm still thinking through the ramifications of this. What if something important happens while the window is open? I'm considering popping up an alert message, or if it's particularly serious auto-closing the window. Well, I admit it's a weird idea. I might just forget about it. But I figured I should say something about it.
Sunday, September 8, 2013
Various things
Working on an assortment of things today, in addition to continuing to look into something to record the screen (I might eventually have to go with a gizmo that reads the computer's videoout), I'm working on the basics of the menu code.
At least things are moving along a lot faster now than they were! Spirits are running kind of high regarding In Profundis, in fact. Dum de doo....
At least things are moving along a lot faster now than they were! Spirits are running kind of high regarding In Profundis, in fact. Dum de doo....
Menus, more movement, and trying to record video
The thing I used to record the original intro was Microsoft Expression something-or-other, but that version also used Pygame and handled drawing in software. Camstudio doesn't want to record OpenGL, and I've yet to find something suitable to replace it.
In other news, I'm thinking more about the skill system, native AI and pathfinding. I'm considering using a system, if I have my algorithms correct, similar to that used in Will Wright's classic game SimAnt, where entities leave "trails" behind them that others can follow or ignore depending on what their priorities are. But I'm still thinking about it.
While working tonight, the MST3K episode "Wild Wild World of Batwoman" was playing in the background. It's not easy to code while cringing. How on earth did that movie get made?
In other news, I'm thinking more about the skill system, native AI and pathfinding. I'm considering using a system, if I have my algorithms correct, similar to that used in Will Wright's classic game SimAnt, where entities leave "trails" behind them that others can follow or ignore depending on what their priorities are. But I'm still thinking about it.
While working tonight, the MST3K episode "Wild Wild World of Batwoman" was playing in the background. It's not easy to code while cringing. How on earth did that movie get made?
Screencasting
The program I used to make movies earlier I can't seem to find, and Camstudio doesn't seem to want to record OpenGL hardware surfaces. Would anyone happen to know a good, hopefully free, screen recording program?
Saturday, September 7, 2013
The Guy
I have a guy walking around now. Movement is not smooth (in fact, he "steps" along a tile at a time), but that keeps with the conscious attempts to downplay platforming. Despite this he can jump; it's too limiting not to be able to jump a bit.
If anything, he probably moves a bit too fast at the moment.
If anything, he probably moves a bit too fast at the moment.
Wednesday, September 4, 2013
Player movement, adapting multitile objects for use as actors, planning native AI & pathfinding
The subject line says it all.
Sunday, August 25, 2013
Multitile aggravations
I've gotten multitile objects working, and not becoming inconsistent as they fall or move around or anything. It was a bit of a debugging minefield but they seem to be working now. There are still some problems and inefficencies, but it's not something that should hold on moving onto the next item, which is, the player and movement.
Saturday, August 24, 2013
Hacking away at multitile objects
Still working on it. I think I'm getting close. Ultimately, in addition to boulders and moving characters who are larger than a single tile, this will make possible Mr. Driller-style, large irregular blocks, that can support each other in interesting ways. It is not entertaining work though, it has been dragging. I continue to muddle through it.
I've been thinking a bit about objects being able to fall more than a single tile per frame. Currently fluids, to make up for the fact that they are no longer slices in single tiles but full tiles themselves, can fall up to four spaces per frame. I've thought a bit about generalizing that into a generic movement system, which would result in more realistic physics to a point. It would not be a simple change though. I think I'd be better served reimplementing character movement, NPCs, and starting on item and inventory stuff.
I've been thinking a bit about objects being able to fall more than a single tile per frame. Currently fluids, to make up for the fact that they are no longer slices in single tiles but full tiles themselves, can fall up to four spaces per frame. I've thought a bit about generalizing that into a generic movement system, which would result in more realistic physics to a point. It would not be a simple change though. I think I'd be better served reimplementing character movement, NPCs, and starting on item and inventory stuff.
Subscribe to:
Posts (Atom)