[Focus in] Design patterns and paradigms
This page is about design patterns, programming paradigms in game developing and those supported in AtomCore. NOT*very good*
Programming paradigms
Programming generally and programming languages usually designed toward a paradigm, but some of them are multi-paradigm also.
Java programming language
*Java* is a computer programming language that is concurrent, class-based, object-oriented, (mostly) imperative, structured (also referred as strictly typed)
emoji:sunglasses Suppose that when you read this wiki you already know what Java is (partly)
Groovy…
is an agile and dynamic language for the Java Virtual Machine builds upon the strengths of Java but has additional power features inspired by languages like Python, Ruby and Smalltalk
Game Programming paradigms
Game framework or game engines also be comparasion (along with its programming language) into some category (not include graphics capacity):
By
Entity System
By concurrent capicity
Active
Reactive
Interactive
Design patterns
Design patterns in game developing
Singleton . Central . Law of detemer
Lightweight & Decorator
Inversion of Control
Factory
MVC & MVC?
MPV: Model View Presenter is the two way of MVC Model View Controller; where Presenter is the middle-man, the mediator between Model and View know and get notificated by both Model and View.
Talk about MVC first: Assume you know about web
Push-based vs. pull-based
Most MVC frameworks follow a push-based architecture also called “action-based”. These frameworks use actions that do the required processing, and then “push” the data to the view layer to render the results.[5] Struts, Django, Ruby on Rails, Symfony, Yii, Spring MVC, Stripes, Play, CodeIgniter, and Struts2[6] are good examples of this architecture. An alternative to this is pull-based architecture, sometimes also called “component-based”. These frameworks start with the view layer, which can then “pull” results from multiple controllers as needed. In this architecture, multiple controllers can be involved with a single view. Lift, Tapestry, JBoss Seam, JavaServer Faces, and Wicket are examples of pull-based architectures.
MVC Push was born in the world of “none frequent” and not suite well for kind of application almost done update every-frame. So there is some kind of Event,Action embed on it.
MVC Pull in another hand, suite better for “frequent update” and assume that View is the one trigger the update call.
Back to real-time game, if you not making a chess game, almost you “are doing” a pull based MVC, or apply this pattern privately.
Design patterns in JME3
Here some analysing about patterns in JME3 world so Atom bypass or inherit them.
Push or pull ?
worth to note: even some part of JME3 assemble MPV, it’s not the whole! also for a game, apply MPV is quite annoying and also tricky!
because of this cycle