A short, simple task: make it so the camera doesn't travel outside of the bounds of the section. I'm not going to miss that ugly grey color of the void.
Tuesday, November 27, 2012
Monday, November 26, 2012
Okay, here's a short video of tiles and entities being animated. The lights are tiles. The stuff at the bottom of the section are entities. As shown, any animation can be used on entities (entities are objects that can be freely rotated, positioned, and scaled). Even things that don't really make any sense, like player animation, as you can see in the video. I'm starting to get the craving to find some real art.
Saturday, November 24, 2012
Just a few minor updates.
- Made a more useful display (seen in big ugly, but convenient, red text) on the texture editor. Shows the size of the current selection (or proposed selection if you're highlighting an area0.
- Made animation speed configurable. I'm betting this will get more complex in the future (i.e. individual frames that take longer than others), but for now a flat animation speed will suffice. Editor seen below--here you can see I've set the sword speed to '4'. Any positive floating point number is valid.
- Added the rest of the basic sword swinging animations (left, right, up) in addition to the one shown before. Although this isn't particularly interesting work from a development perspective, doing this kind of stuff highlights inefficiencies in the process, so I can fix those for a (hopefully) future artist who will use the tools. Quick video of the animations:
Alright, now I'm set to implement what I said I would last time: animations on tiles and sprites.
Thursday, November 22, 2012
Here's a problem that surfaced as soon as I tried to animate something remotely interesting--namely, the character swinging a sword. Check out this video which illustrates the problem:
The problem here is that the animation frames for the character standing and moving are something like 16x22 pixels. The frames for the sword swinging are larger--and every frame is a different size since the sword extends in an arc. However, animation and player models are decoupled--no matter what the character's doing, it's defined in in-game units as 32x44 (the fact that it's double the pixel size is arbitrary; the same problem would occur, and be solved by my solution, if the player was 50x50). So, what you're seeing is a larger image being jammed into that 32x44 box, which looks messed up.
The solution was to add metadata to each texture to define a 'model-box', or model-relative coordinates, to 'anchor' that sprite such that the in-game model will fit into that area. Here's a quick video of me lazily setting up a few of these boxes. Some of them are probably off by a pixel, but whatever.
The blue boxes, therefore, represent the entire graphical image that will be displayed. The yellow box corresponds to the model. And here's what we get when we run the game again with the updated data:
Also added and not shown (because it's just code): basic logic to handle switching between player states from an input processing perspective. That is, different states allow the user to process different combinations of commands--you can move, change direction, and start swinging your sword while you're walking around, but not while your sword is swinging. But you can pause the game (once I implement that) during just about any state. Right now there's only two (basic) states (swinging and not swinging), so it's implemented with an if/else block, but I can see each player processing state being its own class in the future.
Next up: Configuring tiles and sprites to reference animation data rather than just texture data.
Tuesday, November 20, 2012
I had a really basic 'Texture Editor' program which allowed me to manage the textures used by the game. However, the need for something a little more sophisticated emerged after a few requirements. First of all, selecting source texture coodinates by typing in pixels is extremely tedious. Here's a shot of the new utility:
On the left is a tree of 'assets'--so far just Textures and Animations. Selecting a node in the tree brings up the editor for that node. In the above screenshot, I've selected a texture. From the editor, I can then draw a box around the part of the image I want to use to set the texture coordinates. I don't know if the final game will make use of sprite sheets (texture atlases, whatever) or not, but it certainly makes development with temporary graphics a little bit faster. I can also change the source image and title from the editor.
Worth noting is the folder structure on the left. This is purely a development construct--folder data most likely won't be used in-game. But it will definitely be used in the editor build the dynamic fly-out menus to help find certain textures more quickly, and it's useful in the asset management tool too as a way to keep things organized.
Here's a shot of the animation editor:
The image preview actually animates so you can see what you're building, not that you can tell from a screenshot. The list box of frames is populated simply by dragging nodes from the tree into the box. Unlike textures (which are referenced by id), the names of animations are important, as that's how they're set by code.
In addition to the editors above, this asset utility allows the creation and deletion of folders, textures, and animations. You can also rename folders and drag items between folders. Changes are saved explicitly by clicking the save button.
And, for something a bit more interesting, here's a short video of the character running around using 4 simply animations.
Oh, I also hooked up a gamepad (some old Logitech rumblepad) and wrote the code to parse input. Even controlling a character that can't do anything but move around yet is more fun when you're holding a proper controller.