This is Bananattack.

Magical Mayonnaise

Posted by Overkill on September 10, 2008 at 1:49 am under Uncategorized

This week, while not extravagent, was a fairly good one. In Brockoly, I added in region-based grabbing for all the blit routines, in both software and hardware. So now this can be used to make powerful special drawing for sprites and tiles, and can still be combined with rotations and scaling and mutliple blend modes and texture tinting all that magic. So think of Verge’s GrabRegion on steroids.

I also started on the actual sprite system for Brockoly, but I’m trying not to rush it and screw something up. It shouldn’t be too tricky though, since I basically haven’t dramatically changed the sprite format layout since what Resonance does. So after that feature is in, something like a funky shmup game at the very least could be made.

I’m pretty excited. You should be too.

Tags: ,

No comments (make one!)

Strutting back into the spotlight.

Posted by Overkill on September 2, 2008 at 8:11 pm under Uncategorized

I’m pretty much over the first hurdle of lower-level stuff to add to Brockoly’s C++ codebase. Graphics are mostly there, in both hardware and software, just need the region-grabbing blitters before I get to sprites. Keyboard input controls are done. Timing (and handy support for builtin frame throttling) is in. Audio’s in. The executable so far is only about 300kb, so it’s pretty lightweight, but I expect that to rise sooner or later.

Started making work on the file formats. The format loader logic is in there (has a one-line header that specifies information on the format type, format version and format parser which is plugged in to generically load things).

One of the parsers already taken care of is an updated Mungo format, which now can handle auto-numbered keys for entries and lists easily, and a Verge format parser is being planned to allow for conversion. All parsers will convert the file format they loaded into a Brockoly::FormatTable which contains all the entries, and then this generic information table will then be poked at and inspected by the sprite loaders and map loaders (which need to be written), with clauses for how to handle version compatibility between the different table layouts builtin.

An exercise down the line is adding pluginable text encoders (like base64 or binary-to-hex) and binary compressors (like zlib or run length encoding) for when I actually store binary data in the format. I plan on for stuff like tilesets and spritesheets, to allow the formats to be stored outside the file, in case somebody ever wants to make the format file in just a text editor (which I know I will since I don’t always like using specialized editors for everything).

I’m about ready to embark on the more interesting design stuff. The actual implementation of my sprites system, and map and tileset system, and then a seamless world system on top of all that, are to be designed. They should be a fair amount of fun to do. I’m willing to hear suggestions for features that you notice a lot of 2D game engines miss out on! Oh, and of course, I’ll share the file format details with other engines that want to use the same stuff in their own engines.

Some of the planned features for sprites:

  • Frame padding details (for when you’re loading images from outside and want to decide how you’re laying the sprites out to some extent)
  • Custom frame width/height info (everyone has this by now — possibly with ability to guess frame size on sprites with a padding of at least 1.)
  • Custom animations
  • Custom hitboxes/hotspots for certain frames (so when crouching or diving or something, it’ll use a different hitbox than if you stand)
  • Special meta information (easily added when everything’s stored in tabular formats anyway)
  • Entities are higher level objects that contain sprites in them — entity construction information isn’t stored in the sprite. When Ruby is added to the build, the construction information will be stored at the map level, where it can actually tell the engine how to construct an entity. This way you could have “Enemy” and “Player” classes or a just or plain static sprite constructed, with a selection depending on how complex you really need the engine’s handling of it to be — and you could provide a chunk of metadata which it could then use to further improve the customizability in sprites through sharing information between maps and the code. (Whew!)

Planned for tilesets:

  • As with sprites, padding and frame size
  • Tile arrangements (“brushes”), which are specific placements of tiles (may be able to span multiple layers, too)
  • Custom animation scripting for tiles, which creates a special animated tile arrangement, which allows tiles to be reused across multiple animations (if you really need to — might be useful), and allows tiles to be specified in an ordering that doesn’t require the indexes in the tileset to be right beside each other (like it is in Verge — which is frustrating if you make bigger animated tiles)
  • Tile grouping (also groups arrangements), to allow certain categories of tiles to be found easier both by script generation and by editors
  • Special meta information (easily added when everything’s stored in tabular formats anyway)
  • Isometric or hexagonal tiles aren’t exactly on my TODO, but if someone else wanted to add them, I’d be happy to let them
  • Pixels should be readable from tilesets.
  • There’s no intention to make a special “obstruction” layer or obstruction group, and these are left up to specific implementations (like sidescrollers could use pixel based obstructions with color coding for the different kinds of floors , but another might want tile based obstructions). Rather than forcing one on the users, I want to leave this open to choice. There’s a few options that I plan on enabling, then they just need a particular implementation by a user elsewhere.

Planned for maps:

  • Tileset to use (possibly multiple tilesets at a later point — they’d all need to be the same tile size though)
  • Background music
  • Sprites on map, with a bunch of custom construction info (mentioned in sprite part actually), and metadata to share script-side. Sprites can be pixel placed instead of tile placed (with a toggle for snap to grid). Sprites can overlap on a map, too.
  • Tagging of map regions, so you can use this for pathfinding and scriptside spawning (for instance a key that spawns after you step on a button). Can be placed tilewise or pixelwise. You can look it up by a tag name to figure out its position, or look at a position to figure out what tag is associated with the location. You can overlap tags, if you so wish. Might have a variety of shapes, like lines, and rectangles (filled/non-filled), which can then be used for a bunch of different things, including custom obstruction systems?
  • Zones, for tagging map tile regions where a common functionality is shared (spikes that hurt you or locked doors that all say the same message or whatnot). Unlike the tagging, you only plot tilewise, and you can’t find the reverse lookup a zone’s position by its name, but this is because you can place the zones in any arbitrary tile arrangement. Zones may not overlap either. Fairly similar to tags, but unless I can find someway to merge them elegantly, they will be separate pieces of information. Zones have the benefit of being compressed as one chunk when placed because of the “no overlap” rule.
  • Many layers, which contain a tile grid, and a zone grid. Entities may be a member of any layer.
  • Region tags that have special meaning only at the “world” level, but allow a request to start seamlessly loading a connected map.
  • Other special meta information (easily added when everything’s stored in tabular formats anyway)

Planned for worlds:

  • A list of maps contained by this world.
  • Seamless loading of individual maps and their associated tilesets, and sprites.
  • A way denote direct, adjacent connection between maps (by a list of connections that tell to connect the edge of one map to the edge of the next)
  • The automatic generation of minimaps? (not sure)
  • A way to denote indirect connection between maps is already explained in the map section
  • A way for sprites to automatically cross between maps when by direct connection. And when not directly connected, the sprite must explicitly request to be moved to another area.
  • This format is actually quite undeveloped at the moment, I’ll figure it out more when the lower formats are implemented first.

As said before, your suggestions in regard to the engine are much appreciated, and I hope to be able to share this effort with other engines that want to share my format ideas.

So anyway, look out, Overkill’s still alive! Once these formats are relatively done and Ruby’s in, I can return to work on Resonance and then dance between the two projects. This is still hopeful. Lots of work, sure, but I can see the workload progressively getting smaller. Things are shaping up.

Tags: ,

1 comment