SUE, the SFML-based Simple Usable Engine

[Mahboi]

Hello/Bonjour everyone,

I'm part of a small group of Epitech Lyon students and we're gonna begin work on a full 2D game engine based on SFML soon.

For those of you who don't know Epitech,

(click to show/hide)

it's a computer science school based in Paris with branches all around the country.
We're in the middle of our 3rd year and the Epitech cursus requires that we commit to a large-scale, professional-level work over the course of the 4th and 5th years. This project is called EIP, for Epitech Innovative Project. As EIPs go, ours is known as Projet Opaline/Project Opaline, and the result of this project will be SUE.

Me and my EIP group are off to work on this game engine for the next 18 months roughly, unless the group gets disbanded or crashes for one reason or and other. Epitech demands that at least 6 people work on an EIP and we're just 7, so we're not well off. But if the group holds, we will work on this fully SFML and Qt-supported engine.

Of course, we're all native french speakers.

The Original Idea
A lot of us have touched at one point or another to Unity3D or Unreal Engine 4. Those massive game engines pack with themselves a tremendous amount of power and tweaking capabilities, but they bring along just as much hassle.
The real issue isn't so much the complexity by itself, as that always comes with highly capable engines, the issue is that something like Unity3D has seemingly become needlessly complex for a lot of tasks.

What could be a fairly straightforward and simple task to do can become a full-blown research into how Unity works just for simpler 2D programs. The necessary knowledge to properly use these engines means that you basically have to become an expert or constantly check documentation for tasks that really should be about clicking a button, when it comes to 2D games.

On the flip side, we have a lot of efficient libraries that can be used, SFML being our opinion the best of them by far, but those are limited to programmers. Knowing how to code is a must and cannot be avoided if you're gonna take the straightforward library route. Also, it takes obviously more time to type everything down yourself rather than have a preset engine where everything is there for you.

In our opinion it is the spot in-between that needs to be filled. A game engine that will relinquish some more complex features including 3D, but that will gain from it in simplicity and usability. The point is to make an engine that will not require C++ knowledge(although script plugging will of course exist), and will be as simple to use as possible, without abandoning the features that allow good game-making. That is what we will have in mind when making SUE.

A Modular Engine
In line with our idea of simplicity of usage, we intend for SUE to be modular and pluggable.

Essentially, the engine will function like any other game engine, with a screen, list of assets, menus, object-making capabilities, same as Unity3D or Unreal, but at its core there will be only a basic "layer" of SFML graphics interface, sound and physics. A game engine with nothing in it except the capacity to add songs, visuals and basic physics to your objects.

On top of that basic layer we will have game modules. Those will make the bulk of SUE's capabilities as a game engine.

For example, let's say you want to make an RPG-type game. You start a project, pick the RPG module, and you'll have the base layer, along with an RPG drop-down menu in the engine main page. The menu will have everything necessary to have make an RPG, classes, stats, powers, types, buffs and debuffs, special effects, everything you can think of to make an RPG will be there. If you pick the Visual Novel module along with it, you'll have the Visual Novel menu beside the RPG menu, with things like background image, character animations, multiple route choices, etc.
Most game engines go the generic route and allow for a ton of options that have generic effects. For example no game engine will have a specific "classic RPG textbox" feature. They'll allow writing to screen and putting up a background sprite in the lower part of the screen, but that has to be done by the user. We'd rather go with a lot of very specific features, but make it so that every project will kick out 90% of those features and stay focused on the ones that matter for the project at hand.

Perhaps the best example of what might resemble SUE's functioning is RPGmaker, although it's limited to RPGs of course, it's meant to be for non-coders who want to complete a set project, and don't need a ton of generic capabilities to get it done the way they wanted it. With SUE that philosophy will apply, except it should apply on each module. SUE should be just as capable of making an RPG(tiled or not) as making a game like the recent Shantae Half Genie Hero.

A Pluggable Engine
Of course since we intend to have modules, we intend to make them pluggable. To be precise this is our current(under work) roadmap:

In the coming months we will build a website advertising and showing the progress of SUE. If all goes well, over time it will become a hub for selling/offering sprites, artworks and game objects, as well as the home and fora for the community we hope to build.

Around the time the base site should be up, we will have started building the base program and setup the basic layer I was talking about, graphics, sounds and physics. Once it's done, we will build the API and start working on the first module.

Giving a timetable at this point is completely beyond us, but the main first goal post is the creation, and publication, of this API.

We intend not only to build SUE as far as we can, but also to offer the possibility for anyone who wants to take a go at game-making design to be able to use our API to build their own modules if they want to. If a module is absent, unsatisfying or unpleasant to use, we want anyone to be able to branch it, tweak it, or build one from the ground up.

This should be the two main philosophies of SUE:
- To allow pluggable, specialized game-oriented modules  to speak directly to a game core through a public API
- To have both modules and core software aim for user simplicity, efficiency and focused power by trimming the fat off whichever projects the user will go for.

Publication policy
SUE's base code will not be publicly available at its beginnings. We will definitely release the code by the time our main work with it is done(in 18 months), and if anyone is willing to work with us on the base engine, he/she will be very welcome to help, criticize or correct our work. But we'd rather stick by a close team rather than possibly end up with several branches before the main base is even secured.

Financial policy
We're not really in for the money, but to be honest none of us will spit on any of it if we can get some.

Ultimately, SUE will go the same way as most engines of today: be free of use, and demand a percentage fee on whichever games are made on it. We expect to ask the same as Unity3D, which is 3%(I believe).

While in full development, and as soon as we have built the website, we will also attempt at making a Kickstarter or Patreon or Tipeee, or all of them. No clue if it will get any popular, but we might as well try.

As for the modules policy, we want to devise a fair way to calculate module payment. For instance while the base engine will always be used, it's possible that a user will prefer modules that'll have been done for free by 3rd party devs, and we want them to get the money they deserve for this, preferably through some calculation of how used each module was.

In Conclusion
Besides my own group and my school, this is the first time that SUE has ever been spoken of on the Internet. The reason is obvious, there is a very high likelihood that the people working on SUE and those working on SFML will have a lot to talk about in the coming months.

We might have a lot of API requests for SFML. And we would be very happy, if our code is compliant with SFML standards, to provide additions to the SFML API that we'll have created for SUE.

We also hope to garner attention from devs who have been in this already, or those willing to give it a try. The engine's development will require Qt knowledge for the appearance and interface, and everything else will be SFML. I've also accidentally stumbled upon Thor reading the forum, and I'm sure that we will have a lot of use for it.

We want to create the best 2D engine there can be, and to have it be usable by curious noobs as much as pros who think 2D is the best course for their game. Unless the project is shut down, we're in this for a year and a half and we hope to find people willing to accompany us with whatever they're willing to give, their money, their code, their moral support, or their necessary criticisms.

If you have any questions regarding the project, I'll visit the forum soon again and answer everything.

Thank you for reading.

Mahboi
SUE Team

[JayhawkZombie]

It sounds like a great idea!

I think I may be able to give some advice for you, from a fellow CS major who is building a game engine in C++ - with a small team of 5 - for our senior project.

Don't be afraid of taking ideas from other engines.  In our engine, we have taken a lot of ideas from Unreal Engine. There is a reason why those engines have done so well (and Unreal is open source, and in their TOS they even encourage taking ideas from their code and using it in yours).  It sounds like you already have inspiration from them (but please don't take inspiration from Unreal's UI D: )

Don't be afraid of scripting, but if you really want to make it easy to script in, use something like ChaiScript.  The syntax is much closer to c++, and in my opinion looks nicer than LUA.  It's what we use in our engine.  That may spark a scripting discussion, which I will stay out of.

For things like physics, if you don't need to do it yourself, don't.  Use a 3rd-party library. It will save you so much time.  We decided to do that and threw us ahead of our original schedule by a few weeks.

If you do tile-based games, don't use a sprite for each tile. Use sf::VertexArray instead.
The same goes for particles.  A few hundred is probably OK, but a few thousand will slow you down dramatically.

Don't be afraid to go into the raw OpenGL yourself if you need to, to either do something that SFML can't natively do (like instanced rendering) or to just squeeze a little extra performance out of it.

A multi-threaded environment can be your best friend, just keep in mind what restrictions SFML has when using more than one thread.

And probably what I have found to be one of the most useful things:  build in an exception handling system.  If you can, include a way to display a stack trace (you can use __FILE__, __LINE__, and __func__ to do this).  We were able to use a macro to simplify adding a message to the exception with the file, function, and line number: 

#define EXCEPTION_STRINGIFY(X) #X
#define EXCEPTION_STRING(X) EXCEPTION_STRINGIFY(X)
#define EXCEPTION_FUNC std::string(__func__) + " File: " EXCEPTION_STRING(__FILE__) EXCEPTION_STRING(:) EXCEPTION_STRING(__LINE__) EXCEPTION_STRING(:)
#define EXCEPTION_MESSAGE(STRING) EXCEPTION_FUNC + std::string(STRING) + std::string("\n")

Stack traces will print with the whole friggin' file path, but hey it's better than no stack trace.

And, at least in my experience, the easier you want to make it on the front end the more work you have to do on the back end.  Part of our motivation was a frustration with there being no easy to use game engine out there that could actually make decent games.  It sounds like you have the same sort of motivation.

I never would have known you were a native French speaker had you not said anything. Your English is better than many native English speakers.
Laurent is from France. I see him around here sometimes.

[Mahboi]

Hey, thanks a lot!

We're already discussing your advice. I'm looking into ChaiScript as well.

We'll plunder into all the engines we can but I think that for a UI, we'll take our time, experiment and ask people what they prefer.

For physics I've looked around and the most "first search engine occurrence" one  is Box2D. Its API seems clean and it looks like it has pretty much every feature you could need at first glance. It was done by a guy at Blizzard who did the physics for their games for years, too.

Seems like we'll implement your homebrew exception handler right away, too.

And yeah we're expecting the job to be literally too much. Ultra high specialization and user simplicity will mean a huge workload on the backend. It's also one of the reasons why we want to cut into modules, our idea was the same originally but we decided to make the API for modules open in case we can't get enough done, we'll focus on the core and let the modules be freely added by anyone.

Hehe, thanks for your compliment on my english. Most of my team speaks decently well, though not all. They'll eventually set up accounts and post here when we get to the main SFML usage. I'll keep posting main updates and long texts for the team.

[JayhawkZombie]

For the beginning of the UI, just do something your team can tolerate, and make some tools for you guys.  The work up front is soooooo worth it.

The module idea is good, similar to how ours works.  Just a few interface methods and boom, it'll work, get event notifications, etc.

It sounds like your team has a decent amount of time for it, right?  Over a year.  That's more than most college design teams, at least here in the U.S.

[Mahboi]

Yeah time isn't an issue. But we'll be doing it in parallel with a lot of other stuff, and we work over it during our 4th year where we are split apart in different places all over the world. Some in Korea, some China, some Québec, some Ireland, etc.

Gonna be quite a mess to be far apart, have other jobs, and be each in another uni. ^^'

[Mahboi]

http://i.imgur.com/j4DG7y4.png
First draft of what it should look like.

From left to right,

Top: Toolbar,  Detailed Search

Center: Active Entity List, SFML Window

Bottom: Assets Opening/Modification, Option

Up to now, it's roughly Unity3D. And some parts like the "option" tiny bar will probably be modified.

The two docks on the right(which I drew myself and that's why it looks pretty ass) function like Gimp dockable elements, you can pick an x amount of them from the toolbar and they appear on the right side.

There are only two dock windows but whichever dock you pick stay on and can be picked through the little tabs on top of the dock windows.

Dock 2 has a basic example of a fighting game variable control over one entity: through sliders or number textboxes, you can modify the entity's (in this case a fighter) speed, jumping power, strength/damage, stun potential and size.