next »

[RandyGaul]

Simple Engine Library (SEL) is a 2D open source (Zlib license) game engine written in cross-platform C++ and Lua. SEL is a professional and modern engine that utilizes the component based model to facilitate very efficient development cycles.

SEL is ideal for two specific uses:

• Creation of any 2D game
• Study as reference for all interested in computer science, especially game engines

Engine Design Overview

The engine is designed with a component based model. Game objects are merely aggregates of components. A component encapsulates specific data and functionality. The components a given game object define its behavior and appearance. The engine is designed to take advantage of how simple a component based model can be data driven. Data oriented design is taken advantage of where necessary (in this regard SEL's design is similar to the ever popular Entity Component model).

SEL takes advantage of a custom introspection implementation. This leads to automation of many tasks such as serialization and script binding. You might think that the source code of SEL is small in comparison to the feature list; utilization of introspection is the biggest reason for this.

In general simplicity of implementation leads to readable and efficient code; advanced C++ features are only used where necessary. C-like code is often striven for.

Is it an engine or library?

Originally the scope of the project aimed to provide a small library for utilizing a proper component based C++ core. After time the scope changed to something larger and cooler -a fully featured engine.

A little about Myself

I'm a computer science student currently studying for my Bachelor's in CS. I spend most of my freetime playing Starcraft Brood War, working on this project, and hanging out with my lovely girlfriend. I also like to frequent websites like reddit and stackexchange to answer people's CS questions.

I have sort of a thing for trying to help out individuals learn CS and game programming, for free. There was a time when I wanted to attend uni and couldn't due to lack of funds. This experience drives a lot of the effort I put into trying to make free resources for others.


Link to Source Repository

Completed Features List

SEL Website


SEL Feature Highlights

• GLFW for windowing, input and OpenGL context
• Custom introspection for automation of many tasks
• Varius custom containers for strict memory usage and ease of debugging
• Efficient 2D sprite batching and z ordering
• Complete Lua integration, featuring coroutines and more
• Run-time C++ enumeration editor
• Integrated Box2D

To-Do Highlights

• Tile physics (non-Box2D)
• Resource hotswapping
• Joint serialization
• Some simple built in GUI stuff

Here's some code snippets of what the end goal will look like in terms of using the engine:

Code: (Scripting enemy behavior in Lua, patrol and throw bomb)

-- Patrolling enemy

function Start( self )
end

function Update( self, dt )

  while(true) do
    self:PatrolLeft( )
    WaitSeconds( 3 )

    self:PatrolRight( )
    WaitSeconds( 3 )

    self:ThrowBomb( )
    WaitSeconds( 5 )
  end
end

function Finish( self )
  CreateAnimation( "EnemyDeath", self:GetPosition( ) );
end

Code: (Write new component types in Lua)

-- A "Floating" component, makes an object float up and down
-- with a nice oscillation

function Start( self )
end

function Update( self, dt )
  local position = self:GetPosition( )

  while(true) do
    position.x += 1
    WaitSeconds( 1 )

    position.x -= 1
    waitSeconds( 1 )

    position.x -= 1
    waitSeconds( 1 )

    position.x += 1
    WaitSeconds( 1 )
  end
end

function Finish( self )
end

Adieu

Ultimately this engine will be used to create a 2D game in the likeness of some of my favorite SNES games (ALTTP!!). In the mean-time I hope to create a very interesting devlog. Feel free to contact me to discuss or ask questions about computer science and game programming in general.

[RandyGaul]

Currently I've been working on the graphics in OpenGL. I'm best at physics engine stuff but knowing how to do some graphics is super useful. After all physical simulation isn't cool if you can't see it.

Recently finished up sprite batching! Sort by z order then sort z order sections by texture, offload all the transforms to the GPU in a texture. Result is I can draw more objects than I think is really necessary on-screen while dynamically moving about.

I capped at around 8k sprites on-screen before I started getting near 60fps on my home machine. This is pretty good, and I think I'm fill-rate bound. I might schedule in some 2D occlusion culling with some sort of tree broadphase, perhaps quad tree or a BSP tree. Not sure.

Here's a screenshot of testing out batching, z order and multiple textures:



Next on my agenda is some core architecture stuff. Specifically I want to hook up serialization of game objects. This includes archetype files and level files. The level files also will need to support instance data of specific data members. I wanted to finish these things today but I just arrived from travels to visit family for winter break I think I'll delay this stuff for tomorrow morning.

[happymonster]

Sounds very nice, keep going!

[RandyGaul]

Sounds very nice, keep going!

awe shucks

SERIALIZATION  

It's been done. Made archetype files:

Code:

GameObject
{
  Sprite
  {
    m_tx Transform
    {
      p Vec2
      {
        x float 0.000000
        y float 0.000000
      }
      o float -3.132142
      s Vec2
      {
        x float 20.000000
        y float 20.000000
      }
      zOrder int 0
    }
    m_draw bool true
  }
}

And level files:

Code:

SpriteTestObject
  Sprite:m_draw; bool true
  Sprite:m_tx:o; float -3.132142

I spent majority of my time debugging a crazy driver issue with OpenGL. For some reason glBufferSubData wasn't calling synchronously so I had to do a workaround with buffer orphaning in order to fix my sprite batching. I wish I could say the result was nice or more efficient, but really it just didn't have any bugs (which is good too I suppose, but meh like 6 hours lost).

Excited for tomorrow as I plan to do component creation with a Lua file  


The level files are supposed to work by listing a bunch of different archetype names. Each archetype file is a serialized game object to use as a template to build a type of game object. However level files also need instance data for things like initial position, orientation, sprite, etc.

The instance data format for saving/loading was something I put a good amount of thought into. I'm still not sure if I like it. The idea is list an archetype followed by the name of a member. Each member name is separated by a ':' character, so you can have instance data for members inside of members. It's meta  

This makes it pretty easy for me to modify level files given the introspection in the background. So I'll paste this example again:

Code:

SpriteTestObject
  Sprite:m_draw; bool true
  Sprite:m_tx:o; float -3.132142

This is an instance of a game object with a sprite component. The level loader instantiates the data member m_draw with true, and the data member of the data member (meta) o (stands for orientation) to some random radian value.

If anyone has opinions on the instance data stuff I'm all ears. Like I said I dunno if I like the file format... But it does work and is fast enough.

[RandyGaul]

Welp didn't get to the Lua components yet, but I did do a lot of work in another part of the engine.

Enumerations are reflected in the introspection and I ended up creating a fast (hashtable) string to enumeration converter. I needed this for loading of level files. This resulted in some super nice looking code, like so:

Code:

engine.LoadLevelToSpace( space, "level1" );

Speaking of spaces, I don't think this is a well known topic. A space (don't know if there is official term , at uni it's called a space) is a container of game objects. Game objects from different spaces have no communication at all. This is nice for separation of different groups of game objects. For example all UI can go in a space, all gameplay in another. This lets you draw/update different spaces at different times easily. This is a little nicer than only have a game state manager and writing special code to group types of game objects together.

It'll be cool to get some screenshots of some example gameplay components doing things in the near future, like the patrol component I have in the original post

[RandyGaul]

Got the Lua Components thingy done! This is exciting because Lua files can be hotloaded and modified during run-time. This means one could edit a Lua component and see the changes without re-opening or re-compiling the game.

Took me a while to get this done as I really didn't want to call loadfile every time a component is constructed. Ideally you can load a script into memory and reference it in memory whenever you need, as file i/o  is ungodly slow. I had to do some silly stuff with Lua chunks and upvalues to let a chunk inject definitions into the environment of a newly created Lua component. This way I can just hold all the chunks for all component files and inject the Init/Update/Shutdown functions (and any file-local variables) definitions whenever I need. No file i/o or run-time chunk parsing needed.

I made this component to test things:

Code: (testcomponent.lua)

function Init( self )
end

function Update( self )
  local sprite = GetSprite( space, self )
  local timeDelta = 0.1
  local moveDistance = 1.0
  local radianDelta = 0.1
  
  while( true ) do
    AddPosition( sprite, 0.0, moveDistance )
    AddOrientation( sprite, radianDelta )
    WaitSeconds( timeDelta )
    
    AddPosition( sprite, 0.0, -moveDistance )
    AddOrientation( sprite, radianDelta )
    WaitSeconds( timeDelta )
    
    AddPosition( sprite, 0.0, -moveDistance )
    AddOrientation( sprite, radianDelta )
    WaitSeconds( timeDelta )
    
    AddPosition( sprite, 0.0, moveDistance )
    AddOrientation( sprite, radianDelta )
    WaitSeconds( timeDelta )
  end
end

function Shutdown( self )
end

This makes an object float up and down while spinning:

I still have a little more work to do with some of the Lua stuff:

Code:

AddPosition( sprite, x, y )

-- Should be:
sprite:AddPosition( x, y )

This requires messing with metatables and stuff, which requires updating my reflection, so I'll do this later. For now things are working just fine.

Coming up next is to finish the action list and integrate Box2D. I'm particularly excited to get Box2D in here as I have experience making my own custom physics stuff; I believe it'll be a piece of cake integrating Box2D. Things should really start coming together at that point for the engine.

[RandyGaul]

Don't know about you guys but for me Christmas time can be pretty stressful. Also my feet are terribly cold making it hard to work

Took some time to relax and work on boring stuff like updating my personal website. While I was making boring things look nicer I decided to make a not-so-boring thing look nicer, this project:

Was actually inspired while browsing randomly around here and found this sweet gif here on the forums! Took me a while to find a composition that I felt was decent. Now I get to put it all over random things on my website wee

[CMDR Coriander Salamander]

Well, not to look like a stalker or anything...

...but I was wondering where I'd seen this before when I saw it on teamliquid and then you linked here and I was like 'ohhhh, I totally read that like two weeks ago lol'. And then I also PMed you totally unrelated on TL like yesterday (I'm Cyx on there). And now I feel fucking creepy.

[RandyGaul]

Well, not to look like a stalker or anything...

...but I was wondering where I'd seen this before when I saw it on teamliquid and then you linked here and I was like 'ohhhh, I totally read that like two weeks ago lol'. And then I also PMed you totally unrelated on TL like yesterday (I'm Cyx on there). And now I feel fucking creepy.

D'aww I have a stalker! How coot

I really wanted to get some gifs of physics going, but as I sat down to work for the first time after Christmas I was super annoyed with my object construction. At the time I wasn't using any dependency inversion so whenever a new component type is created in C++ multiple files had to be modified in various places to account for construction of the new type. This decreases code readability and increases inter-file dependencies. Bad.

So, like I mentioned, I made use of some dependency inversion. In order to do so I needed to de-templatize a little bit of code, which caused me to re-write a silly allocator to be non-templated.

After some more cleanup of a bunch of files I got it all working and humming.

Physics + gifs tomorrow, and the slider should bump to 80% completion.

[RandyGaul]

This certainly won't look like much, but that's really just because I don't have any sort of editor at all. This marks my own personal milestone of being done with the core code.

All that's left is to do some finalizing and optimizations, such as some specialized containers and tools, and documentation. After these are finished the rest of the work will be put into a couple different editors. I'm excited to use a nice GUI library as I've actually never made an editor myself before!

As promised:

[RandyGaul]

Well I've had a ridiculous past few days  

Tried out some gui libraries, wxWidgets and Qt. I didn't like either one (but I liked Qt way more); I decided to just stick to in-game editors.

This means I won't be making any cool generalized editors like I planned, but that's okay because I spent the rest of my extra time today making a texture atlas generator for png images. This is really cool because it was on my wish-list! Scoping down can have *awesome benefits*  

It also converts RGB format to RGBA automatically, which is nice because often times artists save between both RGB and RGBA intermittently.

Outputted atlas file, UV format is of two vectors representing min/max of a rect:

Code:

amtjde.png
  0.000000, 0.000000
  0.585938, 0.527344

ActionListEnemyBombPatrol.png
  0.000000, 0.527344
  0.449219, 0.907227

196118_394820890602482_127565429_n.png
  0.449219, 0.527344
  0.949219, 0.777344

ico.png
  0.585938, 0.000000
  0.869141, 0.280273

Capture.PnG
  0.585938, 0.280273
  0.846680, 0.514648

clipping.PNG
  0.449219, 0.777344
  0.647461, 0.963867

puzzle_piece.png
  0.449219, 0.963867
  0.473633, 0.988281

yay things are finished

The awesome part about this atlas tool is can I make a super fast and super cool font renderer!

And no that's not my art, I took it from the pixel art image crawler  

10% LEFT UNTIL I'M DONE THIS IS FUN finishing things is exciting

[RandyGaul]

School started up again so I've had little time to do things. Lots of administrative stuff when the semester begins :/

I found a huge bug in my Lua implementation so some refactoring cost me all of my dev time today. I did however finish up premultiplied alpha, and I quickly made a lua component to control some fire particles!

Totally shouldn't be doing this sort of particle updating with Lua, but it's fine for demonstration.

I decided I want to make a nice OpenGL encapsulation, nothing fancy but the idea is to make a simple shader manager that delays all OpenGL context calls. You can filter out redundant OpenGL API calls and the like easily this way.

I've also yet to actually make use of the atlas generator. Currently I don't have a way (that I like) to pass UV coordinates to the GPU that plays nicely with the instancing I have setup. I'll have to think about this a little more. Once I can make use of atlases I'll probably use some tweening and render some cool font stuff.

[RandyGaul]

Aha! Got a simple OpenGL abstraction layer going. It's quite nice. I've never done this sort of thing before so it took me all day to do this. Now I can write sort code like so:

Code:

Context context;
State state;

context.Init( );

Shader shader( "name" );
shader.AddUniform( new Uniform( "name" ) );
shader.AddBatch( new TransformBatch );

// Render all sprite batches
context.Render( shader, state );

The idea is to rid myself of annoying global state of OpenGL.

[RandyGaul]

So school started and stuff hit the fan...

Getting back into the groove of managing my time well. Today I finished some cool polygon splitting stuff for an online article demo, of which will be incorporated into SEL

I thought I'd share this here since it's visual and you all love gifs so much:

This can be used for dynamic sprite splitting or world/object real-time destruction (2D and 3D). I also made a slightly different (and simpler) triangle clipper that works with pure triangles (the above image works on arbitrary convex polygons). The cool thing about the triangle clipper (below) is it can be used for buoyancy (area) calculations in real-time for some pretty interesting 2D/3D ocean physics simulation:

You can see that this triangle clipper totally makes a bunch of unnecessary triangles, so it's not good for rendering. It is good for a one-time clip where  you don't keep the results and only want to work with triangles. This clipper also works in 3D and can be used for cool stuff like

.

[joncol]

Cool stuff! I haven't yet looked at the source code, but I'm curious about what you mean by introspection. Could you provide a quick explanation or some good links?

I've recently made my own entity-component system using Lua and C++. (And with the disclaimer of not having completed any games with it, the architecture feels extremely flexible and fun to work with.) In my case, the C++ layer is pretty thin and only manages image loading, sprites (I use SFML for blitting etc)/collision detection (what I'm currently working on).

The component system is written entirely in Lua. What are your thoughts about what to put in Lua vs C++? I imagine I could run into performance issues down the line with my current approach of having most of my stuff in Lua, but at the same time, Lua feels much more fun and effective (programmer productivity wise). I guess a good strategy is to move stuff over to C++ if/when finding out that it's having an impact on speed.

Also, do you have any thoughts about the Lua/C++ interoperability layer? It seems you expose more or less everything C++ to Lua? Is that what the introspection thing is used for? Me, I have a very C-ish "flat" structure, which was influenced by Löve2d. I'm not using anything fancy at the moment, just plain binding via the Lua C API. I'm interested in other ways of doing this.

Anyway thanks for publishing the source code, I'll have to check it out as soon as I get to a computer (browsing source on phone sucks).

[srslypretentious]

C++ AND Lua??   

Will have a peek around in the source when I get home

Best of luck to you, seems awesome 

[RandyGaul]

Just wanted to pop in and try to put down on record that I'm not abandoning anything here. For me personally it's important to follow through with things I start because I naturally tend to give up and move on with projects or things I start. I think about SEL at least once a week and have full intentions of keeping it all going.

I just started an intensive internship with my favorite company, so I won't be able to dedicate much time, if any, onto this project even though my last summer semester just started.

C++ AND Lua??   

Will have a peek around in the source when I get home

Best of luck to you, seems awesome 

Hi, thanks so much for the nice comment!

Cool stuff! I haven't yet looked at the source code, but I'm curious about what you mean by introspection. Could you provide a quick explanation or some good links?

I've recently made my own entity-component system using Lua and C++. (And with the disclaimer of not having completed any games with it, the architecture feels extremely flexible and fun to work with.) In my case, the C++ layer is pretty thin and only manages image loading, sprites (I use SFML for blitting etc)/collision detection (what I'm currently working on).

The component system is written entirely in Lua. What are your thoughts about what to put in Lua vs C++? I imagine I could run into performance issues down the line with my current approach of having most of my stuff in Lua, but at the same time, Lua feels much more fun and effective (programmer productivity wise). I guess a good strategy is to move stuff over to C++ if/when finding out that it's having an impact on speed.

Also, do you have any thoughts about the Lua/C++ interoperability layer? It seems you expose more or less everything C++ to Lua? Is that what the introspection thing is used for? Me, I have a very C-ish "flat" structure, which was influenced by Löve2d. I'm not using anything fancy at the moment, just plain binding via the Lua C API. I'm interested in other ways of doing this.

Anyway thanks for publishing the source code, I'll have to check it out as soon as I get to a computer (browsing source on phone sucks).

Hi good questions. I think it's important to have a very clear definition on what you want in script, and what you don't want in script. For Lua I'd say that if you as a programmer have a good understanding of how to make Lua useful, then keeping a coherent vision would probably be top priority over most anything else.

I myself am actually going to likely rip my Lua stuff out and start doing some C++ hotloading instead of Lua hotloading. We'll see when the time comes for myself to make some decisions. The pros of this is that C++ is just way faster, and the best part (at least for SEL) is hotloading.

Using introspection lets your code have an understanding of the different types within your code. You can use this information to automate repetitive tasks that revolve around different types of data. This can include things like debugging, serialization, script binding, documentation generation, and a whole lot more. You can try looking for my website for some old information on the subject, but in general this is all a very new idea.

Recently Sirgey from Valve made a great tutorial about this sort of thing for GDC 2014. I loved his presentation and recommend it.

[joncol]

Recently Sirgey from Valve made a great tutorial about this sort of thing for GDC 2014. I loved his presentation and recommend it.

Any chance you have a link? I tried searching for it, but no luck.

[RandyGaul]

Recently Sirgey from Valve made a great tutorial about this sort of thing for GDC 2014. I loved his presentation and recommend it.

Any chance you have a link? I tried searching for it, but no luck.

I spelled his name wrong: http://www.gdcvault.com/play/1020064/Physics-for-Game-Programmers-Debugging

[RandyGaul]

Two new and exciting features added! Thread pool and C-Coroutines.

The first is a simple implementation of a C++11 thread pool. The idea here is to allow a concurrency solution for the general purpose. Hopefully I'll have time in the future to thread my own copy of Box2D's island solving. Graphics doesn't really need to be threaded since almost every bit of work is done in the GPU currently. The only thing the engine that could possibly be threaded as of now (besides Box2D) is the sorting of sprites for batching and z ordering. A recursive approach could be implemented, but sorting is already fast as it is (so I'll probably never optimize it).

Using the thread pool is my favorite part due to how simple it is  

Code:

ThreadPool pool;

pool.AddTask( myfunction, param1, param2 );
pool.AddTask( myfunction2, param3 );

// Waits until all tasks in the pool are complete
pool.WaitForFinish();

The next feature is a clever little gizmo that attempts to implement Knuth's idea of a Coroutine in C (not to be confused with the engine's Lua coroutine implementation). Coroutines really have to be implemented at a high level emulation (like in Lua), or in assembly. Though they can be mimicked in C pretty easily, they cannot be implemented in actuality. The goal here is to have inviting syntax that is appreciable by gameplay code (especially ai routines!)

Code:

void UpdateBomberAI( CoroutineContext context )
{
  COROUTINE_START( context );

  // walk left

  COROUTINE_YIELD( context );

  // walk right

  COROUTINE_YIELD( context );

  // throw a bomb

  COROUTINE_END( context );
}

The above code would actually be called once per game loop. Each time it is called and a YIELD is hit, the function will immediately exit. The next time it is called (if the same context is passed in) the code will resume from the previous YIELD! This is pretty sweet! Later I'll functionality for yielding for a specific amount of time

Another great aspect of this is that generic things can be attached to the context to act as "scoped variables" for the function a context is passed to. This means that a context can be passed to a function, yield, be transferred from one thread to another, and the function can still be resumed. What I just described is a flexible tool for implementing something like an asynchronous file loader!

These two tools are very simple, very useful and lots of fun  

I dropped the completion from 90% to 70%. After spending some time in my first internship I learned some things and new perspective has been achieved. I just feel that the 90 reflects how much work is left appropriately, but the 70 is more time-realistic. When I first open sourced the code was over a Winter break, so I had all night and day to code. Now I hardly have any time to code until my internship ends.

I want to scope down graphics. I think having some tools to write shaders is important, and automated sprite batching is important. Batching is done and shaders are to-do, and I don't want to support anything beyond shader support (perhaps run Clang pre-processor on shader files for all the C # directives). With the down-scope I should be able to finish the engine by September this year and start on my first game with it. After all, in order for the engine to be any good it needs to be used and be iteratively improved.