On Tue, 2010-12-14 at 09:34 +0200, Vlad Dragu wrote: > [vlad] i prefer to work on the "back end" part of the game > functionality, the part that deals with game logic rather than the > part that deals with the interface and front end interactions. So, for > example i enjoyed more to work on the mission engine that to wrok on > the misions implementation in the front end.
Good to know! We can try to see if you can get more of those tasks - no promise, but it will be useful to have it in mind while we discuss tasks attributions. > [vlad] i'm thinking that the game should have some administration / > moderation tools in place. As the user base grows, probably there will > be some natural friction between some players so a report player > system coupled with a warn/ban player in the backed will be useful. > I'm not sure if this is a priority right now, but probably in the > future this will be needed Yup, that's probably something we'll quickly need quickly when we get our first players. Glad that it's something that you like! It's often seen as not very important by a lot of developers, but it helps a lot when it's well done. Will be happy to discuss it then! > [vlad] i think a good place to start will be to work on adding the > additional config variables on the config file and then maybe work on > the user class and add the trust levels and gauges and the functions > needed to manipulate them. Seems to be a good area to start yup. I'd like to refine it a bit though - right now it seems both too big and too small. Too big because the perimeter of the task is fuzzy - there will be lots of modifications to the user class to add trust levels and gauges, could be good to pick just one small area (and then make it really good as time allows). Too small because I think it would be good to have a direct effect on the game - if you only work on the backend classes and methods, the feature wouldn't be complete, as there would be no visible difference from a user perspective. I have in mind that you prefer the work on the backend here - and your choice shows that ;p To try to keep the frontend part small but still have something that would be relevant for a user, maybe we could find something along the lines of "Build a jauge that fills up every time we complete a mission, and gradually fills down with time". The minimal quick&dirty implementation of this wouldn't take more than half a day - then it would be up to you to use the rest of the time to make it good. That gives you latitude and choice during the day - you can focus on the server side, building good code, refactoring the classes while you're at it, etc. And just have a crappy jauge on the client side if that part isn't interesting for you. Of course, it's just an example based on your proposition - don't hesitate to propose alternatives. > However, there are some issues in the bug tracker that are not > assigned to any release, so we could probably choose from them and > assign them to this Friday Yup, agreed - for this Friday choosing a set of bugs to fix is a good idea (with of course David's remark in mind, about completing the current releases before Friday). We can then simply meet in the morning and choose the bugs each of us would work on. What time do you start in the morning? Xavier. _______________________________________________ Farsides mailing list - [email protected] Wiki: http://farsides.com/ List: http://farsides.com/ml/ Forum: http://farsides.com/forum/ Ideas: http://farsides.com/ideas/ Chat: http://farsides.com/chat/
