About 3 weeks ago now my teams game, Gnome Depot, was one of the three games that was able to go forward after Greenlight in my section of the class. Since the initial idea of the game was mine it is very fulfilling to see it go so far for being such a silly concept. The entire Greenlight process was stressful but after making it through and having more people to help with making it, it has been nice. While my specific role of programmer did not get anyone new, I feel the team overall has benefited from having extra help in their disciplines. One thing that is a problem with getting more members is getting them all up to speed and making sure everyone contributes equally, and that people have clearly defined areas that they work in. Even though there are three designers on the team, since they are in different roles, one focusing on QA, one focuses on level design, and the other does whatever else, they are all able to do relatively equal amounts of work.
What a level looks like right now
Overall the game is advancing at a steady pace. There is a clearly defined level, most mechanics are fully implemented now, and most of the time going forward will be spent on iterating movement to make it feel as good as possible, since it is easily the most important part to get right with the game.
Personally speaking however, nothing has changed since the beginning, as the team has always had 2 programmers, and our roles have not changed over the course of the project and it will probably not change in the future
I think the strongest prototyping week I have had in Production II has to have been the first week of prototyping for our green-light game. The reason I think this is because we essentially came up with 2 games in a week, and were able to ditch the initially more risky game we came up with at the beginning of the week and switch to the more solid and doable concept that we have now, Gnome Depot. The initial concept we had in mind was going to be a game where the main mechanic was skating on ice and when you would be able to fish up things underneath it by drawing a shape over it. If you have ever played the Mario Party 3 mini game Etch ‘n’ Catch, it was going to be relatively similar to that. At the time we spent a lot of time thinking of unique things to enhance the game and try to come up with a setting that made sense.
Etch ‘n’ Catch from Mario Party 3, you and your teammate were trying to enclose the toad that was moving on the page to get a point
After about 2-3 days, we realized the challenge technically that came with being able to accomplish what we wanted the game play to be like and felt that it would be too difficult to implement in time for a presentation. This lead our team to hold an emergency meeting to try and either figure out a way to accomplish it in time, or to just go forward with a completely new concept. Thinking about it more, we eventually ended up scrapping our original game idea and coming up with a completely new one which we have come to love much more.
Our beloved Gnome Depot
I feel like I had a pretty big role in this change, since I made sure to do preliminary research into our first concept to check possible ways to achieve what we wanted. Additionally, the concept for Gnome Depot mostly came from my mind, and I was able to come up with the general game play loop of what it would be relatively quickly during the emergency meeting, which was the main catalyst I feel for us going forward with it. I do not know where my sudden passion for this concept came from, but it has lead me to take a secondary design role and I think the team is overall much more excited about it than our initial concept.
One thing I will definitely remember from this process is that doing research as soon as possible is very important, and being able to see potential problems of a concept and communicating that with the rest of the team is essential.
Back when I decided that I wanted to be part of game development near the end of high school, I knew basically nothing about the process behind making games and only knew about the finished products that I played every day.
Through pursuing a game programming major at Champlain College, I have learned many things about game development as a whole. In my classes here I have made numerous little demo games both individually and as part of a team consisting of artists, producers, and designers.
From back in high school up to now in my third year in college, my virtually non-existent skills and experience in game developing and programming now exist and I feel much more comfortable with the process. I now know a lot more about game engines like Unity, and also have managed to become more creative with thinking of game ideas. Through the production classes I also have become much more comfortable being part of a team than when I first started out. I have gone from knowing absolutely nothing and I have been able to now create games with teams that I am proud of.
One such game is a dungeon exploration game called Dungeon NFC, where the game could be played through a USB NFC reader and custom NFC cards
Starting Screen of a dungeon room
Result of using the lockpick card on the room
Screenshots from a dungeon room in Dungeon NFC
Going forward, I hope to learn more about how to accomplish interesting game mechanics and features and to branch out and learn how to create games in other engines like Unreal and not just Unity.
This post is dedicated to explaining the AI technique of formations and in with it the idea of coordinated movement
Formations are useful for basically any genre of game: RTS, RPG, sports games, basically anything you can think of. If you want units to move as a squad in any sort of way in your game, formations are a great and easy way to achieve this. I implemented a pretty basic form of it in a Unity3D project and will show various snippets of it in this post for help with implementation
Basic Concept
A formation consists of a leader slot, and however many other slots are needed to create the desired formation. For the most basic implementation, the leader of the formation is the only thing that is controlled, if movement is involved, and every other slot of the formation is based on the leader. Any steering or obstacle avoidance is only handled by the leader, which means that it has to account for the entire formation when trying to avoid obstacles, making it only really useful for an outside environment with minimal obstacles.
Examples of various four-unit formations(Artificial Intelligence for Games, Ian Millington)
Two-Level Formation Steering
As mentioned, the most basic implementation is only really useful for wide areas and not for indoor environments. To help solve this issue, you can implement something called two-level formation steering. There will now be two levels of steering, one level being used by the leader to move around formation slots, and the other level being the individual units steering to those slots themselves. By making every unit in the formation have its own steering and avoidance, the leader won’t have to account for the collision and avoidance of the formation as a whole anymore. The role of the leader is now solely to just keep updating the formation slot positions/orientations as it moves.
Representation of how units will avoid obstacles themselves (Artificial Intelligence for Games, Ian Millington)
Since each unit now has its own avoidance and steering, if the leader has avoidance related to it as well, then anytime it avoids an object, it will end up skewing every other unit in the formation at the same time. To prevent this, the leader is made invisible and its collision and avoidance is removed. This way the leader can help keep the formation in the correct spots without having to worry about avoiding objects itself and messing up the formation.
Shows the invisible leader in green
Implementation
Implementing formations is actually quite simple if you don’t implement some more advanced methods that I will mention a little later. A two-level formation is the most effective way to implement it I feel and it is also relatively easy with an engine like Unity that has built in path finding and obstacle avoidance. To start out, you need to create a basic formation, which will just be an array of positions that formation units will be placed at relative to the leader position. In my implementation, I created two different formations of four units that you could switch back and forth from, one being a cross shape, and one being a line.
Setting up the positions of the formation slots
I also created a separate array of the same size as the formation that is used to hold the units that will be in the formation. When the leader who holds this formation script is moved, it will be updating its own position and be sending to the units within the formation their updated destinations. Since the formation slots are all relative to the leader, finding where each unit in the formation needs to go is as simple as adding the slot position to the leader position.
Updating destinations of the units in the formation
Since this is a two-level formation steering, the units of the formation each have their own steering and avoidance, which in Unity, will be a navmesh agent. All that has to be done in this case for the technique to function correctly, is to set each units navmesh destination to be its position in the formation. This way if any obstacles are in the way, Unity is automatically avoiding them on its way to the formation slot.
Function within the formation units that sets its path finding to go for its formation slot
Optimizations
What I implemented is about as simple as it can get for an effective formation that can fulfill any basic need you would need for a formation, but with some more advanced techniques it could be a little more effective. There two main issues that my simple implementation comes across, the formation can get ahead of an member that is busy avoiding obstacles, and when switching positions the units can get a little jumbled on their way to their positions.
One unit is lagging behind the formation(can also see average position of all units with axis)
To fix the issue of a lagging unit, there are a couple solutions. The most simple way is to just reduce the max speed of the leader to be around half that of the units, to make it harder for the formation to get too far ahead. This however constantly slows the formation even if there is not that high a chance for the formation to ever be behind. A better way of solving this is by keeping the leader on a sort of leech, making its position be based on the average position of the units, so if one unit is far behind, then the whole formation will be held back to allow it to keep up. Resolving it is a little more complicated than just setting a position, but if you want to learn a little more I recommend looking at around pages 149-151 of Artificial Intelligence for Games(Second Edition) for more.
Units getting clumped changing from the cross formation to the line formation
The problem I mentioned of units getting clumped up when switching between positions is created because each unit has a set index in both the formation unit array and formation slot array. To prevent this jumbling as much as possible it is recommended to make each unit go to the slot that is closest to its position before the switch. This way both the time to get into the formation will be shorter, and the units will be less likely to interfere with each other.
Closing Thoughts
Formations are a very useful technique that can be used in just about any game out there, so I hope I was able to show a lot about it and give some insight on how to implement it :]
Stephen Hill's Portfolio Site 