Welcome, Guest. Please login or register.

  Show Posts
Pages: 1 2 [3] 4 5 6
31  Development / Project management / Trac Spam on: April 10, 2011, 10:06:40 PM
I've noticed, as I'm sure most of you have, that the Planet feed is full of spam tickets being posted on Trac. I've sent barra an email about it so hopefully he'll be able to clear out the offending tickets soon, but I think that there is a larger infrastructure issue here.

I recently ran into a blog entry entitled "The Death of CAPTCHA" (http://www.terminally-incoherent.com/blog/2008/07/01/the-death-of-captcha/) in which the author suggests in no uncertain terms that CAPTCHAs and other bot detection methods are pretty much obsolete, since quite a few companies are now offering large-scale manual spamming operations. While I commend these companies for improving oppertunities for minimum wage employment  Angry, this does put another nail in the coffin of our bot-checking approach to preventing spam.

I've been thinking about the alternative approaches we can take. We can try adjusting Trac's Akismet spam rules or switch to another filtering system, but I'm inclined to reject filtering all together for the following reasons. First, it isn't foolproof and the stricter we make the filters the more likely it will be that we reject legitimate Trac tickets. Second, any spam which DOES make it through the filters and isn't dealt with immediately increases the likelihood that we receive more spam: the company doing the spamming sees our site as an easy target (I'm not just being paranoid - these companies use various algorithms to rank sites for how easy they are to spam in order to maximize their efficiency).

Instead, I suggest that we require ALL new Trac tickets to be moderated before they are posted. Since we're going to have to moderate Trac no matter what method we use to prevent spam, we might as well make our effort worthwhile and prevent spam before it is posted rather than after the fact. We can keep the existing bot-checking filters as they can reduce or eliminate automatic spam and thus reduce our moderation effort.

I remember reading another blog about preventing spam not long ago which  - I couldn't remember where I saw it, but the basic idea was this: to prevent spam, a large website posted a brief but prominent disclaimer on every page with a submit button. To paraphrase, the disclaimer basically said "We actively check for spam and most of it is deleted within minutes of being posted, so don't waste your time trying to spam us." Remarkably, spam on the site was drastically reduced (something like 80%) just because of that simple disclaimer. The lesson is this: if we make it extremely difficult to spam our sites and advertise that fact, our moderation effort is likely to be very small.

Anyway, those are my ideas. Any thoughts?
32  Sprints / Character customization / Re: Post-Sprint Analysis and Reports on: April 09, 2011, 04:26:51 AM
Yes, thanks for the prod qubodup Smiley

What went well? Cheesy
In general, I think the Trac ticket backlog was quite successful at keeping us organized and on-track. In particular, I thought that the Trac ticket dependencies (blocking, blocked by fields) and depgraphs (e.g. http://parpg-trac.cvsdude.com/parpg/depgraph/264) were very helpful for figuring out which tasks to prioritize. AFAICT everyone on the team seemed comfortable working with the Trac tickets and the backlog, though there was some hesitation in the beginning for those who hadn't dealt with Trac much in the past.

I thought that the twice-weekly sprint meetings were extremely useful at keeping everyone in the loop. Twice a week seemed like a good frequency to me - it gave us enough time to work on smaller tasks and report our progress, and also allowed us to quickly discuss and assign new tasks as needed. The strict meeting structure was good at keeping us on-topic, and overall I thought the meetings were very productive.

What didn't go well?  Cry
The momentum from the first two weeks died off rather rapidly in the second two weeks. Based my own experience and observations of the rest of the team, I think what caused this slowdown was a series of structural problems with PARPG which blocked progress in several departments. For instance, in the programming department I was not able to fully implement character statistics because the current model system makes it very difficult to add new things to characters and other game entities. In the graphics/GUI department qubodup and Q_x were unable to work with PyChan and its complexities and eventually I ended up having to work on both the PyChan GUI and game model code, neither of which were easy to deal with.

My only complaint about the meetings was that I would have liked some time to discuss solutions to problems we brought up during the meeting. In theory we were supposed to discuss solutions in-between meetings, but timezone differences and time commitments outside of PARPG made this almost impossible.

In the final week and a half of the sprint we lost barra and shortly thereafter myself due to family and school commitments, which I think contributed to the slowdown and made resolution of the sprint difficult.

What would I change?
I would like more time during the sprint meetings to discuss solutions to problems encountered during the sprint. Perhaps adding 20-30 minutes to the sprint meeting times? We could break away into smaller groups during this problem-solving meeting time, and those who don't have anything to contribute would be free to leave.

What is my overall impression of the sprint?
A fantastic success, though not for the reasons we originally based the sprint on. We did not fully implement any of the user epic stories and from a purely numerical standpoint only completed 68% of the tasks we set for ourselves. However, we learned A LOT about how to communicate with each other and how how to organize and deal with a series of tasks as a team. Before the sprint we were a bunch of individuals working in parallel, but during the sprint we came together to solve problems as a team. We now have an organizational framework that we know works, and I would say that is a major accomplishment.

We also discovered several major structural problems with PARPG which we may not have encountered working alone. It is extremely important that we deal with these structural issues early in PARPG's development, otherwise we may end up with product that not only requires an enormous amount of maintenance but that only a few key developers know how to maintain! Not a good outcome for an open-source project which relies on volunteers with a high turnover rate.

Conclusion
The sprint may not have gone as we originally planned, but I think we did a great job and learned a lot in the process. Now that we know what's blocking our progress we should regroup and start brainstorming about how to tackle those issues. Hopefully we'll be able to start another sprint soon and with the lessons learned from this sprint be able to make some real progress!
33  Development / Programming / Need New Model/Game Logic Framework on: March 12, 2011, 03:11:38 AM
A major issue that blocked my progress during the sprint was that there wasn't a well-defined and easily extended famework for the model portion of the code. For instance, when I went to attach character statistics to the character class itself I found that there was no easy to way to do so without doing some major refactoring. In the future, I expect that adding new character behaviors, traits, skills, inventory etc. will be equally as difficult given the current system, and will each require separate refactoring of the game logic.

The main problem is that we currently use some kind of hybrid inheritance/component-based design, where we have one monolithic CharacterBase class which hardcodes most of the character's functionality (visual appearance, some behaviors such as dialogue, etc.) and a few components like inventory and attributes which isn't well defined. In general I advocate against using inheritance to define "entities" in the game in which we have a hierarchy of classes with a monolithic base class like CharacterBase which NPCCharacter, PlayerCharacter etc. all inherit from.  The reason I am opposed to such an approach is because each time we add a new behavior or component we would need to refactor not only the child classes they affect, but also their base classes. This leads to bloated base classes that are difficult to maintain in the long run.

I've thought a lot about how to address this problem, and I've come up with two potential solutions.

  • The first solution would be to move to a pure component-based entity system, where there is a single Entity class which acts as a container for components such as behavior, AI, stats etc. An NPC character, for instance, would just be an Entity instance that has a certain set of components. Components then query their parent Entity class (or an component subsystem/observer) for the state of other components it depends upon.

    The benefit of a pure component-based entity system is that such systems are well-defined and have an abundance of literature on the subject, so prototyping work would be minimal.

  • The second solution is to try and implement a hybrid component/reactive system, where again there is a single Entity class which acts as a container but components are broken down into smaller, composable units called "Behaviors". Behaviors are time-dependent functions which are not executed directly, but which are called when one of their dependencies change (e.g. time), hence the "reactive" term.

    The benefit of this approach is that it is far more flexible and easier to manage in the long run because you don't have to explicitly deal with component dependencies, which could become a nightmare to manage otherwise. However reactive entity systems are pretty much an academic pursuit at this point, which means that we'd be on our own in terms of implementing it.

My personal preference is to try and implement a reactive entity system. The difference in total amount of work isn't going to be drastically different between the two, and in the long run a reactive entity system will be much easier to maintain if implemented correctly.

In case your interested in the details of each type of system, I've gathered a few references:
Component-Based Entity Systems
Functional Reactive Programming
34  Sprints / Character customization / Might not be on for a few days... on: March 05, 2011, 09:00:26 AM
Hi all,

Unfortunately a family emergency has come up which requires the bulk of my attention for the next couple of days, and potentially a week or more. I will try to complete the character creation GUI by tomorrow evening and commit all of my code (finished or not) so that others can work on it if needed.

I'm really sorry about bugging out at the last minute Sad I'll be on IRC when possible, but I'm not sure how much time I'll have to work on tasks.
35  Sprints / Character customization / Post-Sprint Analysis and Reports on: March 04, 2011, 11:58:14 PM
The sprint officially ends on Tuesday, 10:00pm UTC at the start of the post-sprint report meeting. Everyone involved in the sprint should take some time between now and then to jot down their thoughts about the sprint as a whole. We'll use this discussion as a starting point for the post-sprint meeting on Tuesday.

The following questions should serve as general guidelines:
1. What worked really well in the sprint? What didn't go so well during the sprint?
2. What, in general, blocked your progress most often? What facilitated your progress most often?
3. What would your change about the sprint? What would you keep the same?
4. What is your overall impression of the sprint? Was it successful? Why or why not?

When posting, please start with a brief description of what you worked on during the sprint to serve as a bit of context.
36  Sprints / Character customization / Re: Progress reporting on: February 25, 2011, 10:14:56 PM
Unfortunately I won't be able to attend the sprint meeting today (February 25). Recent cold snaps have forced me to take drastic action to save my fruit trees.

What have you worked on since the last meeting? I've been trying to figure out a method for attaching character statistics and other metadata to character instances, but after fiddling with my current prototype for over a week with nothing but errors to show for all my work I've decided to scrap my current prototype and take a new approach.

What were your impediments? In my previous prototype I tried to simply hack the existing methods in GameModel for loading all_agents.yaml and insert the character data there, but unfortunately due to the way those methods deserialize the character instances written in YAML this proved to be difficult if not impossible without rewriting most of the parsing code anyway.

What do you plan to work on next? In lieu of my previous prototype's failure I've decided to replace the existing YAML parsing code with my generic Python object XML serialization code, which should make it much easier to extend in the long run. I spoke with Beliar about this change last week, and he agreed with such an approach. Hopefully I'll have a working prototype in the next week or so.
37  Sprints / Character customization / Re: Meetings on: February 25, 2011, 12:51:04 AM
Np Barra - sleep is, unfortunately, sometimes necessary! Thanks for taking care of the summary.
38  Sprints / Character customization / Re: Reorganizing the Directory Structure on: February 18, 2011, 08:43:35 PM
I fully support renaming the "scripts" directory to "parpg", it makes a lot of sense in my mind. You'd have to do a find-replace on all imports though and change them.

Renaming the parpg.py module to core.py is fine by me, but perhaps a more descriptive name like "application.py" would be better suited. E.g.
Code:
from parpg.application import PARPGApplication

run.py just needs to be renamed to, e.g. "parpg.py". Its fine as an entry point in my mind, lots of python applications use a python script as an entry point. Might be able to move a bit of the logic it defines to the PARPGApplication class though.
39  Sprints / Character customization / Re: Ticket 306 (Stats Prototype) on: February 15, 2011, 04:08:28 AM
In this prototype a PrimaryCharacterStatistic or SecondaryCharacterStatistic instance defines a particular type of statistic, a sort of template which is then attached to a StatisticValue instance to give that StatisticValue instance a more concrete meaning.

There are a limited number of primary and secondary statistics: strength, health, endurance, melee damage, etc. Each type of statistic has certain common traits:  one or more names or identifiers, a description, and perhaps a minimum and maximum bounding value. All statistic values of a particular type (e.g. strength) attached to various characters have these attributes in common, even though the particular value of that statistic type attached to a particular character may vary. These concrete examples of primary and secondary skills are implemented as PrimaryCharacterStatistic and SecondaryCharacterStatistic instances.

If one were to map this implementation to an inheritance-based design as you suggest, then the attributes that the CharacterStatistic classes define would be class attributes, while the StatisticValue class would map to instance attributes. Although I originally intended to go this route, Taldor pointed out that it would be difficult to manage and extend the inheritance tree for so many statistic types. Instead, I went with Taldor's composition-based design which is much easier to script (new statistic types can be scripted in XML, for example).
40  Sprints / Character customization / Re: Ticket 306 (Stats Prototype) on: February 11, 2011, 11:03:20 PM
Status update: I've pretty much finished implementing the primary and secondary character statistics logic.

In my current prototype, character statistics (both primary and secondary) are defined in two parts: a class which defines attributes common to all statistics of that type (e.g. strength), and a class which contains the value of a type of statistic for a particular character. This relationship is shown in the attached UML diagram.

In the more concrete case of primary statistics, instances of the PrimaryCharacterStatistic class define a particular primary statistic type. Thus, the "strength" statistic is defined as:
Code:
strength_statistic = PrimaryCharacterStatistic(
    long_name='strength',
    short_name='ST',
    description='You know, muscle. Boom! Boom! Fiah Powah.',
)
While a character's strength statistic is given by:
Code:
character.statistics['strength'] = PrimaryStatisticValue(
    statistic_type = strength_statistic,
    value=50,
)

Secondary statistics work the same way, except they have a few additional attributes and methods which are used to calculate a display value (simply called 'value') used to display the secondary statistic value to the player, and a normalized value (on a scale of [0, 100]) used in calculations.

Notice that SecondaryStatisticValue does not allow the value attribute to be set through the constructor (value and normalized_value are read-only attributes as well) - the value is derived using the derive_value(normalized=True) method, which queries the character's primary statistics to calculate the current value. Consequently, SecondaryStatisticValue instances must be attached to the character they belong to and store a weak reference to that character.



Uploaded with ImageShack.us
41  Sprints / Character customization / Re: Twice-weekly Scrum meetings every Tuesday and Friday? on: February 11, 2011, 08:41:32 AM
Sounds good to me. I'll be there.
42  Sprints / Character customization / Re: Meeting to discuss programming tasks with mechanics designers on: February 08, 2011, 08:10:55 AM
Quite frankly I support using XML in this case. We need some kind of scripting that is implementation-independent so that we can easily change our implementation later on if needed. YAML is out, simply because its a pain to write parsers for and we're moving away from it in general. As Zenbitz points out, Python isn't terribly useful unless we have the data structures designed, which sort of defeats the purpose of scripting. JSON would work as it is simply a subset of Python, but for consistency XML is probably our best option.

Keep in mind that it is fairly trivial to write parsers for XML and JSON, so we can change it later if needed. But for the time being my suggestion is to just go with XML and deal with the details later.
43  Sprints / Character customization / Ticket 306 (Stats Prototype) on: February 08, 2011, 05:28:15 AM
I went ahead and assigned ticket 306 (http://parpg-trac.cvsdude.com/parpg/ticket/306#comment:3) to myself, but I'd appreciate feedback from Taldor as I make progress on it.

Taldor and I brainstormed a while ago and came up with a basic implementation: http://parpg.pastebin.com/iWKXQdmQ. I figure this is a good place to start.
44  General Category / Introduce yourself / Re: Nice to meet you all. on: February 08, 2011, 03:10:11 AM
Greetings Necromiki, and welcome to PARPG! We are always pleased to have interested contributors Smiley If you're interested in writing, please check out the Writing Department Wiki (http://wiki.parpg.net/Department:Writing) for details on how to contribute, as well as what has already been written.

As others have stated we use IRC chat quit a bit,  so please feel free to log on and chat. We've just started a sprint (http://wiki.parpg.net/Sprint:Character_customization), so things might be a little hectic.
45  Sprints / Character customization / Re: Progress on Task 297 (Design UI for Pre-game Character Creation Screen) on: February 07, 2011, 07:17:08 PM
The fixed-size notebook design is already pretty much done, and I say we stick with that for now. While it should be easy in theory to change the design to use the scalable graphics, I've found that PyChan has a lot of intricacies that makes even the simplest task a monumental undertaking. I worry that trying to implement the scalable notebook now would just end up being a time sink.
Pages: 1 2 [3] 4 5 6