3D Text/Collisions CREATING THESE EFFECTS IN ALICE 3.1
3D Text Over the past two weeks we have looked at creating 3D Text. Remember that when we create 3D Text we need to follow a few simple steps: 1. Open “Setup Scene” 2. Navigate to Shapes/Text 3. Click on the folder new TextModel() – this means we are creating a new object of the TextModel class. Clicking this it will create a window for our Text Model. Of these we need to pay attention to the initial property values: paint, opacity, and value. Paint – our default color is white, if you would like to change this initially this is where to do so. Opacity – this is how much our color is “filled” in on our object. We need this to be at 1.0 for it to show up fully on screen, default this is always 1.0 Value – this is the string literal value that our 3D text should hold, default this reads “hello”, but we may change this to anything we would like to change it to.
“Animating” 3D Text In many games text always appears on the screen to animate it in a sense that the text is a part of the world. However, this text traditionally does not remain. We will follow this trend by coding the text to appear, disappear, alter the statement/reappear, then fade away again. Remember though!: This object was not deleted by making it fade. So as such we should remember that we do not want to apply this amongst the items included in our SetB array for collisions. To set up the code for this simply follow the example I will provide on the next slide -> -> ->
Take a second look… Remember we did a few things of importance here: We created some global variables for our strings, not just typing them into the value fields. We set an intro timer for the opacity, and set the opacity to 0.0 to make it “disappear” We performed the fade in, change in message, and change of color (paint) in a doTogether() Finally, we used the setOpacity() procedure outside of our doTogether() in order to set the opcaicty back to 0.0. This is mainly to avoid the issue of text turning “on” then immediately “off”
Collision Collisions are important to games. This is what gives us an example of reality to draw from. All things in our realm/dimension have innate properties that allow for collisions to occur. We are going to do the same thing within our game now so that our world has some physical properties applied to it. To do this we are going to utilize a new listener that is found on the main initializeEventListeners page. Following these simple steps will allow us to make sure that we are setting up accurate collisions for our game world…
A deeper look… Looking deeper at the bottom of this page we see that I have added an EventListener. This can be done by clicking “Add Event Listener” drop down menu Navigate to the bottom for Position / Orientation, then navigate back to the top of the next menu for addCollisionStartListener This is where we will utilize our two arrays SetA and SetB For SetA we need to only add one object: Our player’s avatar, or in other words the character we are playing as. In SetB we need to add all objects to the array that we plan to collide with. Remember arrays are 0 (zero) based in value. So our first object/element of the array is labeled with a 0, like this: [0] treeTrunk
We are not finished though… Our new event listener wants code too. Like all the other event listeners on the initializeEventListeners tab there is code required if we want any actions to take place when collisions occur. I have added a line that will make my players avatar (the character my player will play as) bounce backwards in direction by 2.0 meters. This will help simulate some physical reaction of a force meeting a greater force. Remember: We are working with box collisions in Alice 3.1 so that means if you plan to fly collisions on objects will still happen based upon the box collider surrounding the object. So if at any time you collide with “air” or “open air” you are colliding with the box.
Preparing for next week… Next week we are going to delve deeper into creating our own procedures or methods. Games do not consist of one method and if they do, they are poorly designed. We are going to look at migrating our code for specific tasks into their own methods and then setting up our game to look more modularized. For your homework this week make sure you have added 3D text to the game, have it animated in some fashion and make sure collisions are set up. We will also be discussing camera orientation and position next week as it pertains to the player in the game. Have a great week and I will see you all on Sunday!