Play with my Sprite Editor/Menu Editor!! (w/ screenshots)

Started by
4 comments, last by MasterWorks 18 years, 6 months ago
Guys, Thanks to a bunch of you, I've got a pretty solid sprite engine that I think a lot of people would enjoy playing with. I'm not going to get into ALL the details, but it's a VB6 designed system that runs with DX8. You can download the demo (it's 9MB or so because I included my graphics/sprites/sounds for you to mess around with) here: MasterWorks Sprite Editor, Menu Editor, and Collection Editor Download I use the Sprite Editor to save .spr (sprite) files, which contain information as to the actual graphics texture file and how to display it. The powerful part is that each .spr file can contain multiple 'profiles', which are descriptions of how to use the graphics. Each profile can be totally independent, or they can link to each other, etc. For instance, if you have a 'button' sprite, you might have one profile for a big, full size button and another profile that's a small, translucent, rotated button (but both are drawn using the same texture resource). On this example you can see the profiles for the asteroid sprite on the left, and you can edit the sprite with the sliders, etc. on the right: To build menus I use the Menu Editor. The Menu Editor is a tool that basically allows me to place sprites on the screen at specific locations (called Menu Elements, which are just sprites with some extra properties like transitions), as well as add text and sounds and other interface elements. The Menu Editor allows you to edit an entire menu system at once. Here's a screen shot of me editing the music on/off 'checkBox' on my 'Options' menu. To use the Menu Editor you have to load a GAME FILE first (the Collection Editor, included but no screen shot, is used to assemble a game file). The GAME file is just a list of all the resources that the game uses (sprites, sounds, music, menus). After you load the game file you can open up the actual MENU file. I've included the .menu files (and a lot of other stuff) from my game Impact that uses this engine, so you might enjoy opening it up and poking around. I'm leaving a WHOLE LOT of stuff out, the Sprite and Menu editors have a lot of features, please don't hesitate to ask if you want more details on how it works. I've had a blast putting this together, I hope it works ok for you guys (you'll need the stardard VB runtimes but nothing else, I don't believe) and hopefully somebody will enjoy it! There's been lot of questions here lately about textured quads/dynamic VBs/menus/GUIs... there's a lot of time and effort behind this whole system so if you're new to DX I recommend you check this out, I think it's a good illustration of a (nearly) complete 2D engine using D3D. -Jay MasterWorks Software jay@planetflux.com [Edited by - MasterWorks on October 24, 2005 7:05:13 AM]
Advertisement
Nice work!. Plenty of features it has!.

Some comments:
1.The interface should be easier to use.

2.Can you let the user defines their own sprite format ?. If this is implemented, it will be a huge advantage: users can configure the program to suit their needs without changing their existing game source code, that is definitely worth to think of!. Of course, for customized format, the sprite can have less or equal functionalities with your original fully functional sprite format, but it should have because not all functions of your sprite format other users will need.
--> The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones <--
Quote:Original post by Skeleton_V@T
Nice work!. Plenty of features it has!.

Some comments:
1.The interface should be easier to use.

2.Can you let the user defines their own sprite format ?. If this is implemented, it will be a huge advantage: users can configure the program to suit their needs without changing their existing game source code, that is definitely worth to think of!. Of course, for customized format, the sprite can have less or equal functionalities with your original fully functional sprite format, but it should have because not all functions of your sprite format other users will need.


The interface works reasonably well for the Sprite Editor (the Menu Editor is newer and less refined in some ways) but this was never intended to be sold or even used by other people. The number of people making 2-D based games with Visual Basic 6 and Direct3D8 is underwhelming. Still, after having worked on a project for 2 years with these tools, I can definitely say I need some sort of grouping functionality so I can drag and drop groups of controls on the menus, and other such things.

It's all pretty specialized so there wouldn't be any point for having customized formats. You wouldn't get any use out of any of this without the accompanying source code classes. The point is that I can tell my game engine to make a new sprite "asteroid" with profile "damage flash" anywhere in code and the rest is taken care of. Or I can add animated sprites and such to menus without writing any code. I make a lot of modifications to the game just by saving sprite files/menu files instead of recompiling. All the sprite features rely heavily on one another, plus in terms of memory the different profiles just store a bunch of parameters (that are tedious for programmers to enter in manually over and over and over) and don't take up significant space compared to the actual textures (which are of course stored once).

I would imagine that the parameters/info that I save for each sprite is probably going to be radically different from what the typical programmer needs. But if you are thinking of designing your own sprite editor, you might consider including some of the features I did. Many were born out of necessity in the middle of the project. Some examples:

-the profile system
-the termination system, where a sprite "terminates" itself at a certain point (when it fades out, when its animation is complete, when it's done rotating, when a timer goes off, whatever)
-the profile CHAIN system, which allows one profile to link to another profile when it finishes (terminates). This allows you to make a quite powerful scripting system, for instance your character could zoom up, spin around 412 degrees, stop spinning, get smaller, fade out, etc... all in sequence. With no code.
-2 sliders for every value, where the engine chooses a random value between them at run time. So you can make a sprite that starts at between 50-90% transparency, and fades down to 10-25% transparency (randomly). Same with rotation, color, animation, size/scale, etc. This is great for particle systems.
-of course normal/additive blend
-single texture animation, aka sprite sheets (uses texture coordinates to locate the next frame of animation, starting left to right, top to bottom)
-the effects modes (rotateUp, rotateDown, etc.) which would allow you to make a sprite that has a high rate of rotation but stops rotating when it reaches a certain point
-the number of MIP levels that you want D3D to create

Saving parameters like these into a file and then using an editor to adjust them all is WAY more fun than doing it the hard way!

One other thing I was going to mention, for particle systems: if you have a bunch of profiles and some of them share a name, then at run-time the engine randomly chooses one of them. So you could make 5 or 10 profiles called "debris particle" or something, and some of them behave differently then others. That way you can add variety without adding code. In fact, you can pack more or less unrelated graphics together onto one "sprite sheet" (usually .PNG for me) and then create indepedent profiles for them. The mouse cursor sprite is one example.
Yeah, I reviewed the Menu Editor, it's an impressive work and requires a lot of designing your projects to have the same paradigm one after one. I think most commercial games these days (or professional developers ?) developed their own formats carefully at the start and keep it up after projects. Are you working on the game named 'Impact' ?, I remembered seeing this somewhere (maybe GDShowcase).
Hmmm, perhaps I shouldn't build my own sprite editor (or some kind of customized formats) until my project is large enough (Up until now I just made 4 or 5 small games of side scrolling and breakout type (result of several months learning DirectX), thing is still going smoothly, programming is great!!! :). Keep up the good work man, thanks!.
--> The great thing about Object Oriented code is that it can make small, simple problems look like large, complex ones <--
Good luck, I definitely recommend building tools to help you out once you think you need them. If you're doing the same things over and over or doing too much hard coding, you can probably benefit from investing some time in your tools. You are absolutely right about it being difficult to plan things over more than one project, I hope to get at least 3 and hopefully more games out of the engine.

This topic is closed to new replies.

Advertisement