Programming in C++

Design Paradise was programmed entirely in C++. This was done for a number of reasons. The first was the power of C++. Originally, it was proposed that Design Paradise be re-programed in PERL. After trying to program with it for over 2 months, we found PERL's weak structures and abilities did not suit the task. Design Paradise was then re-programed from scratch for C++.

C++ was also chosen because our programmer Jeffrey was familiar with it. However, finding support for it was another story. We had to look high and low for the support for CGI. After reviewing numerous CGI interfaces, we came across Thomas Boutell's GD and CGIC libraries.

C++ is an excellent language in which to program. Unlike other languages, C++ has the ability to be ported onto other platforms. In layman's terms,it means that almost any operating system can use it. For example, Design Paradise was programmed using Turbo C++ 3.0 for DOS. It was easily placed onto the Think Quest server and compiled. If for any reason in the future some school would like to use our program, itis easily modifiable and compatible on their own system. C++ is available for almost any operating system.

C++ has the advantage of power and speed. It is a compiled language rather than an interpreted language. This allows the program to execute many times faster than a language such as PERL. Because of the speed, the program is loaded into memory, executed and quickly deallocated from memory. This frees server resources and is much friendlier to everyone on the server.

Several aspects of C++ allow it to be a much more flexible programming language. For example, in C++ you are able to create multidimensional arrays, structures, and classes that are normally extremely, if not impossible, to create with other languages and Object Orient Programming. Although Design Paradise does not fully utilize OOP, it has the ability and potential to be easily and fully converted in the future.

Unique and Powerful Data Storage

Another powerful feature of the game is data storage. It allows users to save their accounts. Thus, users may return and continue their games,increasing their level of competition and involvement in the strategies and underlying concepts of Design Paradise.

In addition to encouraging repeat usage, our program keeps track of the highest ranking players. This allows our users to shoot for something higher than they normally would on a "closed system." We hope this will spur sharing and collaboration in our Bulletin Board.

The reason why our data storage is so unique is that we actually create a file name that is unique for each individual user. This addresses several problems. Growth and searching problems. Our program creates a unique ID number for each user via a mathematical equation. This is a process known as hashing. When a user logs in again,this equation enables the program to locate the user record quickly and load the file. Our program stores the records in file names by the [8.3]standard that DOS uses. Again this addresses a portability issue.What this means is that the probability of two users receiving the same file name is reduced to well under 1 in 100000000.

We could have stored our information using alternative methods. For example, the worst way would be to store data all in one file. This means that it would take an immense amount of memory if the data file takes too much space and also it would mean certain doom if searching for the last record in a large file. The second way would be to index all the files and sequentially number the saved files. Again this would mean searching the index. The third and final way would be to name our files [first name].[last name].data. However this brings to mind the portability issue which we addressed earlier; not all systems can handle such filenames. Our program is able to handle up to 40 characters for the first name and another 40 characters for the last name. This alone exceeds many operating systems' file name size limits.

Educational Values

Design Paradise from the start was intended as a challenging and engaging learning device.

Our site features several unique aspects. For example our game is scored differently. While most games place emphasis on the amount you do, how much you build and create, our game emphasizes balance. In real life, nobody wins if you overdevelop a city. In our case, residents on Kauai enjoy the rural atmosphere and the beauty of nature. Because of this, if you pursue growth at the expense of balance,you are actually penalized for it. In addition, we have an additional factor that is extremely important. It is the happiness factor. The residents on Kauai will complain if you develop too rapidly or in the wrong areas. On the other hand, the you are generously rewarded for developing moderately and balancing growth for the island.

We allow people to download our source code. Normally people hide their source code for fear that someone else will learn their trade secrets. Design Paradise decided that it would benefit other schools and countries if the source code were released.First of all, programmers are able to modify the source code to fit their area of simulation. If for example, a school in Tokyo wanted to change some of the graphics, and messages in the game, they could just edit the source files. If they wanted to create their own maps, the could also do that.

In addition to allowing customization for other purposes, we also provide the source code as a learning tool. New and beginning programmers can learn some of the framework needed behind a complex game. Also, we have left ample opportunity for programmers to improve and modify the game to be even better than it is now. Our only request, tell us if you use it, and use it only as a learning tool.

Internal Mechanics of Design Paradise Simulation

At first glance, our game may appear to be a simple CGI script. Sure just place a picture here, click there and viola, a ho-hum site. However, most people would not imagine the amount of mathematical analysis that actually takes place behind the scenes of the game.Each tile has a whole set of factors that makes the game tick. On the tile there is soil, zoning, and a structure. Each of those three factors have their own growth effects. These factors are based on true values that were compiled through numerous documents and interviews with industry experts. Factors control the growth of commercial, agricultural, residential and tourist industries. Depending on the type of structure you build and where you build it, the game will calculate the correct reaction.

The game also checks the tile's surroundings. For example if a hotel is built adjacent to an agricultural plot, naturally, residents become unhappy and both tiles will develop slower economically. If a mall is built right in the middle of conservation land, the mall eventually drags the whole economy to a halt.

This may still seem simple, however in addition to calculating growth,the game accounts for the people's reactions to the structures being built.The game checks to make sure the proper amount of open space is left when developing. It keeps track of the current economic status of each tile and actually records each tile separately. It can calculate the amount of time it takes to build each structure and actually compensates for a structure being built in some areas that would actually cost more in real life.

Most amazing is the type of analysis the game does depending on the different modes people take in the game. While some people may build on all three maps provided, others may choose to play on only one.When this happens, our ideal population and employment is molded to the map. In real life, people live in one area more than another while they may work in one area more than another. Our game realizes that and compensates for the different areas. While some games are simple and just place constants for these adaptations, our game actually calculates these figures automatically. If we were to change the type of soil or zoning in any map, the game would recalculate everything it needs to make the game run correctly. There is no intervention on the part of the programmer for this, and thus makes it a great learning tool for other schools around the world.

Quick loading times

Our site was designed with many browsers and formats in mind. Also loading time was of great concern. Briefly speaking, we optimized images and also provided multiple tracks for different browsers.

Most of our graphics include an alternative text description if a browser is text or if the user decides not to load images. This is a common thing for users to do if they have a lower speed connection.

Our game, however, is even more complex. Our game outputs a large amount of text, for example, in graphics mode, each of the three map images is actually composed of 340 separate GIFs. This is quite something when you consider the following:

In Graphics:  <td><img src="the_name_of_the_picture.gif" alt="something"></td>

In Text:  "something"

If we output the graphics version of the HTML for the text user,for every tile (which is 340 times) you can see the unnecessary load that is placed on both the server and the client. Our game is able to modify the output of the game to best suit the situation. In graphics mode, the compression that is built into most newer modems is used to zip the text in the HTML often time 3-4 times faster than usual. This text users to benefit from the best of both loading times and appearance. This modification is transparent to the user after an initial click of the mouse on the game application screen.

For Graphical users of Design Paradise is able to have full of graphics graphics with very low loading times. This is because we employ a technique used by the most complex of games today. Because not every individual point on the map is unique, we are able to tile the graphics to create the map. So if there is a large area filled with grass, we repeat the same graphic over and over. Belive it or not, in most maps, the total amount of graphics is under 1,000 bytes! This results in complete and fast loading maps of Kauai.

Our zoning map may seem to load extremely quickly. Believe it or not,that original image is just over 100 bytes. Using special HTML tags, we are able to magnify the image to the size it is now. In fact, we could make it 10 times as large on the display and still have very little effect on the loading time. This trick of the trade is made possible because of the low amount of detail needed in the zoning map.

SSI Server Side Include Issues

Early on in the competition, we decided not to use SSI in our web page.The disadvantage was that we had to update more files if we changed anyone thing that was of global concern. Moreover because SSI was not fully functional for the majority of the contest, we concluded the following.

• System administrators play a big role in enabling SSI. If we try to offer our site and programs to other individuals and educational institutions and they encounter the same problems as our server, it would mean certain doom to the program.
• In addition, SSI is an internal function of the Web Server. If that aspect of the web server ever failed, our site would be drastically hindered.The probability of a complete web server crash is much lower,which makes our site much less prone to failure.

CGI chatter and other forms of collaboration

CGI is a wonderful tool. For example, if we wanted to place a guest book in our site, we could just borrow a script from any one of many sites on the Internet. However we didn't think just throwing in as many scripts as we could possibly find would help the site. In fact, sites that do so actually detract from their overall presentation.

We carefully picked the scripts we wanted to use. For example, we do not consider guestbooks a valid measure of the effectiveness of our site for several reasons. For most visitors to a site, motivation to sign a guest book is usually to claim a reward offered by the sponsor. Guest books are also more of a novelty than a true collaborative tool. The nature of the tool is one-sided.

Chat software and simultaneous multi-user environments are nice. However through monitoring of the IRC and other Web Chat programs all over the Internet, we find one interesting fact. In almost any multi-user environment, it is a rare event to see two people chatting. This is due to people poking their heads in, asking if anyone exists and then leaving when finding nobody else is present to talk to them. People tend not to wait for another user because of the short attention span of internet users. Another problem is that chat messages are soon lost when the either users leave the chat room or a certain amount of time passes. The loss of information is not acceptable when trying to create collaborative environment between many students. These factors convinced us to eliminate our cool chat page lest it become a distraction.

A bulletin board has several advantages. First of all, all your messages are saved. They are easily accessed in a newsgroup-like form. This means that whenever someone asks a question, they can easily ask and walk away. They are able to return at a later time and read the responses. This eliminates a lot of lost interaction when using a chat room as a primary source of communication. The only problem left was worrying if the players would return to see their responses. Our problem was solved because the users can choose to have all responses e-mailed back to them. In addition, we find that people generally check their e-mail religiously. So we concluded that the BBS was definitely the best avenue to create collaboration.