GCCubed – MemoCube


Upon first meeting representatives of GCCubed, it was decided that the following should be key elements of the project and that these aims must be met. We felt it very important that when visitors to the site arrived, they were greeted with a professional and well laid out design. It should be inviting as well as being interesting. The potential customer should be made to feel at ease whilst being intrigued by the products on offer. It was also felt that whilst we should attempt to keep the attention of the viewer at all cost, we mustn’t lose sight of the fact that the main product is the game MemoCube. Also important to the client was that although it is envisaged that DSL users will account for the majority of hits in the long run, dial-up users should not be left waiting for lengthy downloads.
The primary task of this site is to develop an online presence in the gaming industry and to keep people coming back. It was therefore felt that a chat room and/or multi-user facilities, in addition to the game itself, would be the best way to give users a reason to return.

In order to fulfill these requirements we decided that the best tool for the job would be Shockwave3D combined with Multi-user Server.
The game would be a simple yet addictive multiplayer memory game based around the old ‘Simple Simon’ game of the 1980’s. A player must watch a sequence of colours appear on screen and then attempt to return the same sequence. Each time a player guesses correctly, an extra colour is added and the sequence shown again. This continues until the player can no longer remember accurately the correct order of events, at which point the game ends and a score is displayed. This is an ideal game for developing memory skills as well as being fun and addictive. Included with this would be a chat room so as to be able to challenge other people whilst conversing with gamers from all around the world. This chat room feature, not only gets around the logistical problems regarding physically challenging another player but also increases the ‘stickiness’ of the site as a community begins to grow. Upon researching other, similar games and sites online, it was discovered that the average time a user had to wait was between 2 and 4 minutes. This, we felt, was totally unacceptable. A major priority for us therefore was that the entire loading sequence should not take more than 1 minute on a 56k dial-up connection.
At this stage it wasn’t known exactly how this would be achieved and it was felt that other, similar games must take this long for a reason. After some initial research we realised that the best way to keep file size to a minimum would probably be to use Directors own primitive objects and 1x1 pixel Shaders. This was chosen in preference to building a complex very fancy looking cube in a 3D package such as C4D which would, in essence just be a very inefficient fancy looking cube. The vast majority of the final file size could therefore be used on the game interface and the backgrounds within the 3D world.
The backgrounds used in the final product were mostly created in Director after initially experimenting with images made in Photoshop. The Photoshop images were simply too large in file size averaging around 200-300k each whilst the ones made in Director averaged 15k. This meant that for the size of one Photoshop image we could have up to 20 Director backgrounds. Eventually we settled on using 8 backgrounds, picking one at random, at the beginning of each game. The background is an important feature, as it is this that distinguishes that it is the camera moving and not the cube. The fact that the camera moves creates the confusing aspect of playing the game and as such, makes it harder.
The use of these backgrounds gives the company, GCCubed, the ability to advertise various products within the game in the future. It is worth noting however that if these adverts are produced in an external art package, the file size will increase dramatically. One way around this is to take advantage of Directors inbuilt ability to make use of extremely small .swf files exported either from Photoshop or flash. Unfortunately it is not yet possible to make use of animated flash movies as a background texture within a 3D world but it is certainly possible to use a still picture, saved or exported as an .swf file, within 3D worlds.
An important element within any multimedia production and one that can change a person’s whole perspective of a game is audio. For MemoCube, it was decided that the music used should reflect current relevant trends and that an uplifting dance orientated sound would be ideal. Along with this background music, would be the sound effects of the movement of the camera. When the game was in its early stages, the camera was visualised as being on some sort of robotic arm that move and then clicked into place when it reached the correct side of the cube. It was therefore thought apt to use a sound that would inspire similar thoughts in the mind of the user. To achieve this we used a virtual analogue synthesizer to create just the right sound. We feel that the musical genre and the technological vibe of the sound effects combine well to produce the futuristic atmosphere we required.
At the time of writing, the current compressed shockwave file size is approximately 128k with the director movie being around 2.1Mb. The vast majority of this is taken up by the interface and the sound effects. These, together, account for 1609k. The Textures and Buttons, all made within Director, add up to approximately 2k and the backgrounds, which were all made in Director, except one, total 364k. The rest of the 2.1Mb file is taken up with scripting.

In conclusion, we feel we have successfully fulfilled most of our criteria fully and all of them at least partially. The final product is certainly functional and eye-catching whilst being upgradeable.
A number of elements that were originally thought possible turned out to be simply too adventurous to put in to action. Imaging lingo for example was initially going to be used within the 3D world instead of backgrounds. This would have helped keep the files size down as all the effects are created by the computer in real-time rather than being cast members. The visual scope this would have given us would have been outstanding as the effects could have been anything from one-off, never to be seen again, fractals to simple animated graphical logos. This posed too many problems however, not least the fact that we weren’t able to find out anywhere, whether or not it is possible to incorporate imaging lingo within a 3D world. Then there was the problem of actually learning the syntax as well as the equations necessary to create even a relatively simple effect similar to the example shown at http://www.stormsky.com/content/wizzy1/wizzy1.asp. In future versions of MemoCube we hope to implement something along these lines.
Another element we weren’t able to incorporate in time was different difficulty levels. We originally thought that simply increasing the value of the variable gSpeed would work. This did indeed make the game harder by making the camera rotate around the cube quicker, but also meant that we needed different music so as to fit in with the rotation of the camera. This in itself wasn’t so much of a problem until we realised that for the sound synchronization to function correctly, gSpeed had to be devisable by 10, 260 and 300. With gSpeed initially set to 10 the difficulty was about right for a ‘Normal’ or ‘Intermediate’ level, but 20 was just too quick, even for the most difficult of levels. Perhaps with more planning this could have been avoided. It may also have been possible to tailor the sound more to the user’s tastes by offering a selection of music or randomly picking a different track.
One major problem we encountered when publishing the site live was that web hosts were not overly keen to let us use multi-user server on shared hosting machines. This left us with two options. Firstly to pay between £100 and £300 per month for the privilege of our own rack server with MUS on it and enough bandwidth for the amount of potential users or secondly to investigate the option of an in house server giving us not only total freedom regarding the multi-user software we choose to install but also the ability to host other similar future productions. Third party MUS software is certainly available such as Tabuleiro’s Nebulae http://xtras.tabuleiro.com/products/nebulae/index.tdb but does not come cheap. This second option has bandwidth limitations however and must be considered in depth before making a decision. Attempting to off-set the price differences in software, hardware, bandwidth and of course technical support could end up proving unrealistic and pointless.
The possible addition of a login/register page before the chat room is another facility that might be introduced in an effort to create a ‘sticky’site. Combining different technologies such as PHP, mySQL and CGI scripting would enable GCcubed to keep a database of registered users as well as gain vital information on the number and frequency of visits to the site. This information could then be used to entice 3rd party producers and advertisers as well as providing GCcubed with quality information on the games that are more popular for instance, whilst providing the means to send out newsletters to interested members and keep track of high scores. This would all contribute to help GCCubed.com become a successful gaming portal.