Here’s a download link for the project for today’s session. Created in Unity 5.6.0f3.
Here’s a download link for the project for today’s session. Created in Unity 5.6.0f3.
We were fortunate to be visited on 8 April 2017 by Ciara and Connor, two engineering students from NUI Galway who are part of the Geec team, building the Galway Energy Efficient Car – this is an electric car that a group of students have built from scratch, that is capable driving very long distances. For example, they estimate that it could cover the distance from Galway to Dublin for 14 cents worth of electricity!
Ciara and Connor both explained their roles in the project and answered many questions from enthusiastic members of CoderDojo Athenry. The CoderDOjo members found the Geec and its underlying technologies very interesting. It was fascinating to see that skills that many of them are learning (such as Arduino programming, soldering, and App Inventor) can be put to such great use.
A team, a project and a car. The Galway energy-efficient car (better known as the Geec) is an eco-car designed and built by engineering students from NUI Galway. In May 2015, we competed with 196 other teams at Shell Eco-marathon Europe, where every car was challenged to drive 16 km on a closed street circuit in Rotterdam using the least amount of fuel or energy. The Geec represented Ireland’s first ever attempt in this definitive global ultra-efficiency event. We finished in the top half of the leaderboard in prototype battery-electric class, with a score of 287 km/kWh – roughly equivalent to 8,000 miles per gallon for a petrol or diesel car.
The talk covered the basics of how the car has been designed, built and tested, with the main focus on the electronics and software involved in the car.
Ciara is a final year Electronic and Computing Engineering student in NUIG. Her role on the Geec team is to implement the Data Acquisition and Display system. The system collects data from sensors on the car and then has to accurately display them in real-time to the driver. All the data is used to write out driving strategies for the marathon. It entails designing, testing and building a circuit with various sensors, an Android app to display the data to the driver and a logging system to save the data for further analysis.
Connor is a final year student studying Electrical and Electronic Engineering in NUIG. His role on the GEEC team is designing the power electronics system, which delivers power from the battery to the motor. This involves both software and hardware, with an Arduino being used as the interface between the electrical and virtual sides of the system.
The last two weeks we were looking at something quite different: a text-based adventure system built in Unity. This was inspired by the Henry Stickmin games and also by the old 80s-style choose-your-own-adventure books.
Basic Program Design (Story Card)
The user is presented with a “story card”. A card consists of some text describing their current situation and (normally) a number of options to choose from.
Depending on which option they pick, the story branches from there, card-by-card, until it reaches an end (a card with no options).
Setting up a card is straightforward:
You enter the card description (the text the user sees on screen), the text that the user will see on each option button (the program supports up to four at the moment) and the card (or branch, but we’ll get to that later) to jump to when that option is selected.
There’s also the mention of “States to Set True/False” and we’ll explain that next.
Story States & Story Branches
We could have programmed the system entirely using only cards, but there’s one situation where this becomes tedious. Imagine that you have a choice; hitting a button for example. The consequences of this choice won’t become apparent until later in the story. If we only had story cards, then we’d have to branch the story immediately at his point, replicating the same steps on both branches until the point at which the consequences of your action played out.
Fortunately, there is a better way.
First, to remember the value we introduce the idea of a “story state’. It’s just a container for a true or false value. Cards can set the value of specific states when they are activated as seen above.
So, that covers remembering values, how do we then make use of them? This requires a “story branch”. A branch references a state and two places for the story to go (either of these can be a card or another branch). The value of the state determines which is picked.
This class looks after the story. It is responsible for updating the UI to the details of the current card, for handling the use clicking on specific buttons and generally directing the flow of the story. It also needs a StoryCard to start off the story with.
The project, including a very simple story using a number of cards and also a couple of states, can be found here. There are two scenes in the project, Adventure which contain a simple story and Basic which is a good starting place for your own story.
To help you along here is a little cheat sheet! cheatsheet.pdf
This week we looked at a version of the classic game Breakout. It was an exercise in showing how a game developed with 3D assets can, nevertheless, appear like a 2D game given the correct choice of camera and lighting.
The camera for this game is an orthogonal one. Unlike a standard perspective camera, which mimics how we actually see the world, things don’t get smaller as they get further away with an orthogonal camera. This gives a very flat look where we don’t see the edges of the game area, blocks, bat or puck. In addition, the scene has a single directional light which shines directly downwards. Shining straight down means there are no shadows around the sides of the objects as there would be if the light was at an angle.
This game does not use Unity’s physics for the puck movement. I found that the physics just didn’t give the consistent behaviour you’d expect from this game. Accordingly, I programmed the movement of the puck myself. The maths is a little more complex than I’d like but the intention is to keep the puck moving at a constant speed, even after it hits something.
Additionally, we worked quickly on implementing a mouse controlled camera. In the hierarchy, we created a camera rig from two empty objects, one inside the other, and put the camera object inside the second. Changing the Y rotation of the first empty then turned the camera around the vertical while changing the X rotation of the second tilted the camera around horizontal. The visual below show what a real world camera rig that behaved this way might look like; rotating at the base and at a horizontal pivot.
In our scripts we referenced the usual horizontal and vertical input axes:
float horiz = Input.GetAxis ("Horizontal"); float vertical = Input.GetAxis ("Vertical");
but in the Input Manager (Edit|Project Settings|Input) we switched these from the arrow keys to the mouse axes:
The Breakout project can be downloaded here and the mouse controlled camera project can be downloaded here. These projects are both saved with Unity 5.5.2f1, so please use that version or later when opening them.
Thank you all for coming Saturday on such a nice day!
We continued our Mario game from the previous week, where we used the scrolling of objects in the background to achieve movement rather than making Mario move.
Notes from this week are here: CDA-S6-Week-5-17-StoryTelling_etc.pdf
This week we spoke about possible projects. We also looked at games that you like so that we could draw inspiration from them.
When it comes to projects, there are a few questions you need to ask yourself:
What is the type of game you want to make?
Take a look here for an exhaustive list of game genres: https://en.wikipedia.org/wiki/List_of_video_game_genres
What is the setting for your game? Do you have a character in mind?
These choices will determine the look and tone of your game and are good things to decide early on.
What do I already know that will help create my game?
From what we’ve seen already this year, what things will your game need that you already know how to do?
What do I not yet know how to do?
There are things you might like to be able to do that you’re not sure about how to achieve; these are things to raise with your mentor. He’ll focus on these in the next few weeks. Also; check the Asset Store. There are many free things there that might help you complete your game. If you’d ultimately like to do everything yourself, look at these as items as placeholders to get the basic game working that you might eventually replace.
You will find it hard to get time to work on your project and it’s your first project on your own in most cases. The most important things are to show something that is yours and something that is fun. Showing something that is overly complex but that is not fun is not as good.
Get your thinking caps on!
Apologies for the late post. This week we looked at simple AI navigation.
The basis of navigation in Unity is the NavMesh. A NavMesh is a simplified view of the game world that marks out all the areas that AI characters can move through. The pictures below show the same scene with the NavMesh made visible in the second:
The blue areas are the NavMesh and are the areas that AI characters can move in. The holes made by the walls are apparent as is the “ramp” on the steps and the circle/arrow combinations where characters can jump down from or across obstacles.
Making a NavMesh
The first step in making a NavMesh is marking pieces of the scene as “walkable” and “not walkable”. Open the Navigation panel from the Window menu. When ever this panel is selected, the NavMesh will be displayed in the Scene View, by default.
The Navigation panel has three buttons across the top. Select “Object” and select objects in the Hierarchy that you want to be part of the NavMesh. Select the floor or ground object, select the “Navigation Static” option and set “Navigation Area” to “Walkable”:
Then select each wall/obstacle and again select “Navigation Static” but this time set “Navigation Area” to “Not Walkable”.
Press the “Bake” button in the bottom of the panel to create the NavMesh.
Adding a Character
We use the AIThirdPersonController prefab from the Unity Standard Assets to test our NavMesh. Adding it to our scene, we find that it has a “AI Character Control” script that takes a “Target” parameter.
Just drag any game object (even an empty one) from the Hierarchy here to tell the character to move to it.
The sample project can be found here. This is in Unity 5.5, so ensure you’ve upgraded to this version before trying to open it. The sample project also contains some logic to reroute the character between an array of targets, alternating when the spacebar is pressed. It also has had some “Off Mesh Links” generated. These allow the character to drop from the elevated platform and to “jump” (more accurately float really with this character) between them.
In the CoderDojo Hackers Group these days, everybody is working on their own projects in groups, such as building computers, designing robots, and carrying out all sorts of top-secret plans!
Here are couple of photos from 11 Feb:
Thank you all for coming yesterday on such a lovely day.
This week we did a simple Piano.
We only had to draw two keys, and then could duplicate these and change the names. The same applied to the code. The code is the same for each key apart from one small change so the note is the appropriate for the key.
REMEMBER! You need to make four changes each time you duplicate:
Change the name of the spite to the next Note
Change the name of the TWO costumes
Change the NOTE played
Remember, no sessions for the next two weeks. Have a nice break and for anyone with confirmations to attend next week I hope the weather is extra nice for you.
See you back on the 4th of March
Here are notes from this week in PDF cda-s6-week-4-17-piano.pdf