1) GUI design and implementation - Jon
- I'm going to comment on this description in parenthesis. The person who does this will need to be clever and self motivated. It would be easy to settle on this and if the GUI designer does that our whole program will look little better than an incredibly hard system that no one would bother to learn.
- The GUI will be designed in such a way that it is easy for the user to describe rooms and objects as well as non-playing characters at a latter date. The interface will also provide the user a way to intuitively modify the values of rooms and objects in response to any taken action taken on an object or in a room. The GUI will further provide the user with the ability to select the room to edit based on a visual overlay of the rooms, and it will allow him to input his own commands that will be available once the text adventure has been compiled. This front end, its design and the interaction with the other portions of the GUI will be designed and coded in their entirety by one of the team. And this design will accurately reflect the functionality of the system.
- After writing this, I think that the ideas I put up on Gliffy may need to be redone. It would just be too hard for the user to intuitively create interaction between rooms and say another room or object. We can all talk about ideas and what we would like, but ultimately whoever chooses this position will have to decide where to go.
(Jon 8-29-7 A hard part here is going to be designing an even system. We need a way that changes in a room will effect that room's variables as well as objects and other rooms. It may be difficult to design that in a streamline fashion. We might be looking at a seperate frame to deal strictly with values and the interworkings of value changes. Then one text entry for the verb and one for the nown, er... one text entry to describe the dropping of the item and another to describe the item after it's value has been changed.)
2) Object and Structuring - Luis
- This portion probably won't require many fancy Java tricks; hence if we want to write the compiler in Java I could probably do either this or the compiler with my current knowledge. Anyway, this person will have to write a lot of code. Anything inside the action statements that doesn't directly relate to the GUI or the file system will be this person’s responsibility.
- The skeleton of the development of the text adventure game will be written by this member of the team. The rooms, objects, commands, and maybe latter non-playing characters will be updated and maintained reflecting the user’s creation in their object forms by this individual.
- This is going to be a lot harder than it sounds I think. Whoever does this is the guy we'll all be waiting on. Also we'd probably need something, preferably not global strings to hold the commands that the user wants in the game. And there would need to be a way that the objects would interact with them accordingly. Did someone say hash table? Just kidding.
(Jon 8-29-7 This shouldn't take too much work, but we need to decide how we will store the commands the user had created. Luis suggested another object, but would we want each command to be an object?)
3) XML file storage and loading - William
- After looking over this description I think that it will be too much trouble to write the compiler in C. This person would effectively be dealing with the problems of both languages. And I think that's too much to ask.
- The working file system of the user’s text adventure will need to be taken care of by this team member. All the items that have been maintained throughout the program: commands, rooms, objects, and maybe latter non-playing characters, will need to be put into an XML format. This format is both easy to read and write, and it will accurately represent the defaults, states, interactions, and commands stored in the objects that were originally inputted by the user. So the code for saving and loading will be taken care of by this individual. It would store the objects to a file and recreate them in the compile phase.
- We need to discuss this but the compiler will need to have the save load potential, so we may want this file guy to help with that.
(Jon 8-29-7 This section holds a more serious challenge. We need to have a way of saving the changes that the gammer can enact as defined by the designer's value change. For instance the fact that turning on a lamp sets its isOn value to true. How will we link the command and the object as expressed by XML? Also, William sugested that we will not save a room state in the XML file. The first state will be the default, and any changes to that will be made at compile time. So rooms will be writen with only an ID, descriptions that corespond to the rooms values, and a ruleset for how their values will be changed, also posibly the location of any items that default to them.)
4) Output compiler - Javid
- I think that I could still do this in Java, either this or the core code, as long as it didn't require to many special classes, because I just don't know them.
- This program would operate independently from the users design phase. This programs intended user would be the actual gamer. The code here will still be java gut it will not have a GUI front end, just a terminal output and input. This final portion of the code will use the same object and command set from the design phase. But, this phase would be primarily concerned with outputting the designing user’s text and interfacing with the gaming user by using the designing users command set. The difficulties here will be primarily dealing with string error handling. But the team member that designs this system will create a bullet proof system that will again accurately represent the objects he has been given in a text only format.
(Jon 8-29-7 Item locations are going to be the deal here. It is difficult to establish if a key chip is in it's socket in the room, on the room's floor, or in the room because it is in the gamer's invantory. I suggested using a double to describe the location, such as if the room is ID 192, in the players invantory would be 192.0, on the floor would be 192.1, and in the sockett would be 192.2. This route has the shortcomming of needing to cast any time we want to find an item, and having a limitted number of locations we could put an item in i.e. location 192.1 is the same as 192.10. Luis and William had suggested an alternitive that objects be given tags that identify whether they alter room states. If we go that route it may still be difficult to determine the difference between a key chip and a torch, and there must be a determination made of wheather the torch is on to see if it will actually modify room description.)