Status Updates
2008.02.25
Final Demonstration today. More details to come.
2007.12.10
Our Fall Semester Paper is available.
2007.12.03
Our entire group gave our final Fall Semester presentation/demonstration today in class. We demonstrated our code running in Marathon.
2007.12.03 Meeting
Our entire group met at Volition today from 1pm-2:30pm for a milestone review meeting with Stephen Horn.
Of our five major milestone goals, we completed four.
- memory management
- write events to file
- server reads from file
- XML to code generation
We did not complete server-database interaction
nor are we yet creating any database code from XML.
For our next milestone on 2008.01.14, we have decided on the following goals, which we believe will be reasonably easy. We did not want to give ourselves too much work over break and then end up doing nothing.
- XML to database generation
- QoS-enabled networking simulation
- custom data types
- server-database interaction
- server thread load balancing only if there is extra time
- server event type parsing only if there is extra time
2007.12.01 Meeting
Three of our group members (Erich, Robert, Joseph) met at Siebel Center today from 10am-11:30am to plan for our final (semester) presentation and the second project milestone meeting with Volition.
2007.11.12 Meeting
Three of our group members (Erich, Robert, Joseph) met at Volition with Stephen Horn from 1pm-2pm to discuss our progress and review our schedule.
We made the decision to set 2007.12.03 as our next milestone date. Goals for the next milestone include:
- memory management
- write events to file
- server reads from file
- server-database interaction
- XML to code generation
Stephen has stated that it would be nice to be able to get something to the Quality Assurance team, so they can start doing some testing. This milestone aims to get our project at a state where that is possible.
Based on the milestone decision, our schedule has been updated.
2007.11.05
While preparing for the technical demo, we came up with a number of technical questions for Volition to answer. Paraphrased answers from Stephen Horn are shown immediately after each question.
- Does the QoS system guarantee that data we give it will be sent atomically? If we can fit multiple events in a single send operation, are they guaranteed to all arrive in order or all be dropped? Game code will handle this.
- If the QoS system gives us space that can fit more than one event, should we squeeze events together in the same send operation, or should we stick to sending one at a time? Yes, pack as many events as possible in each send.
- When sending a packet, will we write directly into a buffer that the QoS system provides, or will we send a pointer to a buffer we have created that the QoS system will copy? Game Code will provide the buffer. When sending events to the Game Code, we need to tell the Game Code how much of the allotted space we have used. The function definition should be something like
int log_send_events(char * buffer, int size); - Should we perform our own allocation from the 256 KB given for all variables, or are we allowed to use automatics as well? If we can use automatics, what, if any, constraints exist (e.g. number, size, etc.)? For example, can we do
for(int i=0; i < CONSTANT; i++)knowing that an int will automatically be allocated? Our limit does not include automatics. Those are free, so to speak. But do not abuse this by constantly creating and destroying things if it can be helped. - Should the system implement a fixed constant number of levels of priority, or should the number of levels be arbitrary? Arbitrary.
- Should priority be specified in the XML event definition, in the configuration profile, or internally? Internal priority would be dynamically determined by giving "older" events that have been waiting around higher priority. Store priorities in the configuration profile. We should transmit oldest events first. The priority should only be used to decide which events to delete first when memory is running out.
- Are we allowed to use memcpy()? Besides the STL, what else do we need to avoid? Avoid memcpy() if possible.
- Should we be using Visual Studio? Not necessary.
2007.11.05
Our entire group gave our first technical demonstration today in class. Everything went according to plan, as detailed in the last few days updates.
2007.11.04
Three of our group members (Erich, Joseph, Jesse) met today at Siebel Center from 7pm-10:30pm to finish preparations for the technical demonstration.
We finished integrating a most basic prototype into Marathon. The code is capable of adding events, along with some basic event data, to the logging system. The events (and data) can then be extracted from the system when needed.
Much of this solution ignored the technical requirements in an effort to get something working by the specified time. For example, we are currently using an STL list for the event data storage, which will be replaced by a data structure which we are building in the future. Also, all of an event's attached data is assumed to be 4 bytes in length for now. At this point we are also not printing to file or sending anything over the network.
2007.11.03
Three of our group members (Erich, Robert, Joseph) met today at Siebel Center from 1pm-3pm to continue preparing for the technical demonstration.
2007.11.02
Three of our group members (Erich, Robert, Joseph) met today at Siebel Center from 9am-11:30am to prepare for the upcoming technical demonstration, which will be done in class on Monday 2007.11.05.
We started coding the Logger class, which will be the class that the Game Code interacts with. From the Game Code's perspective, there are two functions associated with the Logger class: add_event and send_events. Events will be triggered via Logger.add_event. When the Game Code is ready to send event information to the server, Logger.send_events will be called.
Our goal is to get this basic interaction working and integrated into Marathon for the demonstration.
2007.10.26
Our entire group met today at Siebel Center from 9am-11am to update and assign resources in the schedule
2007.10.22
The final requirements document was signed today by Stephen Horn (Volition) and a copy was handed in to Professor Woodley in class.
2007.10.19 Meeting
Our entire group met today at Siebel Center from 9am-11am to continue working on a detailed schedule.
2007.10.17 Meeting
Three of our group members (Erich, Joseph, Jesse) met tonight at Siebel Center from 5pm-6pm at to discuss a detailed schedule. We started to design the schedule in Microsoft Project, but decided we had to stop and continue at a later date when all of our group work together.
2007.10.09 Meeting
Our entire group met tonight at Siebel Center from 5pm-8pm to discuss the requirements document. We modified the document according to Stephen and Professor Johnson's comments and have sent this new version back to Volition for review.
We still have some details to figure out, like defining continuous events in the event definition XML, but we are getting very close to a final version.
2007.10.08
Stephen Horn (Volition) reviewed the requirements document and responded with some requests. He also returned the requirements document with some comments.
- more detail, especially interface
- sample API
- XML schema
- enough detail to plan a task schedule
- a second document with the actual task schedule: who, what, when
2007.10.06
Professor Johnson reviewed our requirements document and gave some good suggestions.
- don't use
we
andyou
- give more background about what runs on client and server
- list data formats
- define server-client interface more precisely
2007.10.05 Meeting
Our entire group met today at Siebel Center from 10am-12pm to discuss the requirements document. We re-organized and cleared up some of the text that we felt was confusing, contradictory or unclear. Erich has reformatted the document and sent it back to Volition for review.
2007.09.24 Meeting
Our entire group met at Volition today from 2pm-3:30pm to discuss the requirements document. We are now in the process of updating the requirements document to mirror what we discussed in the meeting.
2007.09.21 Meeting
3 of our group members (Erich, Robert, Joseph) met today at Siebel Center from 10am-12pm to discuss the requirements document. Stephen Horn (Volition) sent us a draft version. There were a few requirements that we thought needed some clarification. We will schedule a meeting with Volition to discuss these issues.
- For the unique user id, should we plan on using the gamer tag? What about player's without gamer tags, like QA perhaps?
- We need some clarification on the "server polls client" requirement.
- For single player environment, does the client still need to wait for the server to poll?
- What type of information might be attached to a continuous event?
- Also, for continuous events, does in-event information need to be retained? (for example, position during the event)
- Can we assume that any custom data types attached to events will be serialized?
- Are we concerned with logging specific draw operations?
- Will each game have its own logical server and logical database?
2007.09.16 Meeting
Our entire group met today at Siebel Center from 6-7:30pm to discuss high-level design ideas.
Stage One: XML Defined Events
Game events shall be defined in XML format.
Stage Two: Inline Function Generation
Inline functions will be generated at compile-time. These functions will be generated in accordance with the XML Defined Events. These functions will wrap a small set of generic event functions. These functions will enforce the standard set by the XML Defined Events.
Stage Three: Client to Event Server Communication
There will be a server that will serve as a layer of indirection between the Client (game) and the Event Record Database. At run-time communication between the Event Server and the Client should be attempted.
Stage Four: Event Recording Profile Retrieval
On successful communication Client to Event Server communication, the Event Server shall report to the Client all valid Event Recording Profiles. These profiles will define the set of Events which the Client should report, and conversely, the set of Events which should be ignored (not reported). The Client should select one of the given profiles.
Stage Five: In-Game Event Reporting
During gameplay, events will be reported the Event Server. The Event Server will do some pre-processing, before sending to the Database. The Event Server will check the type of analysis required by the event: detailed or statistical. Detailed analysis will require that the event be sent to the Database. Statistical events will remain on the Event Server until sufficient event information has been accumulated to justify the event statistics to be sent to the Database.
Summary
For now, we have ignored the Database Server. Also, any and all of this could change once the Requirements document has been completed.
2007.09.14 Meeting
Our entire group met today at Siebel Center from 10-11:30am to come up with a rough schedule.
| Date | Milestone |
|---|---|
| 2007.10.01 | Overall Design |
| 2007.11.01 | Rough Event Definition API |
| 2007.12.01 | Final Event Definition API |
| 2007.12.01 | Packet Protocol |
| 2007.02.01 | Database Design |
| 2007.03.01 | Reporting API |
2007.09.07 Meeting
Our entire group met with our sponsor at Volition, Inc. today from 10-11am.
Agenda
- Project Summary
- Existing Code
- Requirements Document
- Milestone Schedule
- Recurring Meeting
- Alternative Contact Information
Notes
- Our sponsor is now Jeff Thompson, since Mark Allender is going to be too busy.
- Jeff talked about how the final product will be used for Quality Assurance, Marketing, etc.
- There is a hacked-together solution that they have been using, but our goal is to build something much more general, easier to use and with more features.
- We talked briefly about the specifics of the implementation.
- We will most likely end up using a MSSQL database possibly interfaced with an API for grabbing data.
- Network communication can be with standard Berkeley sockets, and UDP is probably going to be necessary for efficiency.
- We will need to allow for multiple event collecting profiles, with each profile collecting a certain set of events.
- We will have access to the person responsible for the current solution. We need to get his information.
- Jeff is going to have a machine set up for us to use for CVS.
- Jeff asked us what we would like to use as a testbed for the project. We are going to be using FreeSpace.
- Jeff will be drafting and sending us a requirements document next week.
2007.09.03
Our sponsor has been contacted and we have a meeting scheduled for Friday at 10am.