mpango-core

[Mpango-core] Status meeting

[Eduardo de V. T. <etu...@gm...>]

Attendees: edevera, devlee, mbadiac, prbarcelon, tufan, wellings.


First status meeting in the project! Nice to have you on board.

During the meeting it was agreed to use Google Chat instead of IRC as people seem to be more comfortable with it. So next week's meeting will be held over Google Chat. We need some explanation in order to proceed, has anyone used Google Chat in group chats? Help is welcome!
We need to find out why all the people invited did not attend the meeting so that we can try addressing the possible problems in order to have them participating. What were the reasons not to attend the meeting? The timing? The technology? 
I have proceed grating more privileges to the team members that are more committed to the project in order to allow them to work more effectively. 
In particular now devdlee, jaywellings, mbadiac and myself have admin rights for the tracker so that they can assign themselves and others more easily work.

We have agreed on the following work for the team members:

devdlee: 
We have to meet online in order to talk about the settlement of units as cities and if cities should be considered constructions. 

prbarcelon, mbadiac: 
Learning JUnit testing and Easymock. 
Resources to read: 
http://en.wikipedia.org/wiki/JUnit
http://www.vogella.de/articles/JUnit/article.html
http://www.youtube.com/results?search_query=eclipse+junit&aq=f
Creating some unit tests for the existing classes that don't have any of them. 
If you want to see what classes are not tested or need more tests, I have added Cobertura plugin to Maven. This plugin produces reports on unit testing that will help you identify what classes are not being tested. In order to run cobertura plugin, just type mvn cobertura:cobertura. You can find the reports after running the plugin in the target/cobertura folder (they are HTML documents). 

turfan: 
Will write some unit tests for the existing classes.
If you want to see what classes are not tested or need more tests, I have added Cobertura plugin to Maven. This plugin produces reports on unit testing that will help you identify what classes are not being tested. In order to run cobertura plugin, just type mvn cobertura:cobertura. You can find the reports after running the plugin in the target/cobertura folder (they are HTML documents). 

wellings: 
Propose a high level User Interface. This document should contain a schema for the main game play mode with the different areas of the presentation to the user (header, menu, body, footer) as well as for the login screen and the registration screen.



edvera: 
Deliver a structure for the web module for wellings. 
Investigate http://code.google.com/p/openmeetings/ for future meetings among the team members.
Continue working on the game script document. 
Add information related to cities.
The turn engine in order to base it on units instead of having a universal turn engine for all players. Turns should be as short as possible so that the players can interact faster with the game. Queues are proposed in order to store a list of things the unit needs to perform.
This document is found in a dropbox folder that has been shared with wellings, prbarcelon, mbadiac and devdlee.
Give tracker rights to all committed members.


If you feel something that was talked about during the meeting has been left out of this email or please reply adding it.

Re: [Mpango-core] Status meeting

[Eduardo de V. T. <etu...@gm...>]

Hi Andy,

My thoughts interlined with your questions:


On Jun 3, 2011, at 7:12 PM, ugl...@gm... wrote:

> Hi.
> I wrote that listeners are mandatory, because I assumed that game
> board(GameboardDTO) will be instantiated in front-end, processed and
> passed to back-end again.
> Apparently I was wrong.
> I saw you created Player entity. I could create some code about
> player, but I have some questions.
> 
> 1) What will be connection between Player and User? Can user create
> more than one player? Regardless the answer I'd suggest that
> (User<->Player = ONE<->MANY),and suggest status inside the entity( for
> example CREATED, ACTIVE, INACTIVE, DELETED).

Yes, a player is the representation of a User in the game. Meanwhile a User has real world information, the player only has game related information (and a pointer to the User that controls it).

I also think that we should not limit ourselves to one player per user. So indeed I agree with you. Either because a user can play on different games or because a user can play in the same game with different players, it makes sense to map one-to-many.

Regarding your status, I agree with you. We should have at least the 4 status you have mentioned. Can you please add them to the directory package as an enum and add it to the user as a mapped field?

> 
> 2) Can Player create game and game board ( like in classical
> multiplayer strategies ), or only join the existing ones? If player
> can only join, then how world will be created?
> 

Worlds will be create by the administrator of the game. So we have control over what is happening on the game and how many games are taking place. Which makes me think to have MBeans for the different administration enabled elements of the game. That would make it easier specially at the beginning when we won't have administration tools developed.

> 3) Assuming we are creating turn based game, how we resolve case when
> one of players will log out?

Great question.

At the moment, all actions of the game will be executed as commands. Commands take zero or more elements as arguments and are to be executed. Some of them are considered instant commands and some are considered task commands (or scheduled ones). The latter ones are commands that need time to be done, so the trick is to schedule the command to be executed in the future. You can see how I have programmed this by looking in the Command, ITaskCommand, AbstractTaskCommand, ConstructionCommand classes together with their unit tests.

Commands when executed interact with the elements  passed as arguments (the subject and object of the action) and produce certain events that they broadcast to the listeners subscribed to it.

I have implemented these classes in the past days, they are just a sketch as I haven't taken synchronization very seriously. So there might be flaws. I also think that it might make sense to decouple Listeners and Entities and have a class that groups both things.

I am thinking about having two different implementation of the same interfaces in order to work efficiently on this scenario you are depicting.

Whenever a player is online, he needs information as closest to real time as possible. That is very costly, as it means having more resources dedicated to inform the online player and to process all events.  At the moment, this scenario is the one I am currently working on, by implementing TaskTimer classes as the base of all AbstractTaskCommand classes. You can have a look at the actions package. This Timer can become quite expensive as they involve having one Thread per Timer. So I was thinking about having a Timer per Player and some classes taking care of executing commands and enabling the undo functionality as well.

On the other side, we will have offline players that while they are away, their games keep on going. In this sense, we don't need to notify anyone about the scheduled tasks (such as collection of food and other resources, completion of constructions, etc...). In this case, the resources needed are less as things can happen in batches with one Thread processing multiple Users. The implementation I am considering here is based on Quartz that seems to be Spring friendly.

On one side we will need to broadcast events of commands to the User Interface, on the other side not. There are things to think about and I haven't come out with a class design at the moment. I don't like to over engineer but as we progress on the implementation I believe there will be elements that will need some design and refactoring.


> 
> 4) How the persistence to database will be done? After player log out?
> After every turn?
> 

Great question again.

Persistance should be done constantly making sure cache is enabled so that I/O to the database stays at minimums. If we want to support a vast number of players simultaneously we can't afford making too many I/O operations. This will be an important factor for the stress tests in order to have metrics of how much cache we need for how many users. That will enable us to estimate how many users per JVM (CPU and RAM values) we can sustain.

So, I would say we have all the database calls we need taking into account that we need those operations to be done on the cache. I would recommend flushing the cache when shutting down the application as a initial idea (of course we would need some more sophisticated mechanism to save the game every now and then so that service interruptions don't cause major data lost).

If we enable, as I mentioned before, mBeans representing the outstanding elements of the game we could use mBean monitoring to enable certain automated administration tasks (such as flush the Hibernate cache when the work load is low).

> Sorry for many trivial questions, but in general aspects of the game
> are mainly in your head.

I appreciate your questions and I must apologize for not writing all these things before you can overtake the work. I think giving out the information on demand is the best I can do at the moment. Of course, I would love to hear counter arguments if any one has them as it would be for the sake of the project!

> 
> Regards
> Andy

P.S. Please consider involving all developers in those discussions as they might be interested getting involved. I hope you don't mind I copied your email to the core list.