So, I've finally reached the point where my FlashPunk tinkering may be of interest/use to others!
KlikPunk is a tool for quickly composing "scenes" for games. You simply drag graphics from the bin at the left to the stage in the middle, arrange them as you please, and click the save icon to store a friendly XML file, ready for importing directly into your game.
To ease the process of creation, the bin full of graphics at the left-hand side of the screen is constantly updated with whatever you have dumped into the directory (and subdirectories) where the scene is to be saved. No irritating import step! Just save your graphics and use 'em.
If you're interested in using this, feel free to let me know what other features you might like to see. Custom properties I think are next on my list, so you could specify, eg, how things move, if they should collide, etc.
Controls:
Tab - show/hide overlays
PgUp / PgDn - move selected graphic forward / back
Arrow keys - nudge selected graphic 1 pixel
Scroll wheel - scroll sidebar bin / zoom in or out
It's an Adobe AIR app, so you may need to grab the AIR runtime to install and run it.
Attachment | Size |
---|---|
KlikPunk.air | 238.99 KB |
KlikPunk_src.zip | 134.29 KB |
Comments
Neat! I only spent a
Neat!
I only spent a moment with it, though. Will try again after (or possibly at) the Global Game Jam. I did think it was broken at first because somehow I stupidly skipped the step where I put images next to where I am saving the xml.
Already I think I would want to add scaling, rotating, and adding some kind of metadata to things.
It probably wouldn't hurt to
It probably wouldn't hurt to put in some kind of message telling you where to start dumping graphics to use; good catch there.
I'm kind of waffling about how I'm going to add metadata support; I think maybe for a first cut I'll just have the loader hang on to any custom attributes you may have manually added to the XML, and preserve them when you save. Adding a custom UI in the editor seems like it would be a lot of work for something that wouldn't actually be much more efficient to use than that. The tool is really about being able to eyeball stuff in a way that you can't really do with text, rather than trying to be a full-fledged game development environment.
Anyway, I'm probably going to throw the source code up on GitHub at some point, if you're interested in helping add any of those features you mentioned. :)
Actually, something that
Actually, something that might end up being really nice that currently isn't in there is file monitoring; where if you save a new version of an image, it updates on your screen right away.
I haven't tried this yet,
I haven't tried this yet, and obviously it seems like something you just recently pieced together, but some usability concerns that are evident from viewing the screenshot:
- All the object icons on the left should be 1:1 in aspect ratio. Some items are shorter in height than others, causing some icons to have greater visual precedence over others, generally killing any sense of uniformity.
- Where are the edges of the playfield? Or are they covered up by the backdrop?
- There's the issue with the same folder icon being used for all the subfolders, and the only way to differentiate them is from the giant text label that intrudes on the level view. Suggestion: Make the labels only appear when moused over, and have the program initially peek inside the folder to generate thumbnails of a few sprites, and display them on top of the folder icon. This will unobtrusively differentiate those folders.
Edit: I'd love to see some sort of standardized XML format coming out of this. I'd like to construct an editor/runtime using the same format and working using cross-platform C++/OpenGL.
- Yeah, alright, I'll force
- Yeah, alright, I'll force a max size rather than just a max width.
- Deciding on the size of a playfield is like my most hated thing to do in, say, Construct. I don't know how big my game is yet, I'm still drawing it! Let me be! So therefore I decided on INFINITE PLAYFIELDS! FUCK YOUR EDGES! (Although knowing where 0,0 is wouldn't be a bad thing.)
- In practice, the folder names are all at the top and scroll off the screen once you start looking at graphics, and anyway the entire UI can disappear entirely with a touch of the tab key if you just want to look at only your handiwork. But that's not a bad idea, and fits in kind of nicely with my thoughts about animations (that they should be represented as folders full of graphics).
Currently the XML looks like this:
The tokens are listed in Z-order.
Probably it will end up looking a little more like this:
Decided to make a scene to
Decided to make a scene to test the XML it spits out so I can create a runtime that reads it in.
Right now using it feels like playing with those sticker boards designed for children.