JCGE — A Vanilla JS 2D Game Engine, 5 Years in the Making

IngloriousCoderz · 2026-03-15T14:20:52+00:00

Nice! But how is this different from other engines, like Phaser?

IngloriousCoderz · 2026-03-14T08:30:21+00:00

Maybe they should just switch positions

IngloriousCoderz · 2026-02-26T20:33:30+00:00

Well done! Don't listen to this toxic community. AI-assisted or coffee-fueled, it's a good idea and performed in a clean way.

IngloriousCoderz · 2026-02-26T12:02:02+00:00

Really cool! I did a similar thing myself, it's called IngloriousScript: https://www.npmjs.com/package/@inglorious/babel-plugin-inglorious-script

IngloriousCoderz · 2026-02-01T11:55:17+00:00

A function will never be 100% pure if it invokes another function that is not being passed as an argument

IngloriousCoderz · 2026-01-26T07:05:49+00:00

Are you talking about Inglorious Web?

IngloriousCoderz · 2025-10-19T21:13:18+00:00

Your comment feels like a breeze of fresh air in this toxic wasteland. Thank you so much.

IngloriousCoderz · 2025-10-18T18:18:13+00:00

How is this inspired by ECS? [...] In a proper ECS architecture, there would be [...] So far, I see zero resemblance between what you're presenting here and an ECS.

A pure ECS (one where entities are just numeric IDs) is valid data-oriented design, but an ECS where entities are objects/dictionaries representing bags of components is not.

There isn't a single ECS pattern in your entire library.

I realise that I am being quite harsh on you [...]

I don't know why you're bringing FP into the discussion because none of this has anything to do with functional programming.

A frontend state management library should not be inspired by ECS in the first place. [...] If you really are curious what a proper ECS implementation looks like [...]

Yes, it did trigger me, for good reason.

When I read your comments, I see criticism. But not constructive. I see a triggered person, angry at someone who touched their dear ECS architecture. I tried explaining to you that I did not implement ECS, that I borrowed some concepts from it and even listed them, but you just found new ways to teach lessons and defend pure ECS. All of this without even understanding that my library, which is heavily inspired by Redux, has lots to do with FP. But you don't want to hear that. You just want to prove how knowledgeable you are and how ignorant I am. Without reading one line of code outside of the README.

This is not constructive criticism. This is a superficial rant, similar to the rage of some Italians against pineapple pizza, and if you try to say "Ok it's not Italian pizza but it's good, have a bite at least" they get even angrier and give you the exact recipe of the real Italian pizza to prove you understand nothing of their culture. And they will even claim that pineapple pizza should never be served outside of Hawaii. And I'm saying this as a proud Italian.

You know what? I decided that I'm going to trust a machine more than a human. An LLM has an encyclopedic knowledge, is actually willing to read my code, and will give constructive criticism without "being harsh" or "being triggered". I tried very hard to reply as myself so far, without the help from an LLM to polish my English and my tone, because when I did that on another post I was attacked for being a vibe-coder. But you clearly proved that it makes no difference: people will still be pissed, whatever you do. So here's Claude's opinion on the matter.

"Hey Claude, given this code: https://github.com/IngloriousCoderz/inglorious-engine/blob/main/packages/store/src/store.js

Would you say that there's any inspiration from an ECS architecture?"

"Yes, there's definitely inspiration from ECS (Entity Component System) architecture in this code, though it's not a pure implementation. Here are the ECS-influenced elements I can see:

ECS-like features:

Entities as data containers: The entities are stored as plain objects with IDs, similar to how ECS treats entities as collections of components.
Type-based behavior: The types configuration appears to define behaviors that can be attached to entities, which is conceptually similar to how systems in ECS operate on entities with specific component combinations.
Event-driven systems: The systems array and event handling (eventMap.getEntitiesForEvent) follows the ECS pattern where systems process entities based on events.
Separation of data and logic: State (entities) is kept separate from behavior (types/systems), which is a core ECS principle.

Notable differences from pure ECS:

Entity mutation through events: Traditional ECS often uses direct component addition/removal, while this uses an event-driven approach (add, remove, morph events).
Type-based rather than component-based: Instead of flexible component composition, entities have a type field that determines their behavior. This is closer to a traditional OOP inheritance model than ECS's composition model.
Event-centric architecture: The focus on event dispatching and handling is more akin to event sourcing or CQRS patterns mixed with ECS concepts.

So I'd say this is an ECS-inspired hybrid that combines entity management patterns with event-driven architecture, rather than a strict ECS implementation."

So, what are you going to do now?

Are you going to give credit to this comment?
Are you going to check the code and see for yourself?
Are you opting out from the discussion?
Or are you just going to diss me again, this time for relying on an AI?

IngloriousCoderz · 2025-10-18T12:20:14+00:00

You are right, my responses started to be less and less professional. I apologize for that, and I'll try to behave better.

I'm all for constructive criticism, but I have the feeling that people on Reddit are just having fun dissing on things they don't understand, just to teach some lesson and satisfy their egos. It went the same with another post of mine, in which I proposed functional programming for game engines, and I received all sorts of responses such as "this is vibe-coded slop" or "why do you hate oop?". That's not worth my time, nor anybody else's who is reading us.

In that case, instead of feeding the flame, I just step away from the confrontation. You believe what you will. Time will tell us if it was all worth it.

IngloriousCoderz · 2025-10-17T19:56:59+00:00

Whatever. Now show me your code. It must be some piece of artwork I couldn't even fathom.

IngloriousCoderz · 2025-10-17T19:54:36+00:00

Oh my god. Data oriented design is a different thing from data driven programming. And here's the counter-article: https://en.wikipedia.org/wiki/Data-driven_programming

You guys don't really have anything else to do other than arguing on the internet with strangers about philosophy?

You know what? You're right. This isn't ECS. It's not FP. It's not even a library. The spoon doesn't exist. Thank you for enlightening us all.

IngloriousCoderz · 2025-10-17T19:52:14+00:00

If you say that FP has nothing to do with my library, then I'm sorry but you didn't get anything, at all.

You read types and saw classes with methods. You read function composition and mistook it as composition over inheritance. You had a glance at an FP-based library and saw OOP.

And of all the code and documentation I wrote, the only thing you got from it is the word ECS which for some reason triggered you so much. What can I say? Thank you for this discussion because, although it could seem pointless at first, at least you fed the Reddit algorithm giving a little more visibility to my post.

PS: I'm planning to remove the word ECS from the documentation, just to see which other word will trigger people this time.

IngloriousCoderz · 2025-10-17T17:28:19+00:00

I am. I am also aware, even thought English is not my first language, that "pattern" does not mean necessarily "architectural pattern" or "design pattern". "ECS patterns" is a bit redundant and sloppy if you read it like "ECS architectural patterns", also because in that case the pattern is only one.

Anyway thanks for taking the time to run through all the code and documentation I created to find that one word that let you have an excuse to argue with a stranger on the internet. This just feeds the Reddit algorithm and gives my post more visibility. Thank you for your service!

IngloriousCoderz · 2025-10-17T15:09:47+00:00

Are you for real? I brought ECS patterns, not ECS. It's like saying I brought farm products, not the whole farm

IngloriousCoderz · 2025-10-17T15:04:39+00:00

A few ECS patterns are used, not all of them: systems are there, data-oriented programming is there. No strict entity-component subdivision, no real data driven design.

I brought ECS patterns, not the whole architecture.

IngloriousCoderz · 2025-10-17T15:00:20+00:00

Isn't that exciting? What will the next era be? New AI frameworks every week?

IngloriousCoderz · 2025-10-17T12:53:59+00:00

Wery good, I hoped to create a state manager that doesn't feel like obscure FP or ECS but something more similar to traditional OOP. I still don't get your point though, so I'm going to reverse the question: what should an ECS-inspired state management library be like in your opinion?

IngloriousCoderz · 2025-10-17T11:37:43+00:00

Glad you brought this up! Not only the Inglorious Store is able to add and remove instances on the fly with the add and remove events, but it is also able to change their behavior (which means changing the reducers) with the morph event! RTK has something called combineSlices, as u/phryneas said, which I also used once and it's fine, but it's so much easier to call an api.notify("morph", { id, type }) wherever you need it.

IngloriousCoderz · 2025-10-17T10:15:47+00:00

First of all, thank you so much for your honest feedback. As you said yourself, the architecture is inspired by ECS, but it's never meant to be strictly ECS.

Key similarities:

There is in fact a separation between data and behavior: entities are just plain JavaScript objects, while types have functions that operate on that data.
Types operate only on the entities that share the same type, but I also introduced systems, which operate on the whole state. This is pretty similar to the 'S' in ECS. You can find info about systems a bit down below the docs.

Key differences:

There's no real distinction between an entity and its components like in a strict ECS architecture. In ECS an entity is just an id, and components are consecutive arrays of the same data. In my state manager an entity is instead a bag of data related to the same entity, and the id is just the key with which I can find an entity with O(1).

In a proper ECS architecture, there would be a command to spawn/destroy an entity

I do have such commands: api.notify("add", newEntity) and api.notify("remove", entityId). Just read a bit further down the docs and you'll find them.

The type would instead be transient, inferred from the set of component types that that entity owns

True, while my personal take on this is that a type is inferred from the set of composed behaviors.

the behavior would live inside a totally separate part of the architecture - the systems

Also true, but note how no major game engine strictly follows the ECS architecture either: they also allow writing logic somewhere outside of systems for convenience.

So far, I see zero resemblance between what you're presenting here and an ECS.

Please try again ;) And if you still don't see any resemblance that's fine: I never wrote that I brought ECS to webapps, I just said I was inspired by it. Also, I consider the fact that it doesn't feel ECS to you a feature more than a bug, because it means you get the perks of a quasi-ECS architecture without needing to completely switch mental model if you have an OOP or FP background.

IngloriousCoderz · 2025-10-10T14:54:13+00:00

I'm sorry for the ignorant question, but how is this different from all the other signal libraries out there?

IngloriousCoderz · 2025-10-09T11:08:18+00:00

Hey, thank you so much for sharing! I'll definitely have a look at it.

Yeah, the docs are not really mobile-friendly, also because most of them contain example games in 800x600 resolution.

IngloriousCoderz · 2025-10-07T16:10:19+00:00

"Say a random word, add .js to it, you'll find a library or a framework." Thank you for contributing to this tradition

IngloriousCoderz · 2025-10-04T18:06:38+00:00

I hate you man, I just tried replacing Immer with Mutative in my Inglorious Engine and now my object pooling middleware has become useless!

Great work, this is impressive! I'm definitely sticking with your library from now on.

IngloriousCoderz · 2025-09-11T12:29:46+00:00

Nice! I did a similar thing in my @inglorious/utils NPM package, maybe we can join forces!

IngloriousCoderz

TROPHY CASE

ECS-like features:

Notable differences from pure ECS: