Topics

1

Window / Invisible window on top of visible one

« on: November 28, 2012, 08:56:20 pm »

I'm currently working on a little game for a project.
My game is designed around a Model-View-Controller pattern. This is where I hope SFML will help me. The ideal idea was to have two separate windows: one that catches input (controller) and one that gives the user some juicy graphics (view). The controller would send some self-defined events to my model (game logic) every grame, the game would update itself accordingly and the view would query the model for a visual update. As said, this would be ideal.

In order for this to work I'd need to create an invisible window that would capture input at all times and a visible window that would never get focus: it's only there for the graphics. A little link has to be laid between them in case of rescaling, quitting,..

This is all still hypothetically speaking. How much of this can I actually realize? Any comments on the matter would be greatly appreciated.


Ruben

2

General / Best way to divide data and view?

« on: November 09, 2012, 09:17:44 am »

I'm not quite sure if this question belongs in the SFML forums, but I'll try it out anyway.

I'm a 19 year old student writing a small game for a long term project. Since I've used SFML before (for visual train simulation with my own graphics engine) I immediately decided it would be my graphics library for this project.

The problem is now: how do I go about dividing data and view in an orderly fashion? I want the blueprints to be just right from the start so I won't have to make any major changes later on. An older colleague has adviced me to use the MVC (Model-View-Controller) model but I haven't found a way just right to implement it.

Just to sketch you some context: The game will be 2D topview. I've got a couple of base classes: graphs and nodes and an abstract factory. All entities or game tiles will be nodes, which the graph will hold. The abstract factories will take care of producing these when asked. The derived class from the graph you can call the PlayField as it will hold the obstacles on the screen and generally decide what the screen should look like as it also holds all entities.

Now.. Just to repeat that tiny, simple-looking question. How best to set up my graphics? One single graphics object that communicates with the playfield to communicate through changes, both ways? One graphical representation object for each entity in the game?

Any help would be greatly appreciated. Same goes for sharing experience: I've got few but I'm determined. Share what you can!