[Discuss] An editor for video game development

#1

Carrying on the discussion from my previous topic, I am considering making a video game development environment that is designed for visual design of video games, written with Haxe and the ability compile to multiple targets. The initial idea was to contribute to the FlashDevelop project, but gave up on that quickly.

What I’ve been wanting to do is make a visual environment similar to Unity, but open source and free, with integrated code editing and debugging tools, a more complete GUI toolkit for game development as well as catered for the web and desktop. It would be a challenging and an ambitious project, but I like challenges - it is what keeps me interested in programming.

The other idea was to develop a game within an actual game, being able to test and develop simultaneously. One idea would be to develop a GUI application in C++ (given I know what I am doing, which I don’t when it comes to that language) that interfaces directly with OpenGL, you would be able to develop video games in Haxe, but it be compiled (almost on-the-fly) into C++ on your editing platform and the visual designing be potentially smoother that way.

The other (and more suited to my skills) alternative is to develop an application in C# using the .NET framework, and with the power of GDI+ use a Haxe library to translate what you see on the canvas of a C# application into a Haxe/OpenFL video game. The only problem with that is that GDI+ is slow, and would only be useful in actually designing the interfaces, not by also testing the game. I do like using GDI+ but it is troublesome to use.

The other alternative would be to use OpenGL directly using either SDL.net or other OpenGL wrappers for C#. At that point, though, you might as well create a game in C# and not Haxe, so that idea is pretty much useless for most people here.

I did have the idea of creating an OpenFL backend, using an editor in C# that would compile C# code into whichever language is required using the Haxe Toolkit, but that idea is pretty much out the window.

There are options and ways to go about creating a free and open source editor with the main focus on drag-and-drop and auto-generated coding capabilities (my original plan ever since I picked up on OpenFL and Haxe, since it seemed so simple but lacked any decent editors - sorry FlashDevelop and the others), and I am so fixated on making a visual editor similar to Visual Studio but for game development. Since such an editor barely exists, I wanted to of course create one, but I am slowly running out of options that would both perform and be practical, that would work well with Haxe and OpenFL.

Any further ideas people would like to contribute to this discussion?

2 Likes
#2

There have been a few efforts in the direction of a Haxe based version of Unity. Check these out:

Unity3D-haxe

Reach3DX

BlendHX

In case you’re wondering how I came across these, there’s a wonderful site that showcases the latest and greatest things going on in the world of Haxe Development…haxe.io

Personally I am not a fan of Unity’s ECS(Entity component system) implementation and sadly the aforementioned tools tend to follow Unity’s lead in that regard.

What I’d like to see is a Game Editor on par with Unity that leverages a more pure Entity-Component-System. My preference as far as ECS architectures go is Richard Lord’s Ash Framework. It would be awesome if a Unity-like editor was built with Ash at its core.

#3

The Ash Framework does look very promising. I will definitely take a look into that later on I think. Thank you for all the links, btw! Very useful.

#4

For Haxe is available 2 ports - https://github.com/Rahazan/hx-ash and https://github.com/nadako/Ash-HaXe .

#5

I’ve been using Nadako’s port of Ash for a while now. But I wasn’t aware of hx-Ash. Thanks for the info!

#6

Agreed. As far as I’m concerned, Ash does it right, and anything less is missing the point.

Same here.

And it looks like hx-Ash supports optional components! (Every time I work in Ash-Haxe, I wish it had that feature.)

#7

In regards to the visual editor, there’s a project going for Snow to do a visual editor. I’ve also worked on one.

Now with the custom platform SDK, it is possible to extend Flash CC with custom exports and frame script languages. That’s one avenue for an editor. Otherwise, I would recommend doing a native shell (like C# for the window and dialog boxes) but running an OpenFL instance (could be a WebView, and promote to something more native later) inside. This helps make it cross-platform and keep the code in Haxe.

If you did something in C# and wanted a code editor, I would maybe recommend considering making the editor work as a plugin to FlashDevelop (perhaps in addition to standalone) as that could allow standard coding side-by-side with the visual component, without reinventing the wheel

1 Like
#8

I’m interested in creating an entity system with some variations from the one propose by Ash creator. Maybe I miss the point but I don’t like that entities are added automatically to systems once they get matching properties.

For example lets say that you have a system call Motion that controls the physics of the object with some properties like Position, Velocity, or maybe you have them inside a single prop. Now imagine that you want to create a system that kills objects once they are out of the screen, you only need the position for that system. So all entities that have positions will be added the system that kills them if they get out of screen. You can add another property like OutOfScreenDeath just to add another condition to the system, but to me thats adds a lot of noise.

I started testing a simpler solution, where you just add and remove the entities from the systems. It’s much simpler to implement than ash because you don’t need the auto functionality(the original uses Reflect, and that can be slow).

I was thinking about adding the concept of “states”. States define what properties should be added/removed and to which systems you should added/removed them. So you define a state InsideAVehicle and the state adds and remove stuff. Some properties you don’t want to destroy, because maybe you’ll need them with those values, but you don’t want a system acting on them, so you just remove the entity from the system.

All of this is still super experimental, here a test using this idea with flixel. You can grab 2 different weapons(small red cubes) pressing down, and shoot with D (only one weapon at a time) you have a quadcopter the little white block, you grab it by pressing down, and you can fly it by pressing D, and stop flying it using D. Then you have a tank and a space ship(green and pink) you enter them pressing space and leave them pressing space. drive them with the key board. Yes you need to use your imagination :smile:

After I’m happy with the API I was planing on releasing it on github. Then create some in game editor that had some control over the entities and could create them using pre existing stuff(properties,systems,states). I don’t like that Unity mixes the roles of people, and adds a lot of noise to all the different roles with stuff that they shouldn’t care.

Interesting discussion

#9

You might want to take a look at this, he does some pretty cool stuff where you can preview your changes live and see how they compare with previous game settings:

1 Like
#10

What about http://gamestudiohx.com/ ?? that seems pretty good and unity like

1 Like
#11

Not that much. At worst, it’s one extra “flag” component per system.

Ideally, though, you’d prefer to avoid making components that are only used as flags. You’d want to set it up so that each component stores relevant information.

In this case, the obvious choice is to store the condition for removal. Name the class “Boundaries,” name the system “OutOfBoundsSystem,” and now you can define custom boundaries for each object.

You can reuse components, so the most common case wouldn’t require lots of extra memory. Just make a static screenBoundaries object, and add that one to all the entities that have to stay onscreen.

I once took a course in programming languages, and two of the languages covered were Scheme and Prolog.

Both of these languages allow imperative programming, but we were explicitly forbidden to use it. And it turned out, learning the “new” way was both fun and educational. I haven’t found much use for the languages themselves (I’ve only used Scheme for GIMP scripts), but it was still worth learning the new way to think about programming.

When I first encountered Ash, I treated it in a similar way. I tried to do everything their way, and it turns out that for the right sort of project, Ash makes things work really smoothly. (Especially the part where entities are added automatically.)

You can change Ash to be more like what you’re used to, and your use of the word “simpler” indicates that’s what you’re doing. But that seems like a C programmer who learns an OOP language, only to avoid using objects. It’s not as bad as that, but it is missing the point.

#12

I do like working in C#, and do prefer using C# specifically for designing forms as Visual Studio is by far the fastest in developing desktop applications. Now that the .NET Framework is open sourcing, when WinForms is compilable to Linux and Mac, that makes .NET a cross-platform framework that would make particularly my life a lot easier.

That looks pretty damn cool. Having a system similar to this in Haxe/OpenFL would be amazing. I was thinking of doing a similar system with my own editor, but at the moment I am stuck at a dead end as I am not sure where I am going with my editor, if I even continue building it.

One thing I am considering is making data-oriented programming a thing with Haxe and OpenFL. You could use JSON to design interfaces, and objects that can be used within the game. I was thinking of making a Haxe library for it… Take a potential example:

{
    "TextField": {
        "instanceName": "myTextField",
        "x": 25,
        "y": 50,
        "text": "Here is some text",
        "defaultTextFormat": {
            "name": "OpenSans",
            "size": 12
        }
    }
}

In your code, you would load your library (having built the interface using some kind of scene editor), and the library would build and commit all drawing routines, with the code looking something like this:

public function new() {
    var lib:SceneLoader = JsonLoader(JsonType.SCENE, "path/to/jsonfile");
    var myTextField:TextField = lib.getControl("myTextField", TextField);
    //Do whatever with myTextField.
}

Obviously I’m just throwing ideas out here, but it’s been something I have been speculating for a while now without making any commitments to it. Is this something you would like to see?

#13

Something you might find interesting is Duality, a Unity-like editor for C# 2D projects.

#14

I’ve long thought it would be nice to have generic scene graph format (probably in JSON)

You could use one of the following:

var layout = Assets.getLayout ("mylayout");

or

var clip = Assets.getMovieClip ("mylayout");

The idea is that you could instantiate it if you just want it to look the same, or you could get the meta-data for the layout, and instantiate things yourself (like if you were using it in a special game engine)

#15

@player_03 thank you for taking the time to answer. I do like Ash but I just think that the auto add feature is a double edged sword. Is nice not having to add each entity to each system, it saves you a lot of useless code, but the risk of unintentionally adding an entity to a system is big. It really depends on how specific the properties are and how many systems you have, if you just have a few systems is not a big deal.

Adding by hand the entities to the systems adds a lot of other troubles too, but I would like to think of them like opportunities to improve. I was thinking about creating definitions that sets properties and systems to an entity, and you could create entities with the combinations of this definitions. This would improve the amount of manual work, and can make you work at a higher level. I know it more OOP but I don’t think that’s bad, just trying to bring some of the good stuff about OOP.

#16

If you design your systems well, that shouldn’t happen. Each system should use a combination of components that obviously ought to interact in the way that the system makes them interact.

So instead of having the “out of bounds cleanup” system look at position and nothing else, you make it look at position+boundaries. If something has a “boundaries” component, it obviously shouldn’t go outside.

An example that I ran into recently: I wanted to make the player character pick up coins, but not any of the other things with a hitbox. What I did was make a “value” component, and then I set up a system for picking up entities with value. As a bonus, making “value” components meant I was already prepared for the next step - adding to the player’s cash. That sort of thing actually happens quite often when you put some thought into your components.

Yes there are drawbacks, but you can avoid them if you work at it. In a way, you could think of Ash as teaching good object design.

Seriously, give Ash a chance as-is.

#17

Alright, I’ll give it another try now in haxe

#18

there has been a text ditor/ide that was inspired by that talk, called light table. really nice, though i myself have not found something to use it in