Sign in to follow this  
Fujikatoma

Javascript Game Engine Architecture

Recommended Posts

Fujikatoma    106

Hey,

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

Here es my current Architecture of the Engine

LoynRub.png

 

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

 

Share this post


Link to post
Share on other sites
jpetrie    13149

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.

Share this post


Link to post
Share on other sites
Fujikatoma    106

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 rolleyes.gif )

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

Share this post


Link to post
Share on other sites
frob    44971

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.

Share this post


Link to post
Share on other sites
Glass_Knife    8636

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.

Edited by Glass_Knife

Share this post


Link to post
Share on other sites
Fujikatoma    106

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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this