Khanon.js a typescript game engine extending Babylon.js

Demos and projects
1

Hello,

I’m finally sharing with you the project I’ve been doing for a long time.
It is a game engine extending Babylon.js capabilities.

1260×437 42.9 KB

Project repository:
Github.

Tutorials repo:
Github Tutorials

NPM package:

Website:

If you want to have a quick view of how it works, you can check Working with actors tutorial.

Key tips:

  • Khanonjs adds a layer over Babylon to drive the logic of the application.
  • It is transparent, the user have access to all of the babylon objects and all of them are freely manipulable, Khanon.js doesn’t rely on any of Babylon object’s properties (but for very concrete situations such 2D sprites, where they are built with a specific mesh and mterial).
  • It adds some new features to Babylon objects, like lifecycle, actors, notifications, event interactions, particles integration with sprites, etc.
  • It works indifferently with 2D sprites and 3D meshes. They all are integrated in the same system.
  • It is built by decorators, the user doesn’t need to instantiate classes and store them in variables, everything is accesible from a global KJS class.
  • It is modular, Khanon.js elements can be added, removed, or moved with a minimum impact.
  • In the future I plan to add more features focused in the game development like scene maps to build games with a template that would fasten up the development, Babylon physics engine integration, etc.

As I mention in the documentation:
– Khanon.js wants the developer to focus in the game design. That’s the main goal of this project.

Currently it is in Alpha stage, there are some features I still have to add to reach the Beta:

  • Deeper testing and debugging.
  • Input events decorator.
  • Sounds and music decorators.
  • Project builder for debug and production optimized bundles.

The project is open source. Feedbacks, suggestions and contributions are welcome.
I’m still working to have a robust and comprehensive base, but it is close to the final shape.

I also want to thank everyone who helped me on the forum, Babylon community is great. Especially to @Evgeni_Popov and @SvenFrankson whose help have been crucial for the 2D model.
And congratulations to Babylon team for the huge job behind the Babylon engine and the big amount of features it has. That helped a lot!

11 Likes
2

The quality of the doc itself, says it all, for the amount of work behind !

Screenshot from 2025-04-01 14-52-44
Screenshot from 2025-04-01 14-52-441837×931 171 KB

In parallel, are you developping some games based on Khanon.js ? It would be a nice way to demonstrate what your engine brings compared to a “raw BabylonJS” game :slight_smile:

4 Likes
3

Thanks for your words!
Yes it had some amount of hours behind :smiley: Writting the documentation is a lot of time..

I don’t want to do a game until reach the beta with full features, will be more decorators and I want to have them for the full demostration :slight_smile:

4

From what I have seen in the wild, engines, frameworks, editors, are among the hardest to sell (in the widest sense). I would say having a “flagship game” beside your engine, will help your marketing tremendously. (Ok, the game shouldn’t be bad obvoiusly :grin:)

Other than that, a game will also act as an (or the) acceptance test for your engine. At least in the beginning you will not have the user base to get much test feedback in. So, how else are you going to tests your engine if not coding a game with it?

Last but not least, fingers crossed for you :money_mouth_face:, but should your engine disappoint expectations, you have at least a game to fall back to.

I know it is too late already and reading your remark as a bit of a complaint, when browsing your source code some of the comments I saw were just redundant:

  /**
   * Returns the name of the class.
   */
  getClassName(): string

Yeah, no shit :winking_face_with_tongue: But actually the best example ever for self-documenting code. That method name tells you everything you need to know about it!

In that entire file I have seen one useful comment:

  /**
   * Sets a timeout.
   * This interval relies on the app loopUpdate and it will be triggered on correct frame.
   * It will be removed on context remove.
   * @param func Callback
   * @param ms Milliseconds
   */
  setTimeout(func: () => void, ms: number, context?: any): Timeout

Ok, understood. Although you could have named the method sth like “runOnLoopUpdate” which summarizes the second sentence. And see, imagine you are in your code editor. And imagine you have seen many of those redundant doc entries. And then you come across the tooltip of setTimeout and read “Sets a timeout”. Angrily hits escape thinking, “Get out of my face stupid tooltip…” Only this time you missed an important info about the context remove thingy.

2 Likes
6

Thanks for your feedback and your time :slight_smile:

I’ll make a game to showup the engine, you are right, but I still need to implement last things.
The input events decorator will be widely used and it will be a must in the code.
Also the bundle is too slow in debug mode and I have to fix that.
The 2D sprites tutorial is pretty nice thanks to the artist that lent me the graphics, but the 3D and Actors tutorials are horrible at the moment. I expect to improve them.

Regarding the documentation, I agree there are redundant things in the api docs, but all properties and methods are described even if the description is just the method’s name. I didn’t find the tooltip annoying, I’m not sure if it is better to have a description for every method and property, or leave some of them in blank. If you think that’s too annoying I can change that :slight_smile:

7

I think proper commenting in code is necessary, especially when packaging as a library, even if it’s a method whose name is obvious.On the other hand, it helps to generate api documentation.
Please follow your ideas (the parts that have been planned so far) and I look forward to seeing the first full version of what you envision!

1 Like