Box2D suggestes a physics engine for games which combines and model and view. Now I want to use MVC design pattern or a framework based on MVC design pattern such as Robotlegs of PureMVC in order to create a game. If I choose Box2D, is it true that Box2D breaks MVC concept? And if it is true, should I worry?
I don't feel the Box2D breaks the MVC concept at all (as long as we are talking about Model-View-Controller here...I often get lost in the acronym ocean ;).
The physics is part of the model. Not the entire model.
Consider the simulation of a missile in flight across a 2-D landscape (e.g. this). The "missile" has a model of how it moves. Part of that is the mass, moment of inertia, velocity, etc. This is the physical part of the simulation.
It also has some kind of "AI Code" to decide how much force to apply, how to turn the missile, etc. These or often called "steering" forces. This is the next level up of the simulation, the "getting things moving" part of it.
There is also a larger part of the model, the part that decides what to do when the missile hits something (which it gets from the physics). Or when to fire the missile in the first place. Or the route the missile should take.
You can go even higher, probably, but the point to take away from this is that at no point have I mentioned how the missile is displayed or presented to the user. That would be the view.
So, my take on all this:
The Model (in layers):
PHYSICS
MOVEMENT
LOGIC AND REASONING
OVERALL SIMULATION or STRATEGY
At no point is the View mentioned in any of these...they operate and exist regardless of whether they are displayed in 2-D, 3-D, or by balloons tied to chipmunks. The layers may interact with each other...the physics detect a collision that ends up causing change in state in the LOGIC AND REASONING layer, etc.
For completeness, the controller brings the user into this. The user "uses" the controller to manipulate the model. I've always felt this was a little hard to think about; I like concrete examples.
On the "hard core definition" level, the user uses the controller to give input to the model. So I touch the screen and the missile knows where it should fly towards. The model gets a command to "go here" and the AI of the missile takes this command and "runs with it".
On the other hand, the controller may also be used by the user to manipulate the view (which is not part of the "hard core mvc" definition. Consider a tablet applications where a pinch changes the viewport but a tap signals the missile to strike "this target". The first changes the view while the second changes the model. NOTE: This situation may be a manifestation of more modern forms of patterns derived from MVC, and not pure MVC.
Regardless, the physics is part of the model, not the whole model.
Was this helpful?
No, it's not true that Box2D breaks MVC. Box2D doesn't combine the model and view, in fact, quite the opposite. Box2D is completely agnostic about what you choose to render your view, so it's highly compatible with an MVC architecture.
Games are conceptually tricky when considering MVC because the model has many parallels with the view (unlike a business app). However, you still get lots of benefits from separating concerns in your architecture.
As Fuzzy says, Box2D is part of the game model.
MVC in a game looks like this:
Box2D will get wrapped in game model classes. Your rendering library (you haven't said what platform you're writing for) will get wrappped in your View classes. Any UI stuff goes in your Controllers.
If you want read more about how to use MVC for HTML5 Games using Box2DWeb (for physics) with EaselJS (view) in CoffeeScript, I've written more about it here.
Related
I have an interface (android activity, but that should not matter) with text input, spinners and a toggle button (all on one page). Depending on the state of all these elements I produce text output (on the same page).
Since the relationship is not trivial, I would like to somehow visualize the logic relationship between these elements. I am reading about UML, activity diagrams, etc but got a bit lost there.
What term should I look for? What program do you recommend to use for drawing such diagrams on computer (linux)?
UML Activity Diagrams might not be what you are looking for. They are usually used to model activities in a process. They tend to be more high-level and conceptual and less about the implementation.
From your question it reads as if you are working on the implementation itself. In that case I would urge you to look at UML State Diagrams. They are really neat when you want to think about different states your application (or components of your application) can be in. It also lets you logically decompose behaviour into states.
Furthermore, it is also a straight-forward way to model your application in a way that you can apply a Design Pattern, notably the State Pattern, to implement your model.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I have a conceptual question and believe Stack Overflow may be a great place to ask it. Often in my reading and learning I hear conversation of "layers" - and loosely defined layers, at that, it seems. Too, a lot of software jargon is used in describing these layers (so, for an entry-level guy or gal (like me), they each become difficult to get a grasp of).
So far, I have heard tell of three (3) layers that interact with each other and that make a program "run":
Business Logic Layer (BLL) - Wikipedia's got a great introductory article to this/
Application Logic Layer - that which is responsible for enabling the business logic layer to interact with boundary technologies
Presentation Layer (the layer I just learned of, today).
Here's my question (and it may not be possible to answer): how many of these layer "types" exist and - briefly - what are they?
I also encourage posting resources via hyperlink that people can consult, particularly as these layers do seem to be so loosely defined.
In this particular case, the layers are essentially a generalization of the Model View Controller system architecture. Briefly, they are:
BLL: The 'guts' of the application, if you will. This is the logic that works on your own internal data types and does, as the name suggests, the 'business logic' that makes your application actually work. It should be as independent as possible from any particular implementation of how the user might interact with the business logic. For example, if you were building a Tic Tac Toe game, the BLL would be the rules engine that does the actual work of tracking people's moves, determining who wins, etc.
ALL: The 'interface' between the BLL and all of the stuff that feeds data into the BLL. This is going to be much more specific to a particular application of the BLL. For example, if your Tic Tac Toe engine had the ability to save out the results of games, the ALL might provide an interface to a database engine that stores the results. It would also be responsable for interfacing the BLL with whatever PL you chose to use (text based, a GUI, etc).
PL: This is the 'front end' of your application that the user interacts with. This could be built from a complicated framework like Qt, or something simple like a text interface. Either way, it's generally completely independent in terms of implementation from the application it's trying to expose. To continue the Tic Tac Toe analogy, you could build a relatively generic 3x3 grid with shapes and a message output that just happens, via the ALL, to wind up displaying a Tic Tac Toe game. Now in practice they're rarely that decoupled, but the point is that you should try and keep any actual logic out of the PL, such that you can change the implementation of the BLL or ALL without having to touch your PL code as long as the interfaces stay the same.
These layers are loosely defined because they're just generalizations used to make visualizing the design of complex systems easier to reason about and to naturally guide development towards proper compartmentalization of functionality for maximum code reuse and component swappability, as well as allowing for more easily performing formal Verification and Validation and other QA tasks. There are many, many ways you can split up software design into 'layers', but these three are the ones that are typically formally described in Soft Eng course material. So there isn't really any specific 'number of layers' that you can talk about. How segmented a particular design is really depends on that specific domain and the 'buzzwords' in the industry at the time. You will however almost always find something akin to these three layers, sometimes broken into a few smaller chunks.
It is strange to me that the three concepts you list should be called "layers". They may be three components of a software system but they don't appear to lie on top of each other except in a crude PowerPoint block diagram.
The idea of layering relates to levels of abstraction in code development where lower layers provide the components used to build higher layers. The OSI model is a paradigm example.
There can be any number of layers in a particular software system depending on how many levels of dependency exist. Perhaps there are only one or two layers within the immediate application being developed, though that application is likely to be dependent on a larger stack of assumed sub-structure.
my problem is that we try to use a MVC (PHP) framework. After discussing a lot think that MVC is very good, but I'm missing the possibility to write reusable model-(application)logic. So, I'm not sure if we have the right approach to implement our software in a MVC framework.
First I´ll describe the non-MVC, oo-approach which we use at the moment.
For example - we are working on some browser games (yes that's our profession). Imagine we have an player object. We use this player object very often. We have some different pages where you can buy thinks, so you need to make "money" transactions on the players "bank-account" or imagine you can do fights against other players. We have several fight-scripts, and these scripts take 2 or more player objects (it depends on the type of battle ie. clan battle, player vs. player battle...).
So, we have several pages (and controllers) with different battle-logic. But each of this controllers use the player-object to calculate all the attributes and items a player has and which damage and defence a player will do.
so, how can we reuse the logic in the player object in case of a MVC Model? it would be bad to duplicate all the necessary logic in the different fight-controllers and -models.
I think the "gold-transaction"-logic would be a good example to give you some more detail information. you need the transact-function in case of a fight, if you win against an other player and loot some of his gold, you need the transaction function in case of buying some stuff and you need the transact-function in case of spending some gold to the players guild...
So, I would say it would be a bad approach to define all these functions in one player model! I can say you these player model would be very big (actually we have the problem that our player-class is really huge - its a god class)
do you think there is a MVC-style solution for this problem?
I would say you put the code where it makes the most sense, and where you would not need to duplicate it someplace else.
If there is some operation that always needs a Player object, but might be used across different Controllers, the Player class would be the logical place to put it. On the other hand, if a bit of logic only needs to be done in the context of a certain Controller, and involves potentially other classes, it perhaps should be in the controller - or perhaps in some other class, too.
If you are having trouble figuring out where the logic should go, perhaps it's because your functions are not granular and reusable enough as they are. There are certainly aspects of MVC that force you to think a little bit more about the separation of concerns and keeping things DRY more than a 'plain' OOP approach... so you might end up breaking up currently coded operations that are in a single function now into multiple functions on different classes to get the right code in the right places.
For example - and these are not at all specific suggestions, but just a random possible thought process - maybe the process of transferring 'gold' between players needs to be broken down into more granular processes. The player class may do the basic task of changing the balance, but then the controller(s) may do specific parts of the process, such as verifying to/from whom gold is being transferred and why.
There has been one more question on what data-oriented design is, and there's one article which is often referred to (and I've read it like 5 or 6 times already). I understand the general concept of this, especially when dealing with, for example, 3d models, where you'd like to keep all vertexes together, and not pollute your faces with normals, etc.
However, I do have a hard time visualizing how data-oriented design might work for anything but the most trivial cases (3d models, particles, BSP-trees, and so on). Are there any good examples out there which really embraces data-oriented design and shows how this might work in practice? I can plow through large code-bases if needed.
What I'm especially interested in is the mantra "where there's one there are many", which I can't really seem to connect with the rest here. Yes, there are always more than one enemy, yet, you still need to update each enemy individually, cause they're not moving the same way now are they? Same goes for the 'balls'-example in the accepted answer to the question above (I actually asked this in a comment to that answer, but haven't gotten a reply yet). Is it simply that the rendering will only need the positions, and not the velocities, whereas the game simulation will need both, but not the materials? Or am I missing something? Perhaps I've already understood it and it's a far more straightforward concept than I thought.
Any pointers would be much appreciated!
So, what is DOD all about? Obviously, it's about performance, but it's not just that. It's also about well-designed code that is readable, easy to understand and even reusable.
Now Object Oriented design is all about designing code and data to fit into encapsulated virtual "objects". Each object is a seperate entity with variables for properties that object might have and methods to take action on itself or other objects in the world. The advantage of OO design is that it's easy to mentally model your code into objects because the whole (real) world around us seems to work in the same way. Objects with properties that can interact with each other.
Now the problem is that the cpu in your computer works in a completely different way. It works best when you let it do the same things again and again. Why is that? Because of a little thing called cache. Accessing RAM on a modern computer can take 100 or 200 CPU cycles (and the CPU has to wait all that time!), which is way too long. So there's this small portion of memory on the CPU that can be accessed really quickly, cache memory. Problem is it's only a few MB tops. So every time you need data that wasn't in cache, you still need to go the long way to RAM. That's not just that way for data, the same goes for code. Trying to execute a function that's not in instruction cache will cause a stall while the code is loaded from RAM.
Back to OO programming. Objects are big, but most functions need only a small portion of that data, so we're wasting cache by loading unnecessary data. Methods call other methods which call other methods, thrashing your instruction cache. Still, we often do a lot of the same stuff over and over again. Let's take a bullet from a game for example. In a naive implementation each bullet could be a separate object. There might be a bullet manager class. It calls the first bullet's update function. It updates the 3D position using the direction/velocity. This causes a lot of other data from the object to be loaded into the cache. Next, we call the World Manager class to check for a collision with other objects. This loads lots of other stuff into the cache, maybe it even causes code from the original bullet manager class to get dropped from instruction cache. Now we return to the bullet update, there was no collision, so we return to bullet manager. It might need to load some code again. Next up, bullet #2 update. This loads lots of data into the cache, calls world... etc. So in this hypthetical situation, we've got 2 stalls for loading code and let's say 2 stalls for loading data. That's at least 400 cycles wasted, for 1 bullet, and we haven't taken bullets that hit something else into account. Now a CPU runs at 3+ GHz so we're not going to notice one bullet, but what if we've got 100 bullets? Or even more?
So this is the where there's one there's many story. Yes, there are some cases where you've only got on object, your manager classes, file access, etc. But more often, there's a lot of similar cases. Naive, or even not-naive object oriented design will lead to lots of problems. So enter data oriented design. The key of DOD is to model your code around your data, not the other way around as with OO-design. This starts at the first stages of design. You do not first design your OO code and then optimize it. You start by listing and examining your data and thinking out how you want to modify it(I'll get to a practical example in a moment). Once you know how your code is going to modify the data you can lay it out in a way that makes it as efficient as possible to process it. Now you may think this can only lead to a horrible soup of code and data everywhere but that is only the case if you design it badly (bad design is just as easy with OO programming). If you design it well, code and data can be neatly designed around specific functionality, leading to very readable and even very reusable code.
So back to our bullets. Instead of creating a class for each bullet, we only keep the bullet manager. Each bullet has a position and a velocity. Each bullet's position needs to be updated. Each bullet has to have a collision check and all bullets that have hit something need to take some action accordingly. So just by taking a look at this description I can design this whole system in a much better way. Let's put the positions of all bullets in an array/vector. Let's put the velocity of all bullets in an array/vector. Now let's start by iterating allong those two arrays and updating each position value with it's corresponding velocity. Now, all data loaded into the data cache is data we're going to use. We can even put a smart pre-loading command to already pre-load some array data in advance so the data's in cache when we get to it. Next, collision check. I'm not going into detail here, but you can imagine how updating all bullets after each other can help. Also note that if there's a collision, we're not going to call a new function or do anything. We just keep a vector with all bullets that had collision and when collision checking is done, we can update all those after each other. See how we just went from lots of memory access to almost none by laying our data out differently? Did you also notice how our code and data, even though not designed in an OO way any more, are still easy to understand and easy to reuse?
So to get back to the "where there's one there's many". When designing OO code you think about one object, the prototype/class. A bullet has a velocity, a bullet has a position, a bullet will move each frame by it's velocity, a bullet can hit something, etc. When you think about that, you will think about a class, with velocity, position, and an update function which moves the bullet and checks for collision. However, when you have multiple objects you need to think about all of them. Bullets have positions, velocity. Some bullets may have collision. Do you see how we're not thinking about an individual object any longer? We're thinking about all of them and are designing code a lot differently now.
I hope this helps answer your second part of the question. It's not about whether you need to update each enemy or not, it's about the most efficient way to update them. And while designing only your enemies using DOD may not help gain much performance, designing the entire game around these principles (only where applicable!) may lead to a lot of performance gains!
So onto the first part of the question, that is other examples of DOD. I'm sorry but I don't have that much there. There is one really good example though, I came across this some time ago, a series on data oriented design of a behavior tree by Bjoern Knafla: http://bjoernknafla.com/data-oriented-behavior-tree-overview You probably want to start at the first one in the series of 4, links are in the article itself.
Hope this still helps, despite the old question. Or maybe some other SO user come across this question and have some use from this answer.
I read the question you linked to and the article.
I've read one book on the subject of data driven design.
I'm pretty much in the same boat as you.
The way I understand Noel's article is that you design your game in the typical object oriented way. You have classes and methods that work on the classes.
After you've done your design, you ask yourself the following question:
How can I arrange all of the data I've designed in one huge blob?
Think of it in terms of writing your entire design as one functional method, with lots of subordinate methods. It reminds me of the massive 500,000 line Cobol programs of my youth.
Now, you probably won't write the entire game as one huge functional method. Really, in the article, Noel is talking about the rendering portion of a game. Think of it as a game engine (the one huge functional method) and the code to drive the game engine (the OOP code).
What I'm especially interested in is the mantra "where there's one there are many", which I can't really seem to connect with the rest here. Yes, there are always more than one enemy, yet, you still need to update each enemy individually, cause they're not moving the same way now are they?
You're thinking in terms of objects. Try thinking in terms of functionality.
Each enemy update is an iteration of a loop.
What's important is that the enemy data is structured to be in one memory location, rather than spread across enemy object instantiations.
I'm trying to build a very light re-usable framework for my games, rather than starting from scratch each time I start a game. I have a component driven architecture - e.g. Entity composes a Position component and a Health component and Ai component etc.
My big question is whether my model composes view components to allow for more than one view of the model, or whether to use a truer MVC where the model does not know about its views, and they are managed externally.
I have tried both methods but if anyone knows the pros and cons of each approach and which is the industry standard, it would be great to know.
depends on your audience, game devs, myself included aren't very used to the MVC model, although most know it, it's not as easy to keep it clean cut, because of development casualties (not any serious technical reasons). So from experience, I've seen dozens of game frameworks start as MVC, but only a pair were able to maintain it until the end. My theory is MVC adds too much complexity and little benefits for small throwaway games (with normally a few devs), and it's to hard to keep really cleanly separate most game objects into these layers for large/complex games. And since games have a release date, they many times sacrifice code clarity and reusability for performance and quick adhoc solutions (that will get rewritten if necessarry in the sequel (if there is one)).
However, with the caveat above, it's better to aim high, because if you succeed it's better :) and if you fail, well to bad. So you should probably try the MVC, but don't worry if it fails, profesional game devs have all failed at the task many times :)
I’d certainly vote for the model to know nothing about its views. Loose coupling is good: Simpler model code, easier testing, more choices.
I know this question might be outdated, but I need to reply on it.
Actually, I started programming a game in Lua (with LÖVE) and I started programming a MVC - Framework for it.
At first, to use MVC really depends on what you want.
I know my problems with game programming, when the program becomes bigger, and mostly the structure becoms too complex to maintain.
Next thing is, I know that I will change all the graphics when I find an artist who is willing to work for it. But until then, I'm gonna use my own dummy graphics.
I want the artist to feel free to do what ever he wants, without beeing dependend on any resolution or color restriction.
That means, I might have to change the whole (!) presentation code. Maybe even the way objects interact (collision detection, f.e.).
The game logic is captured in the models, so I can concentrate on that. And I think game logic is the most important part of making a game. Isn't it?
Hope you see my point.
But, if you have everything together: all the graphics, sounds, the whole thing; then you can code straight forward.
My MVC is a configuration-over-convention-ass, that slows down prototyping a bit.
BUT(!) iterations of development can be made much more easily. Testing, especially Unit-Tests are done much more faster.
I would say MVC turns you development-speed-curve (which is normally an anti-exponential curve) into an exponential curve. Slow at the beginning, but more and more fast at the end.
MVC works really well for games, at least for my games which are designed for cross-platform.
It really depends on how you implement it in order to get the benefit.