Food Force/Meeting Logs5

From OLPC
< Food Force
Revision as of 05:15, 5 April 2008 by 69.115.94.176 (talk) (replace with more readable version)
Jump to navigation Jump to search

Session Start: Tue Feb 26 22:17:15 2008 Session Start: Tue Feb 26 22:17:15 2008


<Ankur> So, you checked the code?

<MurielGodoi> yep

<Ankur> Any suggestions you would like to give before moving further?


<MurielGodoi> Just one thing about the resources...

<Ankur> Yes.

<MurielGodoi> sounds weird the two quantities (market and village) in the same object. resources is a abstract class. It should works for the village stock, market stock or N stock

<Ankur> This way, we can keep the qts of Village and Market in two different variables whenever there is a change in some resource value.

<MurielGodoi> tomorrow when trading between players it might also works

<MurielGodoi> http://en.wikipedia.org/wiki/Model-view-controller

<MurielGodoi> I was thinking about use that architectural pattern

<Ankur> I am opening it.

<MurielGodoi> when reading realize what we should have in our model. We wont use the frameworks... just the patterns

<Ankur> Adding an additional layer named controller between data and user interface will increase flexibility. Controller will independently deal with both of them. Right? So, Muriel, We have to make an additional controller.py file for that

<MurielGodoi> right

<MurielGodoi> http://en.wikipedia.org/wiki/Model-view-controller

<MurielGodoi> That is the architectural pattern. model is what we are coding now. control will be the game engine and view the gui and village simulation. the gui sends the interaction to the controller, the controller changes the model and the model updates the gui

<Ankur> Exactly

<MurielGodoi> there is not much game logic in the model

<MurielGodoi> as price calculus

<Ankur> ?

<MurielGodoi> it is a controller responsibility

<Ankur> Yes, we just have the information about Resources, Indicators, and Facilities classes. these will be further controlled by the controller. GUI will be directly linked with the controller which we have to design, which will update our model.py file and further model.py will update out GUI. Similar to MVC model

<Ankur> GUI- > Controller.py -> Model.py -> GUI Right?

<MurielGodoi> right

<Ankur> So for Game Engine developement, do we have to start from the bottom. i.e. for controller.py file?

<MurielGodoi> sure

<Ankur> Could you please give us some pointers for that?

<MurielGodoi> you also should take a look at GObjects, that is to send messages

<Ankur> from GUI to Model.py Right?

<MurielGodoi> to communicate model-view-control, gui to control, control to model, and model to view

<Ankur> If it is already there, We can create a controller class out of this file, basically this being handling the messages and other events triggered by the user. According to the events performed, Model file will be updated.

<MurielGodoi> yep it is good a new file for that and maybe a refactoring of FoodForce2.py too. strip the view from there to view.py

<Ankur> And after some fixed interval after modification of model.py file, The corresponding changesd in the GUI will be made. This will be done direclty as model.py-> view.? or again controller in between?

<MurielGodoi> the model should send messages to the view them something changes

<MurielGodoi> nop, model-> view, take a look at MVC diagram

<Ankur> thats an indirect association! It will be through model->controller first, I think?, if we follow this. Otherwise to make things simpler, we can directly link them. as you told model->view

<MurielGodoi> there is no unique solution... I am trying to see the effects

<Ankur> Yes, but we will have the one which makes things simpler and faster. So our next task should be to link View to model.py through a controller. Right?

<MurielGodoi> right

<Ankur> where for controller.py we will get help from GObjects and Foodforce2. And to extract ths code for view from foodforce2.py to a new file view.py. Right?

<MurielGodoi> GObject will helps at all. it will send and receive messages between the modules. FoodForce2.py will be the main one to run and launch the game and more three files: view.py, control.py and model.py. FoodForce2.py will instantiate the modules and link then you will realize how FoodForce2.py will link them when reading about the GObjects

<Ankur> Okay


<MurielGodoi> I used that architeture at Memorize game

<Ankur> What is this

<Ankur> Had you developed more games except this?

<MurielGodoi> http://dev.laptop.org/git?p=projects/memorygame

<MurielGodoi> I developed simple games. like educational hangmans :)

<Ankur> Cool

<MurielGodoi> if you take a look at Memorize code: game.py is the control. model.py is model and cardtable.py and scoreboard are the view, activity.py instantiate the modules and link them, there is no problem

<Ankur> I hope all questions to this meeting are over from my side. Deepank and Anubhav, if you have any questions, you can ask them

<MurielGodoi> My master thesis is about computers in education, but not exactly about educational games

<Anubhav> no.. not from my side

<MurielGodoi> I worked on using AI to create analogies to increase the quality of learning material. Federal University of São Carlos, here in Brazil

<Ankur> @Muriel: That seems interesting. But, being from Electronics and Communication branch, I will not have this subject (AI). Deepank and Anubhav will have it.

<deepank> Not from my side also

<Ankur> :(

<MurielGodoi> That is very interesting subject. well... backing to your meeting .. Are we missing something?

<Ankur> Okay then we can have our next meeting next week, same day? Is it okay?

<MurielGodoi> That is fine for me

<MurielGodoi> in the meantime, mail me if you have any questions

<Ankur> @Deepank/Anubahv : Please put up the contents of the meeting. I have pasted on your personal query page.


Session Close: Tue Feb 26 23:29:47 2008