Ever since i've learned how to make games, i noticed that all i've ever done was make editors or tools to speed up development. In the end, making a tool instead of a game =/. I've made tools for frame-based sprite animating, skeletal animation, tile-maps, hardcoded-game-specific editors, more tile-map editors..., multiple cutscene editors ...etc.................. Im sure you get the point.

Anyways, i'm in the middle of making yet another editor. Its supposed to be a "general" level editor, with the main idea that its basically just a bunch of "plugins" used together. I did this to avoid making a hardcoded-game-specific level editor that can only be used for that one game. Through the plugins, one can make a "hardcoded" plugin for the editor if they wanted to, or a more general plugin and interpret the output data themselves in the game. In the game im currently working on, Enribeaver, that's what i did. I interpreted the output xml and "converted" all the sprites into renderable components, and shapes into collision polygons.

If people get interested and want to help, I'll post what i have of the editor. I'll have spend some time to re-code it so that its more organized and manageable as i didn't plan on others even seeing the code. Once i do that, and people are interested, ill upload the source code somewhere for everyone to use.


TL;DR : Is anyone interested with helping to make a general level editor for 2D games? Right now it uses c#/Xna (windows) but if anyone has a problem with that, i can use something else. I'm only using Xna because it's the only thing i have found that is easy to use for rendering. Im thinking of moving to c#/sfml so i don't limit myself to windows users.

This looks pretty interesting. Would it be tile-based, vector-based, or would that be changeable?

If I were to help I'd need it in AS3 but I don't really have the time anyway. I might check it out once you have a release though, if plugins aren't too difficult to make it might prove useful for me.

Well that the thing, what it does depends on what plugins you make for it. One plugin can be for tile-based sprites and another vector-based (If someone is willing to program that in...). The point is to have a program where all these plugins can cooperate together to make a larger and better tool.

The stuff i've made so far was a "Primitives Plugin" which just basically draws shapes (rectangles, circles, polygons, poly fans, beziers, and lines) which i mainly use for level collisions. I made a "Tile Mapster" which is just something that handles placing tile-based sprites. I made one more which was just something i could use to place sprites ( i also added saving/loading of sprite sources so i don't have to re-create them all the time).

To add game variables i might need, i added support for custom properties that can be created and changed with the main program.

Im still waiting for some people to get interested or else i'll just have to continue solo-ing the project.

I'm busy procrastinating working on a sprite animation tool so I'll need to pass. The tool sounds neat, though!

I'm probably gonna need to make my own tool for editing levels in the future though, depending

(01-24-2013, 09:25 PM)Phaze Wrote: I'm busy procrastinating working on a sprite animation tool so I'll need to pass. The tool sounds neat, though!

I have one that i already spent some time on. I'd like to give it to you but chances are it might be a bit confusing since i only really made it for me. I tried to give recolornerd a try at a skeletal animator editor (that i have to re-do all over) just a few mins ago and he was looost. To summarize, its not "cell-based", frames are source rectangles that can be rotated (not scaled tho) and have rectangles and circles for keypoints or collisions boxes.

Its like this:
Then there's the animationplayer that actually does the animating and drawing.

Phaze Wrote:I'm probably gonna need to make my own tool for editing levels in the future though, depending

Thats why i started making this. I was a bit tired of making these game-specific tools too.

(01-24-2013, 09:53 PM)TheShyGuy Wrote: Its like this:
-SNIP-

Thats why i started making this. I was a bit tired of making these game-specific tools too.

Funny, the tool I'm going to be making is general purpose and has a lot of features like your own, but it'll be based on individual parts/tiles assembled into their own frames. It will also have support for making separate 'transformation animations' that will be applied in a game implementing the formats. Stuff like rotation, skewing, color scaling.

It'll save to XML and will be able to export as GIF or a binary format I plan to use in Ridge's fangame. I still need to write up the draft for the binary format, though. I think it's best to wait until I have the program done first though, as it's likely I'll end up changing the XML spec partway.

Collisions aren't going to be a thing handled in the animator though, I plan to leave that in the engine in order to separate presentation from technical details.

About the level editor, it'll depend if your tool will easily support a top-down perspective, all sorts of fancy stuff on tiles/collision and either an explicit partitioning of area data (quadtree) or a quadtree friendly implementation that can easily be partitioned as such.

Being cross-platform is also a thing that is important for me, though I guess mono exists.

(01-25-2013, 01:14 AM)Phaze Wrote: Funny, the tool I'm going to be making is general purpose and has a lot of features like your own, but it'll be based on individual parts/tiles assembled into their own frames. It will also have support for making separate 'transformation animations' that will be applied in a game implementing the formats. Stuff like rotation, skewing, color scaling.

I had that idea a long time ago. But I figured it'd be easier to make a skeletal animation editor and engine to handle frame-based animation along with composited parts and key transformations.

Phaze Wrote:Collisions aren't going to be a thing handled in the animator though, I plan to leave that in the engine in order to separate presentation from technical details.

I think you miss understood me or im just a bit sleepy. My sprite animator doesn't do anything with collisions. I actually left that part, transforming the collisions, up to my entities' animatedCollision component. All it does is ensure that the collision polygons are correctly transformed with the entity and current frame without actually doing collisions.

Phaze Wrote:About the level editor, it'll depend if your tool will easily support a top-down perspective, all sorts of fancy stuff on tiles/collision and either an explicit partitioning of area data (quadtree) or a quadtree friendly implementation that can easily be partitioned as such.

Im not sure i understand what you're saying. A top-down perspective is created through game and art design. What's a level editor need a quadtree for? -placing a quadtree and setting a size? Then should it just be interpreted from the output from a rectangle and a special name or something. Unless you meant for optimal rendering, then i understand, but then it would have no real use to the output data. Im sorry, but im not really sure what you meant by any of that last part.

(01-25-2013, 02:18 AM)TheShyGuy Wrote: I had that idea a long time ago. But I figured it'd be easier to make a skeletal animation editor and engine to handle frame-based animation along with composited parts and key transformations.

I think you miss understood me or im just a bit sleepy. My sprite animator doesn't do anything with collisions. I actually left that part, transforming the collisions, up to my entities' animatedCollision component. All it does is ensure that the collision polygons are correctly transformed with the entity and current frame without actually doing collisions.

Im not sure i understand what you're saying. A top-down perspective is created through game and art design. What's a level editor need a quadtree for? -placing a quadtree and setting a size? Then should it just be interpreted from the output from a rectangle and a special name or something. Unless you meant for optimal rendering, then i understand, but then it would have no real use to the output data. Im sorry, but im not really sure what you meant by any of that last part.

Aren't skeletal animations a 3D thing though? Mine is strictly 2D.

I guess I misunderstood you!

Well yeah, but... eh, can't quite explain what I mean. It's probably just me being dumb, anyway.

Well yeah, a Quadtree would be used for rendering and collision detection efficiency. I meant is one easily parseable from the level data or what-not. I haven't really gotten into making an engine that uses such a thing as a way to optimize collision or what-not yet so I'm having trouble conceptualizing how it fits in with stuff currently. It's the next thing on my list, though so I'll be doing studying I suppose!

Skeletal animations are usually associated with 3D animation, but it is possible to rig up a 2D model with a bone structure. Most frequently, this is done on vector graphics. It works the same way as a 3D skeleton, essentially, but you bind separate parts to the skeleton, allowing you to move them relative to each other. It's an odd choice for anything other than vector graphics, though.

I don't find it that odd. There are a few good uses. To name a few, I imagined using skeletal animation in order to make level animations, menu transitions, or even large bosses.

--

A quadtree is basically one large area, or "rectangle", with smaller ones. So if you wanted to have a quadtree for an area of the map, all you really need to represent one is a large rectangle. I made mine heavily based on this. http://xboxforums.create.msdn.com/forums...spx#162992

Phaze, for the game you're making with Ridge, I don't think you'll even need a quadtree or much collision or rendering optimizations. Don't think about optimization until you really need it.

(01-26-2013, 12:06 PM)TheShyGuy Wrote: Phaze, for the game you're making with Ridge, I don't think you'll even need a quadtree or much collision or rendering optimizations. Don't think about optimization until you really need it.

I know I won't need much of any optimization for an M&L type game especially on the PC, but the thing is that I do want to do this sort of thing to learn. I'm not just making this fangame to help a friend of mine, it's a learning experience in game dev as I'd like to get into doing indie games if I at all can. I've done a number of things in the past but nothing like a full-fledged game -- well, I do have the core systems of a card game made but that's on hold pending a rewrite and the finishing of AKT.

Another thing is that I intend to cannibalize a part of the engine for game projects of my own, as what I have in mind would use the overworld part of things and do away with the separate battle screen. I really don't like the prospect of rewriting more core parts of a game engine for what I have in mind than I'd need to.

I am aware of the issue of premature optimization (not to mention the problems it causes...) but I consider this more of a design choice than anything as I haven't even begun to write code yet. I don't want to start writing code without thinking and then need to sloppily rewrite half of it because I'm an idiot.

Yeah thats how i felt when i first started out and still kinda do. But that shouldn't keep you from excluding the use of other engines altogether.

----

Im thinking of not using xna anymore for this or the game im working on. Mainly because it limits me to windows users which isn't gonna help me out to get other's interest. Im thinking of moving to sfml (most likely) which i believe is cross platform. It's still going to be in c# since i just started learning c++.

(01-28-2013, 01:37 PM)TheShyGuy Wrote: Im thinking of not using xna anymore for this or the game im working on. Mainly because it limits me to windows users which isn't gonna help me out to get other's interest. Im thinking of moving to sfml (most likely) which i believe is cross platform. It's still going to be in c# since i just started learning c++.

XNA is pretty neat but it does have that limitation. There are attempts to port the Common Language Runtime to Linux (see Monogame) but that naturally won't be as good as the original Windows implementation for some time as it has to be 'clean-room' reverse-engineered.

SFML does seem to work very well from what little I messed with it and the license is certainly great

a good alternative is java, its easy to use especially if your versed in C# and its very broad in compatibility.
It can handle most of the things XNA handles so it shouldn't be much different.

(01-28-2013, 09:31 PM)Bombshell93 Wrote: a good alternative is java, its easy to use especially if your versed in C# and its very broad in compatibility.
It can handle most of the things XNA handles so it shouldn't be much different.

While Java does work and is fairly similar to C#, I'd honestly recommend avoiding it unless you really don't feel ready for what C++ brings to the table.

Oracle's track record with Java security leaves something to be desired and this could have some consequences for programs developed in Java - lesser adoption/use for one. It's enough to make me consider porting Mask to C++ when I resume development on it in the future.