Hey,

i'm working on a Html5 Engine with Javascript for a small Dungeon scroller.

Here es my current Architecture of the Engine

What should i change or do better ? It's only a basic architecture but i hope its logic.

UML is very high-level and generic. It seems reasonable on the surface, but that's about all you can say.

Is there a specific aspect of the architecture you are unsure or unhappy about? If so, and you provide some more detail than some basic boxes and arrows, then you may get some more detailed analysis.

My problem is , i don't know how to continue with the architecture and hoped that i get some feedback (If the architecture is efficent or not )

But i think now the best way to continue is to start programming

There are many things that seem to be missing, but considering what you are likely to do with it, the high level boxes are fine.

UI ties to sprite and to object, but apparently not to input. Not sure how you're doing that, but that's okay.

Usually animations have a direct link both to events and to audio. This lets an animator drop a tag in an animation that triggers some game behavior or some audio. Then animators can modify other parts of the animation triggers on frame 47 for this one, or triggers on frame 63 for this other one. Similarly for events, animators could add an event that tells code to destroy or hide an object once animation frame 19 happens.

I'm not particularly clear on the the difference between Objects and Units. Is a Unit not an Object? With only your collection of boxes and arrows, who knows if there is more or less to it.

There are many things that seem to be missing, but considering what you are likely to do with it, the high level boxes are fine.

UI ties to sprite and to object, but apparently not to input. Not sure how you're doing that, but that's okay.

Usually animations have a direct link both to events and to audio. This lets an animator drop a tag in an animation that triggers some game behavior or some audio. Then animators can modify other parts of the animation triggers on frame 47 for this one, or triggers on frame 63 for this other one. Similarly for events, animators could add an event that tells code to destroy or hide an object once animation frame 19 happens.

I'm not particularly clear on the the difference between Objects and Units. Is a Unit not an Object? With only your collection of boxes and arrows, who knows if there is more or less to it.

Input ->Physik(if needed)->Object (UI)

In preparing for battle I have always found that plans are useless, but planning is indispensable.

Dwight D. Eisenhower

This is very important to remember when trying to develop an API or architecture at a high level. The low-level will drive the design. You cannot get around the limitations of the hardware, OS, or language. Follow your design, but don't stick with it no matter what, or you may find that if you follow your design to the letter it will not work.

Ultimately, there will be some low-level assumptions that are wrong, that will cause changes in the design. You can't code around them. For instance, If you design your system with an assumption about web-sockets, only to find that web-sockets can't do what you need, but the API requires that it works that way, you will be tempted to work around it, add hacks, or just sledge hammer it.

Don't fall in love with your design, and you'll be fine.

Thanks for this tipps so far.