Open World Soccer Forum Index Open World Soccer
Community Forum
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Some thoughts

 
Post new topic   Reply to topic    Open World Soccer Forum Index -> Programming
View previous topic :: View next topic  
Author Message
mkko



Joined: 16 May 2008
Posts: 15

PostPosted: Wed May 21, 2008 8:20 pm    Post subject: Some thoughts Reply with quote

I must apologize my enthusiasm, but now that I'm still excited about the subject, I listed some outlined thoughts about the game states. I don't mean to get ahead of ourselves, but I had some extra boring time at work :) I just try to use my springtime energy for something seemingly productive.

Code:
- screen handles different game states
    - screen is responsible only for one specific state
        - splash screen, main menu, options menu, gameplay, pause, etc.
        - the gameplay state would be the most complicated of these
            - initially this could be the demo and later on would be cleaned up and reconstructured
    - a screen can have an overlay screen
        - if there is, depending on the host screen, the control should be directed to the overlay
        - a pause screen, error dialog, menu over the gamplay screen, etc.
    - screen decides the next screen to be invoked
        - thus the state transitions are defined by screens
            - for example a return value of an update() function call
- a game class represents the state machine
    - updates the active screen
        - initializes and (as in screen.init()) closes when needed
    - is responsible for transitions from screen to another
        - doesn't need to know any details about the transitions
            - a factory pattern could be used
        - handles the information/data passed from one screen to another
        - close the active screen, initialize the new screen (via base class pointer)
    - game class holds the global configuration and settings of the game
        - updates the global/relative time (if this is needed)
            - could be passed as a parameter for screen updates
            - or screen could ask this explicitly
    - might be a static class, implementing singleton design pattern
- a factory creates a screen for the given identifier
    - enum ScreenType {NONE, SPLASH, MAIN, GAMEPLAY, ...};
    - no changes to the game class' update logic when adding a new screen
    - this can be implemented as a member function in game class or as its own class
        - Screen* createScreen(ScreenType type);
        - a screen could create an overlay for itself with this
            - either a static factory class or a reference to the game is needed
- main loop updates the game class which updates the active screen which updates the overlay (if there is)

And finally, here are some random issues I came across while thinking about the general architecture:
  • Does the SDL provide some method to prevent the game running too fast? If not, I think this has to be implemented in the game class to provide the time (or time interval) between updates and update accordingly.
  • How should the game objects interact? I've found that one convinient way is to separate drawing and game update logic so, that object only holds the information needed to draw it (position, rotation, sprite and other info).
  • The above could be applied also to the physics, though I doubt there will be any actual engine. Something to check the collisions might be nice and perhaps it should be the one to control the ball. If so, this something should see every player and somehow know if some player has the ball. It might be nice to tell the player also :)
  • How about controlling the players? Should human player control only the one being nearest to the ball and others would be computer controlled players? Who tells players where they are needed? Players could have some sort of
  • How should the replay work? In the racing game project I was partly responsible for the implementation of the replay feature. At that time we solved the problem simply by recording the input as the outcome was always deterministic. I think one possible solution could be recording the input of each player's controls, but that would require some control mechanism for players. Recording only sprite positions would lose some information which could be useful in some bizarre events. This could be replayed with the program as if it actually happened.
  • What about the variation points in the software? Graphics, AI, what else?
  • How about discussion about each and every tiny little detail? Is there any? :)

ps. Once again I apologize. I have too many things on my mind right now. Sorry for the burst :)
Back to top
View user's profile Send private message
Massimo32
Site Admin


Joined: 11 Nov 2007
Posts: 177
Location: Bolzano, Italy

PostPosted: Thu May 22, 2008 12:13 am    Post subject: Re: Some thoughts Reply with quote

I add some comment on what is already implemented in some way in OWS...

mkko wrote:
Does the SDL provide some method to prevent the game running too fast? If not, I think this has to be implemented in the game class to provide the time (or time interval) between updates and update accordingly.

There's a Timer class with a wait method. It works like WaitTimer in BlitzMax and returns a number of frames to process (that normally should be =1). This ensure the game to run at a fixed framerate (and can skip one or more frame in case of problems, e.g. the pc is overloaded)

mkko wrote:

The above could be applied also to the physics, though I doubt there will be any actual engine. Something to check the collisions might be nice

At present the collisions are based only on math (distance), i.e. not pixel collisions.

mkko wrote:

and perhaps it should be the one to control the ball. If so, this something should see every player and somehow know if some player has the ball. It might be nice to tell the player also Smile
How about controlling the players? Should human player control only the one being nearest to the ball and others would be computer controlled players? Who tells players where they are needed? Players could have some sort of

The intention is to have two modes:
1) auto, like YS, one device control an automatically chosen player of the team, max 1 player for each team
2) locked, each device controls one player, multiplayer in the same team is possible

mkko wrote:

How should the replay work? In the racing game project I was partly responsible for the implementation of the replay feature. At that time we solved the problem simply by recording the input as the outcome was always deterministic. I think one possible solution could be recording the input of each player's controls, but that would require some control mechanism for players. Recording only sprite positions would lose some information which could be useful in some bizarre events. This could be replayed with the program as if it actually happened.

The replay in YS was nice, because more subframes were recorded for each frame. In this way, during the replay, it was possible to have a very fluid slow motion. This already has been ported to OWS.

mkko wrote:

What about the variation points in the software? Graphics, AI, what else?

"variation points" Question
Back to top
View user's profile Send private message
mkko



Joined: 16 May 2008
Posts: 15

PostPosted: Thu May 22, 2008 12:13 pm    Post subject: Re: Some thoughts Reply with quote

Massimo32 wrote:
mkko wrote:
Does the SDL provide some method to prevent the game running too fast? If not, I think this has to be implemented in the game class to provide the time (or time interval) between updates and update accordingly.

There's a Timer class with a wait method. It works like WaitTimer in BlitzMax and returns a number of frames to process (that normally should be =1). This ensure the game to run at a fixed framerate (and can skip one or more frame in case of problems, e.g. the pc is overloaded)

This is nice.

Massimo32 wrote:
mkko wrote:

The above could be applied also to the physics, though I doubt there will be any actual engine. Something to check the collisions might be nice

At present the collisions are based only on math (distance), i.e. not pixel collisions.

Do you think pixel collisions would work better? If the game is as fast-paced as SWOS is, I think the difference is marginal.

Massimo32 wrote:
mkko wrote:

and perhaps it should be the one to control the ball. If so, this something should see every player and somehow know if some player has the ball. It might be nice to tell the player also :)
How about controlling the players? Should human player control only the one being nearest to the ball and others would be computer controlled players? Who tells players where they are needed? Players could have some sort of

The intention is to have two modes:
1) auto, like YS, one device control an automatically chosen player of the team, max 1 player for each team
2) locked, each device controls one player, multiplayer in the same team is possible

This sounds promising :)

Massimo32 wrote:
mkko wrote:

How should the replay work? In the racing game project I was partly responsible for the implementation of the replay feature. At that time we solved the problem simply by recording the input as the outcome was always deterministic. I think one possible solution could be recording the input of each player's controls, but that would require some control mechanism for players. Recording only sprite positions would lose some information which could be useful in some bizarre events. This could be replayed with the program as if it actually happened.

The replay in YS was nice, because more subframes were recorded for each frame. In this way, during the replay, it was possible to have a very fluid slow motion. This already has been ported to OWS.

It its way easier to replay the recorded frames and if it's already been implemented, I think there are lots of better things to do. Simply recording the frames we lose the possibility to move the camera during the replay. This isn't too big a thing though.

Massimo32 wrote:
mkko wrote:

What about the variation points in the software? Graphics, AI, what else?

"variation points" :?:

Those not too small things that are subject to change. With AI, I meant to say "player control". I don't know how should the possible multiplayer game over network work, but does the network somehow affect players' controls? Are there any other things that might affect the architecture, such as special game modes?

And I sincerely hope that you leave the possibility to use the old-school graphics. I think lots of people (including me) are attracted to those graphics. The game looking like original SWOS gives a first impression of nostalgy and everything that was great about the original game. I don't mean to say that the new graphics are worse or anything, they're nice, only that I think the game would be more easily approached and would give better first impression if it looked like SWOS.

I never actually asked this directly, just started throwing my ideas at you guys, but how could I be of assistance?
Back to top
View user's profile Send private message
Massimo32
Site Admin


Joined: 11 Nov 2007
Posts: 177
Location: Bolzano, Italy

PostPosted: Thu May 22, 2008 10:55 pm    Post subject: Re: Some thoughts Reply with quote

mkko wrote:

Do you think pixel collisions would work better? If the game is as fast-paced as SWOS is, I think the difference is marginal.

I think that pixel collision is good for a "flat" game (e.g. a platform).
In our case a collision depends on the position on a "virtual" 3D space (e.g. the ball hitting a goal post).

mkko wrote:
Massimo32 wrote:

The intention is to have two modes:
1) auto, like YS, one device control an automatically chosen player of the team, max 1 player for each team
2) locked, each device controls one player, multiplayer in the same team is possible

This sounds promising Smile

Probably it would be also possibile to have also a mixed mode, with one or more players "locked" to an input device and one "auto" the remaining players.


mkko wrote:

Those not too small things that are subject to change. With AI, I meant to say "player control". I don't know how should the possible multiplayer game over network work, but does the network somehow affect players' controls? Are there any other things that might affect the architecture, such as special game modes?


The first goal is to have the features of YS with a better gameplay and a new menu. Networking would be nice, but I don't know how this might affect the architecture .

mkko wrote:

And I sincerely hope that you leave the possibility to use the old-school graphics. I think lots of people (including me) are attracted to those graphics. The game looking like original SWOS gives a first impression of nostalgy and everything that was great about the original game. I don't mean to say that the new graphics are worse or anything, they're nice, only that I think the game would be more easily approached and would give better first impression if it looked like SWOS.


Probably we cannot use SWOS graphics, but it would be quite easy for anybody to make a "mod".

mkko wrote:

I never actually asked this directly, just started throwing my ideas at you guys, but how could I be of assistance?


Start with anything you like, experimenting with the code...
There's something you think you can be of help or you're good at?
Or something you think it's important to do in this stage?
Do you want to help me to finish the demo or to try to compile it for Win or Mac?
Back to top
View user's profile Send private message
mkko



Joined: 16 May 2008
Posts: 15

PostPosted: Sun May 25, 2008 3:15 pm    Post subject: Re: Some thoughts Reply with quote

Massimo32 wrote:

mkko wrote:

Do you think pixel collisions would work better? If the game is as fast-paced as SWOS is, I think the difference is marginal.

I think that pixel collision is good for a "flat" game (e.g. a platform).
In our case a collision depends on the position on a "virtual" 3D space (e.g. the ball hitting a goal post).

Um, so the pixel collisions were mentioned only as opposite to the math based collisions? I think there's no easy way to use pixel collisions in this kind of setup so I guess we're saying the same thing :)

Massimo32 wrote:

The first goal is to have the features of YS with a better gameplay and a new menu. Networking would be nice, but I don't know how this might affect the architecture .

My point was that if there were something someone might now that would affect something :) I think separating the actual gameplay from the menus will help a lot in future changes (this is pretty obvious). If a game were started only by giving the needed parameters to the class responsible for it (teams/players, play time, will there be overtime or penalties, ...), I think it would be flexible enough for the basic features.

Massimo32 wrote:

mkko wrote:

And I sincerely hope that you leave the possibility to use the old-school graphics. I think lots of people (including me) are attracted to those graphics. The game looking like original SWOS gives a first impression of nostalgy and everything that was great about the original game. I don't mean to say that the new graphics are worse or anything, they're nice, only that I think the game would be more easily approached and would give better first impression if it looked like SWOS.

Probably we cannot use SWOS graphics, but it would be quite easy for anybody to make a "mod".

Didn't Yoda Soccer have SWOSsy graphics and customizable kits? I just think that this graphical style is what separates the game from other minimalistic soccer games. The use of original SWOS graphics is naturally questionable as they belong to Sensible Software.

Massimo32 wrote:

mkko wrote:

I never actually asked this directly, just started throwing my ideas at you guys, but how could I be of assistance?

Start with anything you like, experimenting with the code...

This is what I've been doing for now.
Massimo32 wrote:

There's something you think you can be of help or you're good at?
Or something you think it's important to do in this stage?

Well, I like thinking in OOP. If/when this game is reconstructed, I think it should be the first thing to create some sort of game state based structure. If the outlining for the screen-based architecture in the first message sounds fine to you, I could implement an initial version of it. This would have nothing to do with the gameplay, it would only enable menus and other views than the gameplay.
Massimo32 wrote:

Do you want to help me to finish the demo or to try to compile it for Win or Mac?

I've been trying to compile it on OS X for now. Some includes seem to differ ("SDL.h" vs. <SDL/SDL.H>) and I don't know how to compile it without XCode at the time or if it will compile on Tiger at all (I'm using Leopard and Xcode 3). I've installed the SDL, SDL_image and boost libraries and I think they should work except for the boost. I got some linker errors from boost libraries and now I'm trying to find about setting proper search directories in Xcode.

I have no Linux at the moment, but I'd like to install one to a laptop I got from work. Until then I really can't help with the demo, since I never were good at blind coding :)
Back to top
View user's profile Send private message
Massimo32
Site Admin


Joined: 11 Nov 2007
Posts: 177
Location: Bolzano, Italy

PostPosted: Sun May 25, 2008 3:55 pm    Post subject: Re: Some thoughts Reply with quote

mkko wrote:

Didn't Yoda Soccer have SWOSsy graphics and customizable kits? I just think that this graphical style is what separates the game from other minimalistic soccer games. The use of original SWOS graphics is naturally questionable as they belong to Sensible Software.

After some initial experiments with new graphics, we decided to use the graphics from Yoda Soccer. Menus will be renewed, you can see a background and some buttons in images/menu.

mkko wrote:

Well, I like thinking in OOP. If/when this game is reconstructed, I think it should be the first thing to create some sort of game state based structure. If the outlining for the screen-based architecture in the first message sounds fine to you, I could implement an initial version of it. This would have nothing to do with the gameplay, it would only enable menus and other views than the gameplay.

If you can already implement an initial version of it, that would be very nice! Smile

mkko wrote:

I have no Linux at the moment, but I'd like to install one to a laptop I got from work. Until then I really can't help with the demo, since I never were good at blind coding Smile


Ok, meanwhile I'll finish the demo and I'll try to compile it in Windows.
Back to top
View user's profile Send private message
mkko



Joined: 16 May 2008
Posts: 15

PostPosted: Sun May 25, 2008 5:05 pm    Post subject: Re: Some thoughts Reply with quote

\o/

I managed to run OWS on OS X! I didn't exactly take the shortest and cleanest way to do this, but here are some changes I made to make it work after installing the required libraries:
  • Added a cocoa framework to handle the OS X related stuff (I used an SDL Application template).
  • Added the missing frameworks (SDL_image, OpenGL, GLUT, ) to this project and added some references to the search paths.
  • To solve the issue with boost library linkings, added a reference to "libboost_program_options-mt-1_35.dylib" into the project
  • Changed the includes:
    Code:
    #ifdef __APPLE__
    #include <SDL.h>
    #include <SDL_image/SDL_image.h>
    #include <OpenGL/glu.h>
    #else
    #include <SDL/SDL.h>
    #include <SDL/SDL_image.h>
    #include <GL/glu.h>
    #endif

  • And finally changed the code and added casts to draw_texture_rect() function:
    Code:
    glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_WIDTH, (GLint*)&tw );
    glGetTexLevelParameteriv(GL_TEXTURE_2D, 0, GL_TEXTURE_HEIGHT, (GLint*)&th );

Massimo32 wrote:

mkko wrote:

Well, I like thinking in OOP. If/when this game is reconstructed, I think it should be the first thing to create some sort of game state based structure. If the outlining for the screen-based architecture in the first message sounds fine to you, I could implement an initial version of it. This would have nothing to do with the gameplay, it would only enable menus and other views than the gameplay.

If you can already implement an initial version of it, that would be very nice! :)

I could start working on it and try to make it as flexible as possible. For the next few weeks I might have some other obligations, so it might take some time. If you're starting to need the code, even if half-finished, please let me know.

Massimo32 wrote:

mkko wrote:

I have no Linux at the moment, but I'd like to install one to a laptop I got from work. Until then I really can't help with the demo, since I never were good at blind coding :)


Ok, meanwhile I'll finish the demo and I'll try to compile it in Windows.

Good, I really wouldn't be getting along with Windows ;)
Back to top
View user's profile Send private message
Massimo32
Site Admin


Joined: 11 Nov 2007
Posts: 177
Location: Bolzano, Italy

PostPosted: Sun May 25, 2008 6:49 pm    Post subject: Re: Some thoughts Reply with quote

mkko wrote:
\o/
I managed to run OWS on OS X!


Fantastic! Very Happy

mkko wrote:

I could start working on it and try to make it as flexible as possible. For the next few weeks I might have some other obligations, so it might take some time. If you're starting to need the code, even if half-finished, please let me know.


No problem, take your time and send me the code when you're ready Smile

mkko wrote:

Good, I really wouldn't be getting along with Windows Wink

I understand you perfectly Wink
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Open World Soccer Forum Index -> Programming All times are GMT + 2 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group
Get Open World Soccer at SourceForge.net. Fast, secure and Free Open Source software downloads