🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

The future of my game engine.

Started by
7 comments, last by Alberth 2 years, 11 months ago

Hi there!

For the last 3 years I have been working on an open source game engine in my spare time. Concept wise it is similar to Love2D in that it allows you to build games in Lua running on a C++ back end, however there are some fundamental differences that make my engine potentially very desirable compared. Here's a run down of some of the things it can do:

- Works on OpenGL 4.1+ (and ES 3.0+) (no SDL dependency).
- Write game code in Lua, no need to recompile every time.
- Very fast emitter/subscriber event system.
- Scene system, to switch instantly between game parts.
- Load in textures, sprite sheets, custom shaders, fonts, audio, tile maps, text data, databases etc...
- Smart renderer that renders in organised batches for performance.
- Simple and easy to use transform system to move, rotate or scale graphics.
- An SDK/CLI for creating, packaging and sharing your games.
- Compact & portable, with the main executable compiling to 2mb in release mode on Windows.

Development has remained on a private repository since conception, as a lot of the things I needed were things I did not know how to do (like learning C++ as I'm a C# dev), and I wanted to avoid the pressure of people getting inpatient with the progress. I actually build a fully working version of the engine in C# MonoGame before moving to C++, so the whole process has felt like a life time already.

So just recently I reached the point where a good majority of the code base is in good working order. I've shown various examples to people in person, it ports fine (runs on Windows, Mac OS, Linux), and a lot of the pieces are in place, however I'm still wary about pressing the button to make the project go public, as there is a good while, maybe months/years till a v1.0 will happen.

I guess there is some anxiety on my part, wariness that people may miss the point of the project etc... or that people won't understand that it's finished as I am not great at art (the website prototype is still in a shambolic state!). There is also worry weather I'll be able to manage the project when a lot of people make requests etc…Still though I am so proud of the damn thing that I want to shout about it.

Has anyone else been in this situation? If so can you tell me weather I should be patient and plan further? Working in a black box has had it's uses, but it does feel that exposing it to the community might be the best course of action so feedback can help mature it to competency.

Thanks for any contributions to the discussion, I am keen to hear your thoughts.

Koda

10 months since I ordered a 3080, still not arrived… :'(

Advertisement

Hai,

I have been “playing” in open source projects for many years, and reading your post, I think you have a somewhat incorrect picture of how things work there.

When you go public, yes you will have people missing the point, and you will have requests for extensions (from simple to complicated to completely out of scope), and people will ask when feature X is available. This is however not a problem. It's very natural to ask such questions, especially when one doesn't have experience in open source development (ie they don't know how it works).

Where you go wrong is with the idea you need to implement each and every request. This is not the case. Nobody but you decides how to spend your free time. It's generous enough that you make your work available for others!

The simple rules being used often is that the person doing the work implementing the feature decides how it is implemented, and the person controlling the repository decides whether it gets accepted. The latter does include implementation considerations, ie if I implement a feature for the project in a (to you) bad way, you can (and should) reject it. Smart contributors often discuss these things beforehand, making the process more smooth, and then rejection is much less likely.

All requests, bug reports, patches, etc etc are just questions how you look at the subject. If you can reach agreement everybody is happy, otherwise if there is at least some common ground, explain why the current form doesn't work for you. All other things are simply out of scope. It's fine that the other person wants it, but he/she doesn't own your time unless you (and only you!!) decide otherwise.

If you want more details, ask here or feel free to send a PM.

I've taken what you said on board and agree, afterall I control branching and merging. Perhaps the biggest issue is knowing when it's ready rather than what I'll face when I go public if you know what I mean. I know a project like this can actually be in a perpetual state of progress or readiness, and perhaps nearly having everything in place is making me wonder when I should actually press the button.

10 months since I ordered a 3080, still not arrived… :'(

Oh, ready isn't an issue in open source. Nothing is ever ready until the repository is archived ?

What you get with a certain version is a set features. If that set is sufficient for the problem at hand, your engine is usable, else it isn't. It's that simple.

A release hasn't much meaning in practice. It is mostly a tagged development version, and nothing more. Of course it depends on the release process, but you're not going to have something major different in a release compared to the development version at the time.

As the tag doesn't move, the feature set is constant in time, which is nice for building something distributable and having documentation created for that version. On the other hand, with todays CI facilities, those things tend to get build for every change in development too, so it's far from unique.

If you want to avoid deciding when it's ready, do a time-based release, eg every 3 months (although that may be too fast). A release impacts development somewhat, as you don't want to add big changes days before the release date as you don't have a chance to fix any problems that might happen then, but you have that problem with any release policy.

You should consider what license to use for your software. If you use other software that comes with its own license, this can be a tricky problem.

That's already something that has been sorted months ago, the engine is under the ZLib license, with dependencies either using ZLib, BSD 2-Clause or MIT. This was part of why it's taken a while to get to this point as I wanted it to be as open as possible ?

10 months since I ordered a 3080, still not arrived… :'(

Do you know what, I'm going to polish the website, wrap some of the final bits up, then put it live early next week. I think just having a conversation about this has helped me set my mind straight lol.

10 months since I ordered a 3080, still not arrived… :'(

kodaloid said:
Do you know what, I'm going to polish the website, wrap some of the final bits up, then put it live early next week.

hehe, great!

Enjoy the ride, I hope you find many pleasant surprises on your path ?

This topic is closed to new replies.

Advertisement