Kurosuke (working title)

[tentus]

The fourth player (a hare) has been added, rounding out the Kurosuke roster. Pretty happy with him, check it out.

The big news, however, are two massive feature additions to the level editor. First, I have made right-click select objects from your brush set, meaning that it is much easier to edit levels quickly. Second, I have written a function that will randomly place geometry en masse: essentially, very very basic procedural level generation. Hit the F key to see it in action.

I've also simplified the shapeData system, in terms of code length/complexity at least, I suspect that the actual execution is a little worse for wear. Still, it ought to help make implementing little fixes and features easier in the future, because I won't have to bend over backwards to get to the variables I want.

As usual, I beseech thee to give me bug reports: I can't fix things that I don't know are broke.

[tentus]

Version 110220 mostly focuses on improving enemy AI, by using the "white cane" method talked about on this forum before. It's still pretty simplistic, but it seems to be working OK. This version also brings shape masking into play, which allowed me to streamline some internal stuff at the cost of legibility: setCategory(1) doesn't read very well, but it is very effective.

There are various other little bug fixes, variable renamings, and so forth, particularly in the misc options. This version also brings proper player stats into the player's view, with little informational pages becoming available.

The dieWorld has been dropped, which may help performance a little bit. DT is now capped at .5, to prevent a physics bug when Love execution is paused. I've rearranged some GUI materials to make them more visually appealing and flexible. The procedural level function has been reassigned to f4/f5, and now positions itself according to the mouse. Players now respawn in Team mode, wellsprings don't crash the game, your team bucket can only hold 100 points at a time. I've done some (thus far fruitless) work on the camera code, anyone who wants to comment on it feel free.

As always, please let me know about bugs, I am doing my best to iron them all out.

[slime]

I envy your game's performance. I get 400+ FPS ingame in Kerosuke, and much less in most other löve games.
I think most of that has to do with your general lack of HUD text or particle systems. Both of those bring my FPS down pretty hard.

[tentus]

I envy your game's performance. I get 400+ FPS ingame in Kerosuke, and much less in most other löve games.
I think most of that has to do with your general lack of HUD text or particle systems. Both of those bring my FPS down pretty hard.

Thanks, I'm glad to hear that my performance obsession is working out. I actually forgot to mention, this version also moves the terrain, water, and ramp images from per-object to massive-table organization. This doesn't mean much on a small level, but on a truly massive level it can really help loading time and framerate, because it's not re-rendering identical images.

But yeah, not having particles or much text goes a long way towards keeping FPS up. Funny how seemingly small artistic decisions have such far-reaching consequences.

[tentus]

Version 110221 of Kurosuke is mostly under-the-hood, but the changes I've made are fairly sweeping, so I'm going to mention them anyhow. I've moved all the actors, sensors, projectiles, and geometry into a unified "ents" table. Ironically, testing this made me aware of pre-existing bugs, so now the baddies are a little easier to kill, and killing them with projectiles won't crash the game anymore. The boss AI is fixed.

I've moved object details out from each ent class into a handful of functions in the editor class, which will hopefully make the code easier to maintain, and should help performance a tiny bit. I've merged water and terrain image generation into a single function, to reduce code redundancy. This also forced me to get around to make special-case images for water.

I've started work on adding "barriers" into the game, which will be the precursors to doors (barriers have requirements, while doors will have individual keys). The tutorial level has been marginally improved, though I am loathe to work on it since I know I'll be replacing it outright at some point. (Maybe soon!)

Anybody got any feature requests? I'm starting to iron out my own personal list, so new ideas at this point would probably be a good idea.

[tentus]

Version 110225 is largely focused on control, with some emphasis on cleanup. Players can now bind axes on joypads to any control they want, and the pause button has also been made rebind-able. Rebinding now checks to see if the key in question is already in use before it commits the bind.

Some functions have been added to make the code less redundant, others have been combined. I had to add a joystick class to accomplish the above. Old settings files should probably be replaced, they run the risk of crashing the options menu.

Team has been broken into two gamemodes: Capture and Team Capture. Versus also has received a team version.

Lightning and bombs now cause camera shake, bombs do not cause the physics module to crash, lighting spawns in appropriate places. If you try to use a move before it is ready, your companion will flash red. When filling your bucket in capture, it will flash green when full.

As always, bug reports are appreciated, feature requests can't hurt either.

[slime]

(mega-bump) I noticed you don't seem to be using spritebatches for your level geometry. Is there any particular reason for this? They'd speed up the level drawing a ton, especially for more complex levels. You'd have to put your static sprites into a sprite sheet though. This tool seems to do the job pretty well: http://lukasz.dk/2011/04/18/texture-atlas-generator/

[tentus]

(mega-bump) I noticed you don't seem to be using spritebatches for your level geometry. Is there any particular reason for this? They'd speed up the level drawing a ton, especially for more complex levels. You'd have to put your static sprites into a sprite sheet though. This tool seems to do the job pretty well: http://lukasz.dk/2011/04/18/texture-atlas-generator/

Could you give me a link to an example of spritebatches being used in Love? If I can examine some working code I can probably get a good idea of how feasible/worthwhile it is.

[Lafolie]

We were discussing this on IRC earlier. They use some vertex thingy in OpenGl, which apparently speed up the drawing process. Basically, using a spritebatch means that if you've got one particular image drawn multiple times each tick (such as tiles in a tilesheet) then it's much faster to render them in one draw call using a spritebatch.

[tentus]

I should point out that if an object isn't onscreen in Kurosuke, it's not drawn at all. Also, right now each geometry "chunk" is compiled into a single image on level load, which can be rendered by any chunk of that size in a single call.