Jump to content
  • Advertisement
Sign in to follow this  

Should I store graphics like this? Also, is this a bloated system?

This topic is 2536 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm making a small test game but who knows, I may take it further if I like the look of it. For this reason I want to make sure my game is easy on memory and processing.

In my game I have a class called "Entity". An entity is something that is not a part of the terrain or a controllable element. It serves one purpose. It may be a building, gate, gun turret, moving platform, etc. An entity holds onto an object called a "SpriteMap". A spritemap holds an array of "Sprite"s. A sprite holds and array of "Frame"s.

The relation can be seen in this diagram.


In MVC theory I don't believe you should do any processing in the Model or View other than what is most basically necessary. My Model doesn't even have any methods or even a constructor, just a bunch of variables. I haven't written view yet because I'm stuck not knowing which direction I should take on drawing the sprites. My options are

1. Leave the spritemap and sprites alone but store all possible features and construct a temporary image of its state at every draw interval.
This would require me to either piece the image together in the Controller (despite MVC theory) or send the View a massive amount of variables relating to the sprite. This would mean I only store one image of each spritemap and it wouldn't be very easy on the memory but would make the coding more confusing and harder to manage. Additionally it would be difficult to update.

2. Give each entity its own spritemap (even of the same image) and allow the spritemap itself to regularly update the image. Then I can use the controller to move the image to the view and the view won't need to concern itself with any details.
This would be simpler and easier to manage but may cost a lot of memory. Lets say I had 1000 entities running at the same time. What problems could I run into?

Am I overestimating the cost of memory? And possibly underestimating how much available memory the average person has?

Also as a side note. Is this proper MVC and do you think this method I am using with spritemaps, sprites, and frames is a good one? I'm new to MVC

Share this post

Link to post
Share on other sites
You'll have to excuse my ignorance if this is a common way of doing things in game development, I'm not that great with game development myself and am still very much learning.

I am however a professional developer of both web and desktop applications, and understand the MVC pattern inside out from that.

But my first question is, why are you trying to mangle the MVC pattern into this type of role? Is it really the best pattern for this type of thing? It's well suited to many applications but I'm struggling to see why you'd want to use it here?

Essentially, MVC is about separating your user interface from the data that the user interface displays, or manipulates.

The view should display the user interface, and should take any user input and pass that to the controller.

The controller should receive that input, which, in web frameworks, may be as simple as a GET request from a user entering a URL into their browser, and it should pass details of that input to the model

The model then may do some kind of update on the data or similar, and the controller will then pass anything it needs to pass from the model back into the view.

In a web framework, your model will act as your interface for the data layer- it will often be just a set of plain on classes that pull data from the database and store it in variables for the controller to access. The controller will be the class that handles requests for a set of pages, such that if you request www.blahblah.com/blah/hello then you will probably have a controller class called blah, and a function in it called hello to handle that request. The hello function may then create an instance of a specific model class, take some properties from that instance and pass it to the view. The view will just be an HTML page, likely with a small bit of scripting in it to display those passed properties from the controller.

I think the question you have to ask is is there any benefit to separating the drawing from the underlying data? In web frameworks and so forth it's useful because it means the web designers can bugger off independently of what the back end developers are doing and can manipulate the HTML front end all they want, and as long as the controller still passes down the same properties they need it'll just work. The decoupling of the view from back end processing makes it trivial for multiple developers and designers to work on the project without getting in each others way. It means the UI focus can focus on what they're best at, and the back end folk can do what they're best at, with the controller effectively acting as an interface between the two. There are other benefits, in that personally I just find MVC based sites far easier to manage and work with (even if I'm doing all of it, model, view, and controller) but for the most part it's benefits are in decoupling the user interface from the data layer.

So now that you know what MVC is, and tries to achieve, this may at least frame things a bit better for you. Maybe others here have experience of mangling MVC into this sort of thing and it is a done thing, but personally I don't think this is a sensible use of the MVC pattern- it does strike me as a case of over-engineering the problem. Is there any advantage to separating the view from the back end data in your case? or are you just creating more difficulties than the benefits MVC would provide?

Share this post

Link to post
Share on other sites

In MVC theory I don't believe you should do any processing in the Model or View other than what is most basically necessary. My Model doesn't even have any methods or even a constructor, just a bunch of variables.
Then it isn't much of a model. What can you do to its data? Anything. What does it do for you? With trivial data structures, nothing. What invariants does it guarantee? None. A Model should provide basic, meaningful operations that preserve data integrity and consistency; typically this means executing some nontrivial atomic transaction in a database, but in games there are all sorts of complex data structures to update (for example, when you create an entity it is put it into a spatial index and its sprite is added to a vertex buffer).

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!