Z# Game Editor - Porting ZGE to C#

[Petya2164]

Hi everyone!
This is my first post on this forum, and I'm going to start out with a big announcement!
A few weeks ago I stumbled upon ZGE, and I have to tell you guys, it is the best game editor I have ever seen It is very intuitive to use, and it makes game development quite easy. So naturally I wanted to add a few features to the engine, and I was rather disappointed that it only compiles in Delphi XE2. I gave it a shot in Lazarus, but I concluded that a Lazarus port would be pointless. Delphi and Pascal were so great in the past, but now this technology is considered outdated by a lot of programmers.
In my opinion, an open-source project cannot really be open-source if it only compiles in a commercial IDE Therefore I decided to convert the project to a modern and popular language: C#. During the past few weeks, I have converted about half of the core ZGE components and I have put together a decent-looking editor. You can check out the project on github:
https://github.com/petya2164/ZsharpGameEditor

Currently, you can compile the code with the totally free and open-source SharpDevelop 3.2 or 4.2, and you can also use Visual Studio 2008 or 2010 (the Express edition is free) if you like. The project targets the .NET Framework 3.5 SP1. That's your only dependency.
To be perfectly honest, I did not want to do a "faithful" conversion of all the Delphi code, but I used a lot of it. I have also added new features such as SceneGraph management (inspired by Unity and UDK), heightmaps for mesh generation and mouse picking. The idea is to make the editor and the engine suitable for more complex games. C# makes this a lot easier, for example: scripts can be written in real C# and even the users can add new components dynamically (a component is just a C# source file). But keep in mind that everything is compiled (it is not "conventional" scripting) and the .NET framework delivers near-native performance.
The editor is not really usable at the moment (no drag&drop features) as a lot of components are missing, but it still shows its potential, and it is rapidly improving

I started this project for fun (besides writing my PhD thesis) and I think that it has reached a point where it could benefit from contributions by other great programmers! Currently, we are a team of two: my best friend and me. The possibilities are endless, and we believe that the world needs a totally free and open-source game editor/engine to which anybody can contribute with free tools. The ultimate goal is to make the game development experience easier than ever before!!!
We would be really interested in your opinion and if you have any questions or suggestions we are looking forward to your feedback! And if you want to contribute, you are more than welcome to do so!
In particular, if you are developing on Linux or on Mac OS X, then you could try to compile the project with Mono and MonoDevelop. We've only tested it on Windows

[Kjell]

Hi Petya2164,

Very cool! Already found out about your project yesterday

So naturally I wanted to add a few features to the engine, and I was rather disappointed that it only compiles in Delphi XE2. In my opinion, an open-source project cannot really be open-source if it only compiles in a commercial IDE

I agree .. the Editor should have been build in Lazarus instead ( the engine actually can be compiled using FreePascal, but the Editor can't ).

I started this project for fun (besides writing my PhD thesis) and I think that it has reached a point where it could benefit from contributions by other great programmers!

Even though I'm not a programmer ( by trait ), I do have allot of ideas of how ZGameEditor could be improved. For example a couple of years ago I proposed some changes to the Editor in this thread. Not sure if you're open for primarily design ( opposed to development ) help though.

K

[Petya2164]

Hi Kjell,

Already found out about your project yesterday

I am glad that you already found out about the project. It seems that GitHub is a very good place for publicity

I have just browsed through the linked thread and I really like your mock-ups. I have to tell you that we are on the same page. In particular, we have very similar ideas about adding components to the project tree and about the online repository for components. I would like to implement these features soon. If someone creates a new component, then they should be able to easily share it with everyone. A good component might also be adopted into the standard component library. We definitely don't want to reinvent the wheel every time we make a game

Usability is a prime concern for us, so any design ideas are most welcome!
We tend to concentrate too much on the coding side, so having a different perspective is always great!

- Peter

[VilleK]

Hi Peter, and welcome to this forums!

First of all let me argue with you a little

Delphi and Pascal were so great in the past, but now this technology is considered outdated by a lot of programmers.

It's not outdated, it's just not as popular as it once were. Delphi has been in constant development with new versions appearing every other year since 1995. The XE3 version was released this year and since the XE2 release the Delphi compiler supports Win32 and 64 bit + OSX target compilation, and it also got good support for generics.

I'm a fan of C# too (the syntax of ZGE scripting is a subset of C#) but it is not native so it plays in another league. Apart from Delphi the only (almost) other option for native development is C++, which features improved code optimization and more advanced language features, but in my opinion is less productive because it is harder to use.

I agree with you that it is a shame that Delphi is not free. Embarcadero that owns Delphi should benefit a lot from releasing a limited free version, that would earn them lots of new (younger) users.

Your project looks very interesting! You seem to have understood the ZGE class hiearchy well and make good use C# features which makes the source very compact and readable. Letting the users script in C# and dynamically compile this is a good idea too.

I will follow this project with interest. And I'll be happy to answer any questions you may have considering the ZGE sources are not documented and some comments are in Swedish . I've done lots of C# coding so I may be able to help a little bit with coding too when time permits.

Usability is a prime concern for us, so any design ideas are most welcome!

That is great because I'm much more a engine programmer and user interface features tends to always get less priority from me. That's the main reason ZGE is still difficult to use and has a steep learning curve. Kjells interface ideas are great and if you can work together then I'm sure it will end up really good!

[Petya2164]

Hi Ville,

Thank you for your encouraging words and I also like a good argument!
Don't get me wrong, I also love Delphi and ObjectPascal (that's my mother tongue in programming ), and until around 2004 it was the most productive IDE. And the Delphi compiler is still pretty fast and efficient, considering that it generates native code. But I believe that Anders Hejlsberg has really surpassed his previous creation, Delphi/ObjectPascal with .NET/C# in terms of productivity. And that is the root cause for its propularity.

I have also considered the other native option, C++ (I was always a big fan of Qt), and I totally agree with you that it would be counter-productive to deal with all the unnecessary difficulties of that language. However, the .NET JIT compiler generates reasonably efficient native code, so C# is not that slow. Moreover, it is likely that the framerates in a well-designed 3D app will be GPU-bound, as opposed to CPU-bound. And if it turns out that C# is the performance bottleneck then we can consider using Ahead of Time compilation (http://www.mono-project.com/AOT). I am also thinking about generating Vala code (https://live.gnome.org/Vala/Tutorial) from the editor which is very similar to C# but it translates to C and ultimately compiles to a native binary.

I am glad to hear that you like the project and its codebase! I have to admit that the code is all messed up now, and I have very little comments The ones I have are mostly translations of your Swedish comments (those were actually really helpful for me, since I understand some Danish and Norwegian).

I would be delighted if you could help with the C# coding! Your knowledge and experience regarding ZGE are just invaluable! We can coordinate our efforts here and on github. We are already talking with Kjell about some of his ideas, and I will do my best to incorporate those into the project. Hopefully we will end up with a very convenient editor!

Regards,
Peter

[darkhog]

When you are on this - I'd like you to use MonoDevelop, so we can use both Z# IDE and games on Linux/Mac too (it's bad Mincrosoft doesn't release official .NET Framework for other systems, since it was supposed to be multiplatform, just like Java).

Also if you want, I'd like to contact you about some things I was about to do in my fork for which I currently don't have time for - mostly "idea guy" thingy, but my ideas usually are well-thought so you may benefit from them.

[Petya2164]

Hi darkhog,

When you are on this - I'd like you to use MonoDevelop, so we can use both Z# IDE and games on Linux/Mac too (it's bad Mincrosoft doesn't release official .NET Framework for other systems, since it was supposed to be multiplatform, just like Java).

Absolutely, adding support for Mono should be a top priority. I have a positive experience with Mono and MonoDevelop on Linux, but I am working on Windows now. So if you are actively developing on Linux/Mac, then your assistance would be much appreciated. I can set up a MonoDevelop project to get you started

Also if you want, I'd like to contact you about some things I was about to do in my fork for which I currently don't have time for - mostly "idea guy" thingy, but my ideas usually are well-thought so you may benefit from them.

Please feel free to contact me here (in pm or we might need a thread for ideas so that others could weigh in). If you have great ideas I would certainly like to hear them!

[VilleK]

I agree that the C#/Visual Studio combo is more productive than Delphi. But since C# is not native they cannot really be compared .

Because Delphi is native it can be used as a system language so in theory you could write operating system and drivers with it. You can also embed assembly to allow advanced features such as the ZGE implementation of native calls to external dll's. And thanks to Freepascal porting to Android (native) was not difficult at all.

I do agree with you that .NET JIT compiler is fast enough for most cases (and that apps often are GPU bound). For me using a native language was important because I wanted to make small native binaries just like the main inspiration ".werkzeug" tool.

I tried running your project with Visual Studio Express 2012 but encountered a few errors. Have you tried it?

"The type initializer for 'OpenTK.DisplayDevice' threw an exception."

[Petya2164]

I do agree with you that .NET JIT compiler is fast enough for most cases (and that apps often are GPU bound). For me using a native language was important because I wanted to make small native binaries just like the main inspiration ".werkzeug" tool.

I agree that Delphi is the only viable high-level option if you want to have small native binaries. In C++, you often get large binaries for relatively small programs. And going back to C (or to Assembly) would be a productivity nightmare

I tried running your project with Visual Studio Express 2012 but encountered a few errors. Have you tried it?
"The type initializer for 'OpenTK.DisplayDevice' threw an exception."

No, I haven't tested it with VS Express 2012. Can you pinpoint the code line that throws the exception? I guess that this issue might be related to a newer target framework, try to set it to .NET 3.5 if VS somehow modified the project options. You can also try SharpDevelop/MonoDevelop (with unmodified project/sln files) to see if the issue is VS-related or not.
A similar issue was reported here: http://www.opentk.com/node/2537 and the solution was to drop the OpenTK project reference and add OpenTK.dll from elsewhere as reference instead. It might be that VS 2012 cannot handle the project reference properly.
Anyway, I was thinking about removing the OpenTK project from the solution, and directly use the dll (to simplify the build process). But I frequently make modifications to OpenTK, and I want to navigate to its source files, so that solution is not ideal either.
Please let me know how this turns out for you!

- Peter

[VilleK]

You were right, VS2012 automatically set the framework to 4.0. I switched back to 3.5 and then it worked straight away. It looks very nice! Already much better user interface than ZGE.

[Petya2164]

Glad to hear that it worked!
To be honest, the editor is far from usable at the moment. I have to re-write the code generator and then it will be easier to implement what is missing right now

[Petya2164]

Hi guys,

I have added a spate of new features to the editor. My primary focus was usability and code generation. The Project Tree now has a right-click menu to add and delete components, which makes life considerably easier. You can also add custom C# code to the application or to specific models, and you can recompile that code on-the-fly, the game state will be preserved although the application itself is re-created. Keep in mind that all your code is compiled, this is not really scripting. I wrote a brand new code generator that works similarly to the Visual Studio designer. You can see the whole generated code in the editor, and it also supports standalone builds. Anyway, you can check out the project roadmap here:
https://github.com/petya2164/ZsharpGame ... ki/Roadmap

The codebase is growing rapidly, it is just over 10000 lines now
Oh, and there is a little RTS example among the projects to showcase some of the new features. The colored spheres are the units, and you can move them over the terrain by left clicking (first the unit then the destination point). Make sure to hit the "Start/Stop" button if you want to see the units moving, as the application is paused by default.

Let me know what you think!
I am a little bit uncertain about my next steps, perhaps there are too many ideas in my head about the project

- Peter

[VilleK]

I just tried it and it looks great. The code generation is very nice with the InitializeComponents section clear and readable just like when using WinForms. And also very cool that standalone is already working. Perhaps you should start providing binary builds of Z#GameEditor to make it easier for users to test?

[darkhog]

One thing that really bugged me whit editing components was method used. I'd like something more like Scratch's/Stencyl's "design blocks" and ability to write custom blocks in C# with simple block's UI designer that would expose specified variables to user of such "custom block".

Basically take what ZGE is now (it is great scene tool) and slowly change it into 3D Game making program with features from "real" game engines, such as physics, but not forgetting Z#GE roots, i.e. not removing procedural things which is as easy to use as MultiMedia Fusion/Klik'n'Play/The Games Factory is for 2D games. Of course keeping it as free/libre software (you can do living from it by e.g. selling "content packs" (textures/models/sounds/music) or providing paid support).

[Petya2164]

These are excellent suggestions, thank you!
I will put up a binary release when the basic editor features are all stable.

To be honest, I was also thinking about using blocks instead of the treeview that we have now. The treeview is getting quite confusing for bigger projects. Blocks (or icons) would provide a more efficient solution to represent the same component hierarchy. We can even have lines connecting the blocks to indicate dependencies.

The PropertyGrid currently exposes all the public variables of the blocks, and I believe this is a nice way of editing those variables. However, the code editing is not so efficient now. It is relatively difficult to find the method that you want to edit, even if you have just a few components. I am toying with the idea of editing the project code separately and binding the corresponding events to methods similarly to the VS (or Delphi) designer (with C# partial classes). Then you can see and edit your source file in full (maybe you would want to use VS or SharpDev for editing). Well, this would essentially "degrade" the IDE to a 3D component designer surface (analogous to the WinForms designer surface in VS).

I am big fan of visual programming but I always felt that most projects (like Scratch, Google's AppInventor, Kismet in UDK) apply this concept on a very low-level to fully replace textual code statements. And this is never going to work on a statement level as it is very efficient and natural to write code lines! Instead, we should apply visual programming on the component level to specify structure. Well, not like UML, because that will result in a spider web But ZGE has the advantage of forcing all components into a program tree! And for me, this is the most appealing feature!