Welcome, Guest. Please login or register.

  Show Posts
Pages: [1] 2 3 ... 13
1  General Category / Introduce yourself / Re: Hey on: September 23, 2009, 01:42:38 PM
Taking a break for now. (I emphazise "for now"). Just don't have enough time to contribute, sorry.
This also means I step down from the "programmers leader's board".

Hope to be back soon. Good luck till then.
2  General Category / Introduce yourself / Re: Hey on: September 07, 2009, 02:55:09 PM
Probably wont be online for a few weeks (except during working hours) starting from next week. I finished on the project here in Switzerland and we don't have internet access at home yet. D'oh! :X
3  General Category / Meetings / Re: Meeting of the entire development team on: September 03, 2009, 07:22:06 PM
Don't worry about me. Use the date where the most people can attend, of course! Smiley
4  General Category / Meetings / Re: Meeting of the entire development team on: September 03, 2009, 03:09:09 PM
I can never on weekends, at least not until we got Internet at home. Which will still take at least another month.
5  Development / Programming / Re: Class Design Draft on: August 28, 2009, 12:29:05 PM
The idea is to have more than just an attribute saying "Yes, this is openable", but to have functionality that determines what happens if you try to open this object. Therefore the composition by inheritance.
I'm strongly against having one unified function that has a huge if-then construct which checks for the attributes to see what happens.. In the end it's the same but harder to maintain, harder to extend and less elegant. Also you end up with a complete set of functionality in all objects when each of them only need a certain subset.

I recommend the link that was posted in the second reply in this thread: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
6  General Category / Introduce yourself / Re: Hey on: August 26, 2009, 09:29:16 AM
might not show up so much in the next few days, got some things to sort out
7  Development / Programming / Re: engine.py and world.py on: August 20, 2009, 10:03:46 PM
A game is not really GUI driven.

The loading of the map should the map class itself (in case of decentralized loading functions) or a loader class handle. The engine/game class is actually a good point to inherit from the input listener, as it will possess all the game data/class and can delegate the work. If we had a separate object just for listening it would need the references to the other objects to delegate/trigger things.

PARPGEngine is, in my opinion, not a better name than engine. There exists already a PARPG class and because people are lazy they would not write out the name fully each time they talk about it and it would require further explanation again, which engine class is meant.
8  Development / Programming / Re: Map handling on: August 20, 2009, 12:11:23 AM
Or as somebody else put it: premature optimization is the root of all evil :-)

This is not about premature optimization but about deciding on a strategy. As I pointed out, being able to hold more than one map at one time in the memory and switching freely between them would require a slightly different approach in storing information.

But apparently it's decided that we stick with what we have.
9  Development / Writing and Quests / Re: Dialog map in the writing editor on: August 19, 2009, 04:15:00 PM
Well, you would want to know which decisions the player took so far. I imagine there are not only immediate effects/reactions to the decisions, but also some other influences later in the game.
Like if you encounter dude1 in the beginning of the game and call him an asshole he wouldn't be happy to see you again, later in the game.
10  Development / Writing and Quests / Re: Dialog map in the writing editor on: August 19, 2009, 02:53:06 PM
Will you implement variables? (Like storing whether option 1or 2 was chosen?)

And, for the exact reason you mentioned, it is not a tree: the GOTO breaks the tree-structure.
11  Development / Programming / Re: engine.py and world.py on: August 19, 2009, 02:41:27 PM
All the addObject addPC functions, that are currently present in both world.py and engine.py. I'd like to have a class that in the background manages our data layer and the FIFE objects. (Ensuring that they are in sync, updated properly. That new objects are added to the layers peroperly etc. etc.)
Right now this handling is decentralized and quite confusing.

As for the naming thing: I agree with you. I didn't want to make this a separate task. I'd rather have the developers think a bit about the name, when they add new functions/classes. And, like you said, if they encounter really bad names, change them.
12  Development / Programming / Re: Map handling on: August 19, 2009, 02:35:19 PM
Jup. First mapload takes 0.5 seconds on my computer. Second is faster IIRC, but i don't know how long it takes.
We should consider that this game should be able to run on older PCs as well. Smiley
13  Development / Writing and Quests / Re: Dialog map in the writing editor on: August 19, 2009, 12:53:10 PM
Would a graph be more useful than a tree? The dialogue path's are, after all, not paths down the tree. I'm thinking of something looking like a state machine. Cheesy
14  Development / Programming / Re: engine.py and world.py on: August 19, 2009, 10:27:48 AM
Just saw the Trac tickets about the GUI. That's a step in the direction I suggested here, but needs to be done for more than just the GUI stuff. Smiley
15  Development / Programming / Map handling on: August 19, 2009, 10:12:05 AM
What do you prefer?

1. Maps are loading just in time, when they are needed. Previous map is discarded. Only 1 map is being held in memory at a time.

2. Maps can be preloaded and are cached somewhere. Maps remain in memory. Loading/reloading strategies can be decided on later, according to performance experiences.


Problem with 2. is that the map loader we use is creating the cameras automatically. The cameras are bound to the object layer in the map. If we wanted to go for 2. we would need to rewrite part of the map loader and save the information for creating the cameras in the map cache, so the cameras can be recreated on a map change without reloading the map itself.
Pages: [1] 2 3 ... 13