So last week I’ve been participating in this years global game jam with theme ‘extinction’. The location here in the Netherlands being the HKU in Hilversum, having over 140 participants in total. I was invited by the people of Digital Dreams Games since they needed a second programmer on the team. The game we created is called FYI (see here and here for downloads and more info), and is a platformer puzzler game based around the concept of infographics. Every action you do in the game affects the platform elements in the game (bar graphs, circle graphs etc), so the trick is to do all the correct actions such that all the elements are in their right state (with bar graphs its having them at correct heights for example) to finish a level.
During the 48 hours we made the game, we did some things right and we did some things that we could have done better in retrospect, so I decided on a quick writeup for some obvious tips.
- Throw away your first three designs. This is one tip that the organization proposed as well and i think that really worked out well for us. The idea is that the first three ideas you are going to have, are also the ideas that other people are going to have and are therefore not original enough to be used.
- Make sure you have a good source control system in place. Source control can benefit greatly to the production efficiency, so be sure to use it. We used dropbox as our tool, which was not the best choice to make as it has no version history and no merging capabilities. This arguably cost us a considerable amount of time, since effectively we couldn’t work in the same files at the same time, and face overwrites of files on previously made changes.
- Have a good assets pipeline. If you start on building a game, make sure that when you have finalized assets that they can be placed into the game immediately without intervention of other people. This means first of all that the team has to decide what kind of assets are needed and in what format, size and orientation they will have to be. Take empty space into account when you are using sprites; as an artist think what the asset is supposed to be doing. The programmer needs to have the piece of code to use that asset into place using placeholder graphics such that the only thing that has to be done is replace the assets when they are ready, which the artist should be able to do just by overwriting the placeholder. The next thing to do is have all variables in a separate class such that they can be adjusted easily also by a game designer. Make sure you don’t hard-code levels into your game for the same reason.
- Don’t manically code stuff together with all kinds of pieces from earlier projects because of the time constraints. Honestly, piecing together sections of code from other games is just as fast as coding from scratch, but causes the game code to be chaotic, bloated and incomprehensible quite fast. Try to setup your code base similar to how you would normally do, add structure and try to keep everything as tidy as possible without spending a lot of time on it. If you want to use previously written code, set it up in such a way that it can be easily integrated for example by making it a library.
- Have a clear idea on what needs to be done. It is really an obvious tip, but in the hectic hours of the jam this is easily neglected. Have a board up with post-its, a site to track those things or something similar. It will ease communications and have a positive effect on production efficiency as you can easily prioritize TODO features, see who’s working on what and so on. Also don’t have long arguments on how things should be looking, and don’t spend a lot of time on changing things that had been finalized unless it is absolutely necessary.
- Get sleep and eat healthy. Even if its only 48 hours, even having four or five hours of sleep a night will help you to see things clearer, and makes you work more effectively then when not sleeping at all. It was really a disappointment to see the organization serve french fries and other fried junkfood the first day as if it is inherent to the whole thing. Eating fruit and veggies and drinking fruit juice are a better option always ;)
- Utilize the knowledge available in other teams. It may sound a bit odd, but ask other teams in the event for quick advice when you’re stuck on a problem as it can save you precious time.
I’m sure there are plenty more tips to go around, but these are the most obvious ones in my opinion ;) All-in-all it was a really cool experience to participate in the global game jam, i really encourage people both veterans, starters and students to participate and make cool games together. The organization did well, and breakfast and lunch at least were up to spec ;)
In Alien Swarm there are many waypoints, and they are all connected with a lot of neighboring points. Collision detection is used to check if a path is actually valid and disabled if not (see screenshots). The main reason this is done is because the environment can be dynamic. For the paths in a limited area where the environment is dynamic and changing, new paths are added if they are free from collisions with the changed environment.
Waypoint graphs can also be extended to include a radius. These kind of graphs are sometimes referred to as circle-based waypoint graphs. The idea is that characters may only traverse from waypoint to waypoint if their circles are intersecting. The improvement over a simple waypoint graph is that a circle-based waypoint graph approximates the free space. The problem is that when waypoints are placed in arbitrary locations, the approximation of the free space may still be fairly inaccurate, which means that characters still can’t reach locations that are visibly reachable. Also, the denser the environment is, the more waypoints you will need generally because the circles of the waypoints are smaller. By placing the waypoints along the medial axis of the environment (the axis on which the distance to two different obstacles is equal) you can insure connectivity.
