28 of January

This page will not be displayed correctly without the shockwave plugin you can download here

Below: downloading Connect 4-3D game 4Mb.

In a perfect word, as professional, before creating a game, a design document like the one following has to be done... It has to plan the schedule of the elaboration of the game and help the designers team(?) to structure its progression. In my case, as many students I think, as artists too, the last thing I did was that design document !
However I have written the keywords of my progression every weeks since the beginning.


Week one: the idea, some rules, the media to use, first questions.
Week two: conception of the 3D field of action, exportation from 3DMax and importation in Director of Macromedia.(errors, problems, tips and tricks)
Week three: get lingo controlling the main events triggered by the player interaction. (changing shader and visibility of models with accuracy, moving around the 3D environment).
Week four: new rules, system of lists keeping in memory the state of the models during the game.
Week five and six: creating frame script interpreting selected cubes and redirecting game.
Week seven: first tests.
Week eight, nine: creating script for game against computer.
Week ten: creating the interface, the menu and the options of the game.
Week eleven: design and errors fixing.
Week twelve: presentation to real players. Improvement thoughts.
Week thirteen: publishing.




Week 1

The Idea:
A 3 dimension version of the traditional game “Connect 4”, playable by one or two players.
The platform: Mac and PC.
The media: a Director projector, for CD-R or others and a shockwave version for the Internet.
First ideas for the rules: Within the boundaries of a 3D environment, players, each in their turns, have to select, drag(?), pawns and align 4 of them in order to win.
First questions:
-what kind of boundaries for the field of action ?
-what kind of pawns ?
-how can players select their pawns ?
-who first starts ?
Next Step: build the 3D environment in 3DMax, export it as W3D for Director of Macromedia, and then try to answer those previous questions.

fig.1

Week 2

According to the rough sketch of the 3D environment (fig.1), the field of action is included in a 3D frame in the shape of a cube that becomes the boundaries of it. The pawns are smaller cubes that can be disposed with a maximum of 5 cubes on each axe X,Y and Z or a total of 625 cubes.
Knowing that lingo can create 3D models on mouse action, is it better to only build the boundaries in 3DS Max and then leave Director creates the pawns as players play ? In that case, Director has to create them with a good dimension and then place them in a good position to keep a correct alignment.
Would not it be easier to create all the 625 pawns in 3DMax and then set their visibility on or off according to the will of the players ? Well, I have decided that this would be easier... It is only a question of choice.
Problems when importing 3D environment in Director:
- the size of the boundaries are too large,
- size of the whole member too small,
- impossibility to put any 2D graphics on top of the 3D member, so if any text field to display the score or whatever have to be used, they have to be by the side of the 3D member . That brings me to already plan the disposition of the area of the game.(fig.2)
Others questions popping up:
- how to view each side of the “BigCube”(name of the field of action and its boundaries). Do we have to turn the “BigCube” (and all the smaller cubes with) or is there a way to turn around it ?
Next Step:
-Find a good disposition of the 3D member and other components, find an appropriate size for the whole area of the game(Director movie).
-Try to turn around the “BigCube” using 3D camera controls within the behaviours library of Director.
-Try to set the visibility each different small cubes.

fig.2

Week 3

Without getting bogged down in details of problems of exportation from 3DMax to director, some points however need to be highlighted:
- using Orbit Camera behaviour in the Director library, I have noticed that at some points the initial ambient light of 3DMax was not lighting the “BigCube” enough. So, I have added lights.
- to give a start with the 3D lingo behaviours, I have first used some of them randomly, to see what description behaviours list were proposed and I have noticed that I could select each one of my models by their name. So, I had to get back in 3DMax to rename each one of those (for an easier use later in the game).
Decoding the lingo scripts from the library and compiling some parts of them in order to achieve my own ones, some problems and questions occurred:
- the ‘on mouse within’ handler is not taking the 3D models of the 3D members into account , but the members by its whole, an independent selection of models need to be set.
- how can the handler ‘on mouse within’ highlight cubes to give an idea of preselection(fig.3) ?
- how ‘on mouse within’ will react if under the mouse are more than one model ?
- Is a model not ‘viewed’ if its visibility is set to 0 ?
- how can players select cubes in the middle of the “BigCube”?
And that is I think so far the harder part of the programing: select an object with accuracy.

Done:
-An on key press “shift” action has been set up to turn camera around the y and x BigCube pointing at the the centre of it. Like an orbit camera, players can now view the field of action by many angles they want.
-An 850 X 600 director stage.

fig.3

Week 4

Because of those problems of selection and for an easier playing, some new rules have now appeared:
- players can only select cubes by the side of those previously selected.(fig.4)
- the first cube of the game is randomly selected and attributed to the second player or the loser of the last round.
The function modelsUnderLoc( ) returns a list of models localised right under the mouse (even if the visibility of the model is set off).
The objective is now to put all small cubes in a list at the beginning of the game and set one of their property as “ready-to-select” or “not-ready-to-select”.
Then make a loop with each items of the list of models under the mouse and look at the other list to see if the cube is “ready-to-select-” or not. Then, using the shader property of the model, set the visibility to 50% and make it flashing.
And then, most of the code controlling the 3D environment is done! Now, I have to change the event of the shader according to a “on mouse within” and a “on mouse up” handler.
Next Step:
- Adding a property within the list of models that sets for each object who of the players have selected them.
- Setting an inter-frame called “Interpreter” in the game that looks at that list every time after a player has played, to see whatever 4 cubes of the same player are aligned, or if there is no more cubes to be selected (draw game) or if there is no winner and still some cubes to be selected, set the “ready-to-be-selected” property for the cubes close to the one previously selected.
That brings me to start to set the time line of the game (fig.5) and set some global variables.

Done:
Two global variables gcoloursP1 and gcoloursP2 are set at the beginning of the game to define the colour rgb(xxx,xxx,xxx) to add to the shader of the model selected.
That way, the model takes the colours of the players when they click on it. That global will be set later by a button within a “interface menu”.



fig.4


Week 5 and 6

A first frame sets the world to its initial set up(visibility and shader of models), sets some global variables like the list of models and the colours corresponding to the players, then sets within the list of models a random model to “P2” (owned by player two).
Finally the play head goes to the frame call “Interpreter”. That frame, according to the global variable gLastCubeSelected (set by the first frame if beginning of the game), looks for winner or draw game or sets cubes to be selected and then, according to the global variable gLastPlayer goes to the frame “P1” or “P2” (player one or player two).
On both of these frames are set a “go to frame” action that waits for an “on mouse up” triggered by players to set the global variable gLastCubeSelected and gLastPlayer again and finally a “go to the frame interpreter”... and so one...
- How the interpreter looks at a winner or a draw game ?
Well, this is a question of math and calculation/combination of list, this is not very complicated, but I leave you ask me to have the free source code, because I won’ t explain it here.


fig.5

Week 7

The whole of the scripting is now done and a serie of tries and tests has been made within that week.

Week 8

So, now what about a virtual second player ?
Playing against a computer is it a such challenge to program ?
Well, are you good in maths ? Because that is the question. Technically, I keep the same timeline of the previous game (2 players), but the script of the frame “P2” has a bit changed...
What that frame has to do ?
Instead of waiting for an action of the player 2, that frame has to select itself a cube. But not randomly, one cube has to be selected in order to win or in order to defend itself. The script does quite the same than the frame “interpreter” but instead of just looking for 4 aligned cubes, that frame first looks at its cubes and establishes four lists of probabilities.
The list A contains the cubes to be played to have 4 aligned cubes, the list B the cubes to be played to have 3 aligned cubes, the list C the cubes to be played to have 2 aligned cubes, the list D the cubes left to be selected.
The same is done regarding the cubes of the player. Then both 4 lists are compared like:
- if list A of computer is not empty then play one of the cubes listed in it.
That means the computer wins.
- if list A of computer is empty, then if the list B exists AND the list A of the player is empty then play one of the cubes listed in that list B, unless if the list A of the player is not empty, choose one cube of that list or the player will win the next round. And so on...
Understood ?
That works fine... That frame has now to set some variables, like the owner of the cube selected within the list of cubes and some others global variables used by the “interpreter” frame.



Week 9

Don’ t think the computer playing scripting has been done in one week!

fig.6

Week 10

Time to add the “Menu” frame(fig.6) which is the interface where players can select a range of options before playing.
- A first button: the “select game” that selects a two or a single player game. It works very simply: it sets a global variable that will tell the “P2” frame to execute or not its ‘computer script’. Simple !
- An new option “Round” can be set in order to play a multiple or single round game. The same way as the global variable used for the “Select game”, the button sets as a global variable gRoundType, a number of rounds: 1, 3 or 5. Then, a button “Play again” (appearing at the end of each individual round) decrease that variable of 1 and get back to the “Start” frame which either sets and plays a new game or goes to the first frame of the game, that new frame added to the timeline is called “initialise”. The variable gRoundType is used at the beginning of each round to set a text field showing the rounds won by both players.
- The same way, an option “Time”, sets a laps of time(second) to play for each player round and tells the animation to change player if no actions has been done within that amount of time.
- A choice of “Music” and sound effects is available as well: when set, a list of members(sounds) is created, and while playing the game, according to handlers and events(on mouse up, or while a displaying of a draw,loser,winner screen) a member of that list is chosen to be played.
- A choice of “Colours” is also available.

Week 11

Week of tries and tests, fixing minor errors found within scripts. I have finished the design of the whole game:
-choose a font suitable for a 3D game,
-choose a range of music,
-aligning objects on the stage and
-adding a flash intro to present the game(You know the Idoia thing...). I have designed the winner screen adding a film loop(little animation) to give the game a more enjoyable side and highlighted (using a flashing unique colour (white)) the aligned cubes that make the player wins.


fig.7


Week 12

Friends at University helps me (as guinea pigs) to understand the needs of players and what they don’ t like to be annoyed by( difficult menu interface, too long before playing...).
Thanks to critics, I have changed many things (presentation, quick access to the game by setting default values to options...) including the highlighting buttons:
When many cubes have been selected, it is difficult indeed impossible to see the colours of cubes in the middle of the “BigCube”, then impossible to know who owns them.
Those buttons resolve that problem setting the visibility of cubes by level 2,3,4(fig.7).

Thoughts to improvements:
- the camera movement is sometimes not intuitive enough,
- four smaller stages added somewhere to display cubes level by level(fig.8), instead of using buttons.
- a “Score” screen which stores name, score and time.
- an intelligence computer playing that learns from its last defeats.

fig.8

Week 13

That week has been spent to publish the game different ways(shockwave, projector) for different computers.




If some of us have questions, comments or feedback, feel free to ask the free and open source of that game.
Alexandre Garacotche January 2001 for Thames Valley University London
Game Play Design Hedley Roberts.
http://www.idoia.com
info@idoia.com