Welcome, Guest. Please login or register.

  Show Posts
Pages: 1 [2] 3 4 ... 6
16  General Category / Meetings / First Developer Meeting Agenda on: April 25, 2011, 11:47:33 PM
The first developer meeting is currently scheduled for Sunday, May 1 from 8-9 pm UTC. In preparation for the first meeting I'd like to start a discussion about what should be on the meeting agenda.

One item that I think should get top priority is how administrator access to our web infrastructure should be managed and distributed among the current developers. Another high-priority item should be the focus of the next sprint.

Should any additional items be added?
17  Development / Project management / Re: Doodle: Weekly Developer Meeting Day and Time on: April 25, 2011, 11:35:21 PM
It looks like Sundays, 8-9 pm UTC is the winner. We haven't heard from qubodup, taldor, and kb1pkl yet, but lets plan on having our first meeting next Sunday, May 1 at 8 pm UTC. I'll start another thread to discuss what the meeting agenda should be.
18  Development / Programming / Re: Need New Model/Game Logic Framework on: April 23, 2011, 11:53:00 AM
FIFE is definitely more than just a rendering engine, and does provide a basic system for organizing objects using Maps and Layers. However, these FIFE "Objects" are tightly integrated with the rendering code and as such it is very difficult to extend Objects to include the actual game logic. Plus this makes it difficult to sort out the rendering code from the game logic.

Grease, on the other hand, is simply a framework for defining the game logic in a modular fashion and integrating the game logic with other subsystems, like rendering. The pyglet dependency is mostly used in the examples that come with grease, though the Clock class is used extensively throughout the library, and since pyglet compiles on pretty much any system I think it is really a non-issue.

There is some overlap between grease and FIFE for sure, but I think that the two can be integrated successfully. I've been playing with grease and I've found that it is fairly trivial to simply wrap much of FIFE into two classes: FIFEInputSystem, and FIFERenderer. I already have a working prototype that can load and display a FIFE map. I think that the key to using grease with FIFE is to very carefully separate the game logic from the rendering and input/event code, which should make it a lot easier to define and extend the game logic without having to worry about the low-level stuff.
19  Development / Programming / Re: Need New Model/Game Logic Framework on: April 19, 2011, 04:37:35 PM
So here's an interesting development: while doing research on entity systems I came across a full-fledged component-based entity system framework written in Python and C++ called "Grease"(http://packages.python.org/grease). The authors say it is alpha software, but it looks quite mature to me.

This definitely changes things. I honestly didn't expect to find any FOSS entity system frameworks on the 'net, much less one written in Python. If Grease works and is stable it could save us months of work developing our own framework, not to mention countless hours of maintenance. Even if Grease isn't production-ready, it's still better than starting from scratch and I'm sure the authors would appreciate the extra development.

My only concern with Grease is that it has the implicit order of execution dependencies (e.g. the rendering system has to be executed after the position system) which seem to plague component-based entity system designs. However, in the larger scheme of things it's probably easier to deal with those dependencies than to try and create the "perfect" entity system.
20  Development / Project management / Re: Doodle: Weekly Developer Meeting Day and Time on: April 19, 2011, 04:12:45 PM
So far Tuesdays from 7pm ~ 8pm look good. Conflicts will be inevitable given the timezone issues, but as long as we are all able to meet most of the time we should be okay. I don't envision these meetings being replacements for asynchronous dialog either, so even if we can't find a common time I don't think it will be too big of an issue.

If we can agree to a common time by Friday of this week I think we should go ahead and hold the first meeting next week, unless there are any objections.
21  Development / Project management / Re: Regular Developer Meetings on: April 18, 2011, 07:23:53 PM
We should definitely discuss the form and content of the meetings, but the basic idea was to simply have a time slot where everyone know that everyone else would be available in real time. If weekly meetings turn out to be too much, we can always scale back to bi-weekly meetings.

What I'm trying to say is pretty obvious:
Each meeting should be planned at least a day ahead
List of topics should be gathered somewhere (forums? wiki page?)
Discussions that are involving a single department or fewer people should be moved towards the end of the timebox, so that uninvolved person are not mandatory to participate

I like those ideas. We could post the meeting agendas a week ahead of time on the wiki and let any developer add items as necessary, or alternatively dedicate the last 10-15 minutes of each meeting to coming up with agenda items for the next meeting.
22  Development / Project management / Re: Trac Spam on: April 18, 2011, 07:16:33 PM
You can't login for free, as codesion doesn't allow anonymous users to register for Trac accounts.

That's unfortunate. I guess we just have to make do with the anonymous tickets.

Just to clarify, the spam filtering IS working now. I tested it by copying several of the spam tickets and attempting to submit them. I don't want to expose too much detail about our spam filtering in public, but basically our filters had a loophole that allowed obvious spammers to submit anyway by passing a CAPTCHA. We were simply putting too much weight on the CAPTCHA response, so I reduced that weight and strengthened some of the filters.

The policy IMHO should not be demotivating for spamers, but simply should disallow any spam.

Unfortunately there is always a trade-off here. We use some pretty sophisticated filters that work quite well, but even the most advanced filter is going to have some false positives and false negatives. If we strengthen the filters, then we risk blocking valid submissions (this was the case several months ago when I first joined the project).

I'm hoping that my changes to the spam filters will prevent the type of spam we saw over the past two weeks. I'm also going to try and get Codesion to fix the logging so that we can see how our spam filter is working and better fine-tune it.
23  Development / Project management / Doodle: Weekly Developer Meeting Day and Time on: April 18, 2011, 07:20:40 AM
I've set up a Doodle for us to schedule weekly developer meetings. Please visit http://www.doodle.com/dy486qpy33tm9z7n and list the times and days of the week you would be able to attend a 30-60 minute meeting each week to discuss the current state of the project.

Local times should be displayed automatically, but double check the drop-down list just above the poll and make sure it displays your timezone.
24  Development / Project management / Re: Trac Spam on: April 18, 2011, 06:10:22 AM
Barra gave me admin rights to Trac/Codesion today and I managed to delete all of the offending tickets. I also cleaned up the Planet feed as best I could. Apparently the Trac spam filter plugin wasn't configured properly and was letting obvious spam through, so that might have been the source of our recent spam attack. I don't know if Codesion accidentally reset our configuration or what, but in any case I made it significantly harder for a manual spammer to post a suspect ticket and limited the number of anonymous submissions from a single IP address to 2 per hour. Hopefully this significantly reduces our spam.

Someone suggested that we get rid of the anonymous submission process altogether and require users to register with our Trac site before submitting a ticket. I whole-heartedly support that idea. After all, what's the point of anonymous ticket submissions if our spam filters are so strict that they can't get through? (besides annoying the submitter)
25  Development / Project management / Re: Regular Developer Meetings on: April 18, 2011, 04:35:45 AM
Zenbitz and aspidites make a good point: weekly meetings are always a good thing, if everyone thinks we can meet that often reliably. The objection to weekly meetings seem to be with regard to sprints - two weekly sprint meetings AND a weekly developer meeting seem like overkill. Several people on IRC have suggested merging the developer meeting with one of the sprint meetings in this case, perhaps the first meeting of the week. I think that this solution is definitely manageable, and if there are no objections I'll go ahead and start planning weekly developer meetings.

How long do you think the developer meetings should last? This will of course depend upon the content of the meeting, but we should set an upper limit. If we are going to meet on a weekly basis, then I suggest a maximum of 45 minutes. Thoughts?
26  Development / Project management / Regular Developer Meetings on: April 12, 2011, 04:38:35 PM
Zenbitz and Q_x expressed some support for regular developer meetings, and I think that these meetings could be very useful to keep the project going. I wanted to get some feedback from everyone about whether you support the idea of regular developer meetings and how often you think we should meet, if at all. If the results show support for these meetings I'll post up a Doodle poll to select a time that everyone can attend.

Edit: Just to clarify, these developer meetings would be separate from sprint meetings and are meant primarily for discussing general project management and infrastructure issues. During sprints, these developer meetings would occur in addition to the weekly sprint meetings, so that might affect your vote on how often these developer meetings should be held.
27  Development / Programming / Re: Need New Model/Game Logic Framework on: April 12, 2011, 04:30:18 PM
After a few weeks of researching and prototyping a reactive entity system I think I finally have a grasp upon the concept, so here's my take on it.

Summary: Differences Between Component-Based and FRP-Based Entity Systems
The core idea behind FRP (functional reactive programming) is that you are able to compose functions which define behavior into more complex behaviors. This is in contrast to a component-based entity system in which you start by defining complex behaviors and then refactor them into smaller, modular components. Both processes are a form of aspect-oriented programming, where you define what an entity "does" rather than what an entity "is" as in object-oriented programming, but are radically different approaches.

In component-based entity systems you define behavior by first defining a general category of behavior. This category of behavior eventually becomes a "Subsystem" or "System", and the specific types of behavior that belong to that category become "Components". The System acts as both a global manager for the Components it contains and defines how those Components communicate with one another and with Components belonging to other Systems. For example, you might define a MovementSystem which provides Position, Walk, Run, and Jump Components. Action-based Components will then need to query the Entity that contains it for other Components that it might need to interact with, e.g. a Run Component would need to interact with a Position Component as well as an Animation Component. In the case of the Animation Component, which belongs to another System (say, RenderingSystem), the Run Component will need to query the RenderingSystem to determine what it can do with the Animation Component. Intra- and inter-communication between Components and Systems quickly becomes a very complex problem, and component-based entity systems require a solid communication framework to work effectively.

In an FRP-based entity system, you don't bother with the intermediary step of defining a general category of behavior - you just write a function that does what you want. However, unlike in component-based entity systems these behavior functions usually do not have side-effects (i.e. they don't modify state), and thus don't have any dependencies to worry about (they are "atomic" operations). Instead, the function will expect some kind of entity state information as input and output the changes to that state. For example, you could write a move(position, velocity_vector) behavior function which would take the entity's current position and a vector defining how fast and in what direction the entity is moving and the move function would return the new position of the entity.

Entities and State in an FRP Entity System
State in an FRP entity system is contained entirely within Entity instances, which are basically fancy dictionaries. However, it is a little bit more complex than that: state is not represented by ordinary values, but by "Signal" instances. A Signal is simply a function that takes time as an input and returns a corresponding value, and represents a value that can vary over time. I must admit that I haven't grasped exactly how Signals and behavior functions are supposed to react to time, but the basic idea is that behavior functions are operations on Signals.

"Controllers" are functions that map an entity's state onto one or more behavior functions, and are the glue code between behavior functions and entities.

Generic Function Composition
The real power of an FRP-based entity system lies in the fact that it allows behavior functions to be generically composed to form more complex behaviors. For example, the move function above could be composed with a render(animation) function into a new walk(position, velocity_vector, animation) function which renders the entity's walk animation cycle.

Of course, the big question is: how do you compose behavior functions in a generic way? Yamppa http://www.haskell.org/haskellwiki/Yampa, which is the FRP Haskell library I based my prototype code on, relies on the Haskell "arrows" framework to do this function composition. The arrows framework is explained quite well on this website http://en.wikibooks.org/wiki/Haskell/Understanding_arrows, but the basic idea is that you can compose functions in one of two ways: in serial (the output of one function becomes the input of the next), and in parallel (input is split or cloned and passed to one function independently of the other, and the output of each is later joined). Arrows works fine for Haskell because it is statically typed and allows functions to be dynamically overloaded using type classes, but in Python it becomes quite cumbersome. I did get a working arrows implementation in Python, but it was so difficult to work with that I ended up scrapping it.

The Problem with Arrows and the Solution
Arrows ended up being very difficult to script without a DSL (domain-specific language) and placed unPythonic restrictions upon what inputs a behavior function can take and what outputs it can return (either a 1- or 2-tuple). I eventually decided to try and treat arrows-composed functions as restricted, directed graphs, which meant that I could use a graph language like Graphviz dot or GML and visual editors to script it.

I quickly found that treating function composition as a graph was really intuitive - functions are just nodes in the graph, and edges connect the inputs and outputs of the functions to each other. Since I was going to use a graph language for scripting anyway I decided to drop the restrictions that arrows placed upon the behavior functions. This meant that any Python callable could be used as a behavior function without modification and that function composition could be much more complex.

If you have ever worked with procedural noise/texture generation then you're probably quite familiar with this method of composing functions. This is what I mean: http://www.world-machine.com/images/ss6t.jpg (world-machine is a fantastic noise/texture/terrain generator, just FYI. Windows-only but works fine in Wine).

Conclusion
So that's my not-so-brief summary of my research and prototyping. There are still a few areas to iron out, but I think I have a good understanding of the theory and mechanics behind an FRP system. I'm curious to hear Beliar's opinion on this, since he was working on a component-based entity system last time I checked in with him.
28  Development / Project management / Re: Trac Spam on: April 12, 2011, 02:36:17 PM
Well, this pretty much reminds me of headless development times, when Beliar, Domtron and me did some enormous progress (and haven't ceased the project). Especially the spirit.

How did that work out in terms of project management? I'm just curious as to how the three of you worked together, what sort of things went well, what didn't go so well... etc. I think some of the agile process has proved useful, but any lessons learned from that time would be helpful to know.

When Martin came back, he said he will be there for a month or so and will try to breathe a new spirit into the project, which he did, and was here longer than expected anyway.
I'd rather assume he will be back and push him to give some of us access to some places, as this is what we need, not backups. Using some h4x0r soft to copy wiki database may be in fact a waste of time.

Hmm, I wasn't aware of that. We should definitely push barra to give us administrator access to all of our web infrastructure, but my point was that we shouldn't let the infrastructure slow us down if he doesn't show up within a month or two to do so.
29  Development / Project management / Re: Trac Spam on: April 11, 2011, 06:16:19 PM
This is just a thought, but why don't we start having regular weekly or bi-weekly (meaning every two weeks) meetings to discuss the current state of the project. This way we would have a dedicated time slot for real-time discussions. It may be that we also want to setup some kind of elected committee system that rotates every month or so to make task delegation easier to manage.
30  Development / Project management / Re: Trac Spam on: April 11, 2011, 06:08:20 PM
I get what you're saying and I agree with most of it. I strongly advocate for shared administrator access to all of our web infrastructure so that we don't end up in this kind of situation again. If barra doesn't reappear in a reasonable span of time then I think that we can and should set up a new set of websites and transfer as much information as possible from the old ones - I don't relish the idea of abandoning our web infrastructure, but if it is holding us back then so be it.

However, I think there is a larger project culture issue here that needs to be addressed. Barra is an incredibly capable leader, so capable in fact that I think we've all been relying on him far too much to push the project forward. It really isn't fair of us to delegate so much of the project's infrastructure maintenance to barra - its not like he's being paid a salary for doing it. By relying on barra so much we've also set our bus factor to "1", i.e. if barra disappears the project dies. This is simply unacceptable for an open source, volunteer-based project. Practically no large, successful open-source projects exist that delegate major infrastructure maintenance to a single person - Python has Guido van Rossum, but he doesn't manage python.org by himself! The Apache project does practically everything by committee.

I think that this project needs a drastic change in project culture. We all need to be project managers working to maintain and propel PARPG forward. I feel like we're all trapped in our little area of expertise and unwilling to venture outside of it. Instead of saying "that's not my area of expertise" we all need to step up to the plate and out of our comfort zones. I recognize that everyone is volunteering their free time and that most don't have the time, energy or desire to learn new skills, but at the very least anyone could help advertise for new developers in the areas where we're lacking skills.

Most importantly, we need to make sure that at every point in PARPG's evolution that every developer has the tools and ability to manage the project infrastructure. This means demanding equal access to all project resources and administrator rights to all project infrastructure, and not being shy about it.

In practical terms, I think that this means:
  • All current developers need full administrator access to our project infrastructure, and we need some way of making sure that access cannot be denied by any one person
  • We need more developers with website management and development skills
  • We need more programmers who are willing and able to work on tools and GUIs
  • If the new agile development process is slowing us down because of lack of knowledge, then either a) everyone needs to do some research and learn about it, b) we need to pick and choose some elements of agile development we are familiar with (sprints, product backlog) and drop the rest or c) we need to scrap it all together

Case in point: if the sprint end isn't well defined, then lets define it. There's no sense in waiting for barra to do it for us.

I don't want to sound presumptuous - after all, I've only been here for a few months when most others have been with the project for years - but I feel very strongly about this, and I want to get the discussion going about the long-term viability of the project.
Pages: 1 [2] 3 4 ... 6