Shareware Overload

home *** CD-ROM | disk | FTP | other *** search

/ Shareware Overload / ShartewareOverload.cdr / games / gkit.zip / GRULES.DOC < prev next >

Wrap

Text File | 1988-05-05 | 15KB | 277 lines

Top Secret Document: GRULES.DOC Project Codename: GATEWAYS Required Security Clearance: Ability to write in (or learn) the C language Last Revision Date: May 5, 1988 Author: David M. Larson (codename: JUPITER) Source BBS: (916)753-8788 Opus Baud: 300/1200/2400/9600 HST Fidonet Node: 203/955 Address: P.O. Box 915, Davis, CA 95617 --- WHAT IS THE GATEWAYS PROJECT? --- It is a project for C programmers or those aspiring to learn C to exercise and develop their creative skills by designing and writing games, simulators, educational programs, or similar programs that can support scoring techniques. These games will be linked together (using an overlay linker) into 1 huge program. Interactions between the games is encouraged. The programs will be written to run in a BBS environment where players will call up with a modem to play (normally one player at a time). Obviously any graphics will be limited or very creative in order to support the variety of computer equipment used to call a bbs. There is a lot more to a good program than graphics, and I know we will have an exciting game system to prove it. Some of the side benefits you can look forward to are: to meet people with an interest in C, to create some new and interesting games that interact with each other, to explore new concepts in programming, to expand your opportunities, to have fun. Anyone is welcome to join the project. If you are an experienced C programmer or a beginner...If you have a lot of time or just a little time once in a while. --- THE OVERGAME CONCEPT AND THE GKIT DEVELOPMENT ENVIRONMENT --- Their will be an overgame control program that will provide functions for your game and will allow the player to move from game to game. The overgame will be a game in itself and the player will have to develop skills to reach the games he or she wants to go to. When your game function is called, it will be passed the current player #, the max number of players, and the current entry gate number for your game and the max number of gates in your game. When you return from your game, you return a gate number. Functions are provided for you to access information about a player from the overgame using a player number. You can use the gate number for whatever purpose you can dream up. A suggested use is to think of it as representing which of several entry points in your game a player comes in by or exits by. A function is even provided for the player to interact with the overgame to decide if he or she is going to continue with your game or go somewhere else. Whether you make use of the gate numbers or not, the overgame will use them to map your game into its concept of space. The mapping may be dynamic or static depending on the skill of the player and who knows what other factors. The Gkit development environment I am providing will simulate the bbs environment and the overgame for you to develop your game with. The kit will be simple in the beginning and progress at the same time your game progresses. Additions and changes to the kit that you and other participants request will be given a higher priority than other enhancements that I may have in mind. I may ask some of the participants to help with the actual overgame, providing functions or small games or ideas. If you think you can help in this area, let me know. --- RULES AND STEPS FOR PARTICIPATING IN THE GATEWAYS GAME PROJECT --- 0. This project is only in the C language. You must be prepared to submit your C source code written according to the rules involved. 1. Find the nearest Opus or Fido Compatible BBS that is carrying the GATEWAYS echomail area. If you cant find one call my bbs (916)753-8788 (or sent netmail to 203/955) and I will arrange for a bbs near you to carry it if possible. 2. Get a C compiler and a full screen editor for your computer. If you have an IBM Compatible, I recommend Turbo C. It includes an editor and you should be able to find a copy for less than $70. If this is too expensive for you, Mix Power C is under $20. If you have a different type of computer, try to find a compiler that supports the latest ansi function prototyping methods and has advanced lint like warnings (It will save you a lot of grief if you are a novice). 3. Find a book on the C language that you can understand. You may be able to use the manual that comes with Mix Power C, but don't count on it. 4. Get the LATEST GKIT.ARC file or its contents. It should be available on bbs systems carrying the GATEWAYS echomail area. This is your development environment and you should download it whenever you find one with a later date. There may also be other files of use there such as C tutorials. 5. Read the GKIT.DOC documentation and other documentation files. 6. Look for a #define line in GATEWAYS.H for your compiler. If you don't find it, leave me a message and be prepared to help me adapt GKIT to your compiler. If you do find your compiler, set that #define to 1 and all other compilers to 0. Also look at the other #define macros that specify what features your compiler supports that GKIT wants to use and change them if necessary. The kit is configured for TURBO C when distributed. There may be tips for setting it up for other compilers in GSETUP.DOC. 7. Compile the example game D0MAIN.C, the G0KIT.C module and any other C modules listed in GKIT.DOC. Link these files together. If you get any errors, resolve them or ask for help. There may be a document file for setting up your compiler for the kit (like GTURBO.DOC). Also there may be a makefile or project file for your compiler (like D0MAIN.PRJ). 8. Run the resulting program. It should validate itself and then allow you to play a simple number guessing game. Whenever you guess correctly, it will quiz you on a concept of the Gateways project (using a list of questions in D0QUEST). Do not be alarmed if you see a simulated carrier loss (its there to give you a realistic testing environment). 9. Look over the D0MAIN.C file with a magnifying glass and add comments for each statement. Feel free to ask me about anything you don't fully understand. 10. Make 3 or 4 improvements to the example game, compile and test them. 11. Start thinking about game themes. You can start with a game you enjoy or a favorite object, place or activity. Write down as many ideas as come to your mind, whether they are small, big, old, original, or silly. Don't judge them at this point. This is your private list. Make it as big as possible. 12. As an exercise, design and implement these string handling functions: (I use the name "string", when I really mean array of characters or character pointers that point to a string of characters that is terminated by a zero (null) byte.) A) Truncate a string at a position N. B) Copy the N leftmost characters to another string. C) Copy the N rightmost characters to another string. D) Copy N number of characters starting at position S to another string. E) Center 1 string inside a larger string. F) Change all the copy functions so that the destination and the source strings can be at the same memory location. G) Given a string that contains 2 words separated by 1 or more spaces, reverse the order of the words. In each of the above, do the following: U) Pass all arguments to your functions including N and S and the char pointers or char arrays (which are automatically passed by address). For example, B could be leftcopy(dest,source,n). V) Do not call any library functions to accomplish any part of the job. If you call other functions, you must provide them. Do not call other functions from inside a loop (avoid the overhead). W) Use pointer variables instead of integer indexes to arrays. They are more efficient. X) Avoid using temporary char array memory. A low level function should use very little memory. Also, if your temporary memory is overwritten by an oversized string, the program will malfunction or crash. Y) Compile and test your functions. If you are confused or don't understand something, try to isolate the specific details of your confusion. Make use of the C tutorials and manuals available. If you are still confused or would like someone to confirm your grasp of a concept, please leave a message (on the GATEWAYS echo) asking specific questions and including any guesses you have about the item (or include examples). 13. Arrange to send me a copy of your changes to the example game and your string functions. You can do this 3 ways: A) Use PKARC or ARC to archive your files into 1 file that has your initials in the name. Upload this file to the nearest bbs carrying Gateways and ask the sysop if he or she will pass the file along. B) Put your files on a 5.25 or 3.5 in MSDOS format disk and mail them to David Larson, P.O. Box 915, Davis CA 95617 C) Call my bbs at (916)753-8788 and upload them files. Also leave me a message in the GATEWAYS area telling me to look for the file(s). 14. Request your two letter code..It will probably be your initials. You must use this code to prefix all your c files, function names, global variables and data filenames. This way there will be no conflicts with other games (at least with names anyway). 15. Take you private list of game ideas. Add any more ideas that come to mind at this time. Now go through and cross out the ideas you don't like and circle your favorite ones (the ones you would enjoy the most). Can you think of a way to combine any of the ideas? Pick one of your ideas and write a description of what the game would be like. Discuss your ideas on the GATEWAYS echomail area. If you have trouble thinking up an idea, we can help. Or we may have some more ideas to add to yours. You can change your game theme anytime, but you need to pick a theme early for a focus for your design. 16. Start designing the details of your game.. A) What will be the functional parts of the game (break it down)? B) What will you be outputting to the user? C) What will you be inputting from the user? D) Are there interactions between players? E) Are there interactions with other games? F) What is the cycle of the game? Does it start and end with each player session? Does it run forever? Does it need to restart itself at some point? G) What data will you be maintaining? (in memory and in disk files). H) What data has to be initialized before or during a game? (Your game must be able to do this automatically) I) Do you need to provide an installation program or editor to allow a sysop to customize anything in your game? J) What kind of documentation do you need to provide for a player to figure out how to play? Can a player learn everything from just playing your game? K) How will scoring work in your game? L) How will game fit in with the overgame? M) Start designing the details: the data structures and functions to maintain them, the main functions of the game and all the supporting functions that you need to write. Feel free to ask for HELP! If you think your game is too difficult for you to handle, try simplifying it or pick a simpler game to start with. If you have a complex game, you may want to team up with other participants nearby and get together to have creative sessions and split up the work. 17. Please inform me of all your data needs.. including global variables, og_malloc() memory, any arrays of anything (that means strings too). I need to keep track of this to make sure I can link all the games together. 18. If you send me a copy of your program in progress every once in a while (even if its not compilable), I can provide feedback so that you wont have a lot of changes to make after you submit your game. Also send your documentation from step 16. 19. Only use your compiler's library functions if they are on the approved list in the latest GKIT.DOC file. If there is something you need that you feel should be in the kit, contact me. 20. Make sure that your game program will compile and run under large or small data memory models. For instance, do not make any assumptions about the size of a pointer. 21. If your compiler supports function prototyping, use it! Create a header file similar to D0MAIN.H that defines all your functions and their parameters. ------------------------------------------------------------------------ --- GKIT.ARC contains the following doc files --- *** IMPORTANT: ALWAYS WATCH FOR A NEW GKIT.ARC WITH A LATER DATE *** GRULES.DOC This file introduces you to the project and gives you the basic rules for joining the project. This file is the only file that will not change much. You are reading this file. GTERMS.DOC This file contains definitions of terms as they are understood at the time. GSETUP.DOC Tips on changing GKIT to work with a new C compiler GTURBO.DOC Instructions for setting up a Turbo C environment for GKIT. Other participants may contribute similar files for other compilers. GNOVICE.DOC Tips for the novice to the C language. GTIPS.DOC Tips for all participants. GKIT.DOC The main documentation file that includes documentation on the development kit files and what functions you can use in your game. The latest changes will be listed here also. --- COMING IN A SEPARATE ARC FILE --- GNEWS???.TXT Some current interesting topics from the GATEWAYS echomail area. If you have something you would like to submit, send it to me. G_ADS Special offers, advertisements and opportunities will appear here. If you have something you would like to put here, tell me about it. ??????????? There may be other files added for special projects.