| Edwin Brady | EB |
| Stephen Quinney | SQ |
| Andrew Chadwick | AC |
| Thalia Teasdale | TT (Chair) |
| Stuart Teasdale | ST (Secretary) |
| James Quinney | JQ |
| Stuart Bird | SB |
TT opened the meeting and thanked the attendees.
No previous meetings.
None
EB informed the meeting that rendering was present, with hooks for extra bits - hyperspace, docking, etc. The flight model is in need of sorting.
Event handling and guile to sort.
Outstanding:
EB outlined the need for a demonstrator consisting of a player flying around with some other ships. Shooting, navigation and other important stuff should be included.
Economics is needed but not till later.
AC informed the meeting that the Perl was coming along nicely and outlined the structure.
Perl calls C to initialise the universe. The model loader and dumper are also in.
The Perl achieves a flexible extension system, c.f. emacs, where most of the functionality is written in the extension language.
There is a need for core classes which are well documented.
EB added that he saw the AI as basic in C++, but driven by Perl events. He added that the split between fast C and slow Perl was important, with an aim to keep the speed critical bits in C and put complex stuff in Perl.
SQ asked "What's going into Perl?"
AC answered with the following
items:
EB summarised by stating that C++ would control per frame bits, and Perl doing event and construction bits. Objects will respond to events.
EB continued to outline that C would handle an object being shot and trigger the special effects. Perl would then delete the object.
AC stated that Storage, Callbacks and Game events form the beginning of the library.
Storage - Each entity is called a THING.
It has properties which are hierarchical to stuff stuff. This provides a
flexible system. The extension programmer shouldn't need to see the exact
layout, but instead use the API to access. The classes in so far include:
Other bits would include, e.g. market prices.
The thing will be very flexible and nearly complete, but needs integrating with EB's bits.
EB - "Only needs a facade for `flyey abouty bits'".
AC continued to Callbacks.
C fires an event - Perl handles it via specially named methods (e.g. 'On collision'). It also tidies up.
The system will allow specifying what events to listen for. We must avoid firing the Perl when not necessary. The Queue will have to be smart.
SQ queried if the code would be replaceable, e.g. simple to complex AI.
AC continued to Library
There is a need for properties to change dynamically. This would form the standard place to plug in AI modules to handle different AI behaviour.
ST pointed out that this was a major gameplay decision.
AC pointed out that he also needed lots of objects coded up.
It was decided to place an action on AC concerning the Perl.
Action 1. - To remove guile, replace current functionality in Perl
On AC timespan 2 weeks after meeting.
EB asked how slow dereferences would be.
AC replied that they'd be quite slow. Dereferences by pointer would be more optimal than those by value.
AC completed his presentation at this point.
ST started with the non-network
bits he'd added. These are:
This work has stopped while the library situation sorts itself out.
He then moved on to the more important issue - Networking
ST suggested that the 2 key points were:
He then outlined splitting the data passed between client and server into
two distinct streams:
The game can afford to lose some tactical data, but not strategic
The main network issues are performance and security.
We must:
The server would be able to do some of the physics, but not all. It could roughly check what's going on.
EB suggested attaching a klaxon to the server.
ST continued to the architecture: Distributing parts of the server functionality.
SQ enquired about the "[networking] White paper".
ST said that it was being continually worked on, it's not currently ready to be a firm basis for the setup yet.
AC asked when the client/server split should occur. It was suggested that work to start this should occur as soon as the last guile is removed.
Action 2. - To play with various client/server setups to see what's feasible in terms of latency and reliability.
On ST - No fixed timescale.
JQ's report was handed out (see annex):
Notes on 2D artwork:
TT claimed she didn't have much to report. This was obviously not true.
TT has now written 3 stories with a 4th in progress. The stories attempt to cover all aspects of the universe. She will try to write a story about any aspects requested.
The plot should be integrated with the game design, but must be led by what the programmers can do. This should not stunt plot stuff though.
The plot should be developed along side the game. A good plot/universe will help the game to stand out.
AC pointed out the success of the Marathon series on the Mac was down largely to good plotting.
TT continued that the stories help explain plot development. She wondered if the story characters could be tied into the game.
TT sees the stories as a "Flight of Imagination", but not the be all and end all. Stories are not set in stone. However TT would like changes to be fed through her.
SQ suggested getting other mote-plot people to write stories.
TT offered her services as an editor, suggesting "Open Source Writing".
TT - Edwin previously covered a bit, but felt that targets were needed.
EB outlined a 3 stage approach:
EB was keen to avoid setting deadlines, he felt that targets were more acceptable.
EB suggested that using more portable libraries would aid future porting efforts.
AC emphasised the importance of good looks for non 3D cards as well as accelerators. 2D overlays cause problems in this area. 2 different kinds of cockpit design may be needed.
SQ pointed out the importance of aiming at 3D cards primarily, but recognised that there should be 2D only card support.
EB highlighted the need for sound libraries.
AC also commented that the team would need a sound man eventually.
EB discusses the mechanism by which events would fire sounds and pointed out that plib can cope with most sound stuff.
Discussion continued to the next code target - Getting an event handler,
which would allow a basic combat sim to be set up as a demonstrator. To
achieve this the following steps would be necessary:
It was felt by all attendees that the end of August was a good time to aim for completion of this demonstrator, and that this would be a good basis for the network split.
Action 3. - Create release 0.1 demonstrator.
On all attendees - By end of August.
TT voiced concern about communications problems. For example the web pages.
There was also general concern about work loading issues and people trying to move others along too quickly.
SQ urged people to remember that Mote is being done for fun.
EB suggested that we should all be supportive of people with big workloads.
The following rules of thumb were suggested:
ST pointed out that EB is the final arbiter, but some responsibility also lies with section heads.
The role of the main committee should be to help reduce excessive workloads and be a general decision making body.
SQ suggested we have a "Mote Ethos Statement" which can be evolved.
EB finished by saying that part of the core team's job is to keep this fun.
ST referenced back to his earlier summary.
Several transport systems were proposed:
TCP and UDP
Also Sockets versus CORBA. CORBA is probably too slow.
Performance and Reliability, security.
Realtime side transmits as little data as possible.
|
TCP:
|
UDP:
|
UDP doesn't guarantee in order delivery. Two possible solutions:
Timestamping and sequence numbers.
A periodic time sync will probably be necessary.
It is important that the implemented solution is easily masqueradeable and/or forwardable.
It was felt that in the white paper the term "galaxy server" was misleading, and would be better changed to group server.
ST explained the server architecture proposal, and pointed out that some of the labels did not really fit. In particular it was noted that the current wording of the politics server was not so good, and needs to be revised.
There was a short debate of how control between servers and the actions of the jumpgate would be managed.
ST Used the earlier tactical/strategic data split to attempt to characterise the difference between the Universe and group level server behaviour, likening the universe to strategic data, and Group to tactical.
There was also concern registered as to the wording of the standalone mode operation.
Several people noted that sourceforge's ftp and http chug.
EB stated that sourceforge had now largely sorted these problems.
AC suggested that people having trouble with ssh access could look at Mindterm, a GPLed java client.
Action 4. - Inform mailing list about mindterm
On AC - ASAP
EB continued that sourceforge had been having growing pains but that these are slowly passing. He stated that backup plans were in place, but this should not be an issue.
TT pointed out that sourceforge offers projects high visibility.
ST suggested that more skilled developers should help with proving tools to access sourceforge services.
ST enquired if there should be a mirroring of http content.
EB answered yes.
SQ Enquired about where the website should go.
TT suggested a fresh start would be best.
SQ suggested making an official site with links to individual developers' content.
TT felt that centralisation was important, links were an inconsistent option. She also pointed out the need to update mote.sourceforge.
EB pointed out that all developers can access the sourceforge http space. He requested that we appoint a webadmin.
SQ suggested decoupling content and form. Developers could provide the content and the admin would generate the pages.
Action 5. - SQ takes responsibility for management of the webpages.
On SQ - Effect immediately.
SQ resolved to "keep it simple"
EB pointed out that we need a sourceforge logo on the site.
The meeting was adjourned for Tea
AC drew a series of diagrams explaining the operation of the frames of reference.
He explained the frame based nature of the model. Frame changes are carried out by "walking the tree". All frames have a parent, except the central frame.
Object position defined by parent and position vector.
Orientation defined by 2 vectors relative to parent (To be confirmed).
Ship Object has a "facing" attribute within frame.
| Motion | Rotation rate Rotation Axis Velocity Rate Velocity Direction |
Either relative to object or parent.
There was a discussion about defining rotation in terms of absolute x, y and z axes. This would cut down on complex co-ordinate transforms.
It was felt that stationary planetary bodies would suffice for version 0.1.
Ships motion
Basic control would be via pitch and roll
Motion would always be forwards
Speeding up would be easier than slowing down, and max acceleration would be a ship attribute.
All clever ship dynamics would be excused by being done by a "flight computer"
There will be an intra-system minijump operating by setting velocity to a big value. This was seen as a boredom prevention device.
AC mused about the role of angular acceleration
ST & SQ suggested simplifying it down to a maximum turn rate.
A dual mode control model was suggested, with engines on mode providing inertial dampers and engine off giving near real physics.
ST hoped that this would overcome "Chicken runs" and trying to out turn opponents.
There was a brief discussion of missiles, and it was decided that a missile cam would be fun.
AC> brought up the issue of frames and combat. He suggested creating an empty frame of reference for combat, labelling it "Dogfight space"
SQ mentioned a need for some form of IFF (Indicate Friend or Foe) system. Connected to this he suggested allowing players to name groups to join, and tying IFF operation to these groups.
Suggested initial groups included military forces and the Peace corps.
Action 6. Add a property for player's disposition toward groups.
On AC - No stated timeframe.
SQ suggested that there should be control of threat recognition, but no identifier to what the threat was. finding out the attributes of a threat would improve as range shortened.
EB said that a sound man and a 2D art man were needed.
Primarily cockpit displays and texture maps were needed.
He suggested that placeholder art would suffice in the short term.
EB pointed out that there are sound libraries available, which should provide adequate initially.
TT hoped that the demonstrator would get more people involved.
The attendees extended thanks to JQ for his sterling work to date, which is already ahead of the general state of the game. Well done!
EB explained that BSP trees are good for many closely located objects. Good for depth sorting and collisions.
Mote, however can use 2 pass rendering and bespoke collision boundaries as it's not room/polygon based, but object based.
BSPs are not being used ATM, but they may be considered if advantages can be identified.
The attendees decided that this should be carried over to the next meeting. Plaudits for JQs work so far.
ST Introduced the "Integrated Leaky bucket" approach to ships energy supply.
Essentially this offered an energy reservoir to all ships equipment, and a maximum energy flow rate. This could be divided between the equipments, who had different energy drain characteristics. Some would trickle (e.g. shield maintenance, life support), some would dump out in batches (e.g. laser weapons). In general equipment would have a maintenance energy level, below which they would not work. Possibility for increasing energy flow by upgrading energy conduits, and for allowing bigger energy reservoir.
Death was discussed. It was, therefore, decided to investigate the use of automagic escape pods. This would require some serverside plot devices.
SQ suggested allowing people to borrow money, e.g. loan sharks. This would overcome any initial lack of money.
Rich players could become loan sharks. Perhaps the legal state of such loans could be dodgy.
SQ expressed an interest in becoming a loan shark.
Control of money would need to be through a "Central bank".
EB Mentioned that the police would be AI, but able to offer specific missions to players.
The next meeting was proposed for the end of August (28th), location TBA.
This page created by Stephen Quinney <stephen@jadevine.org.uk> using hitop.