Prologue to first steps with Swift

MrJre Leave a comment

It has already been like 6 months since I announced I would make a fresh start given I would have to make some time for it. Lets do it!

Swift 2.1 got introduced a week or two ago, and the time comes closer that we are going to drop Objective-C in favour of it. You might wonder why the heck after a year of Swift we are still using Objective-C, but the answer is quite simple. Given that we have a large user base, we still provide extensive support for iOS 7 on all of our apps. They share a large code base in multiple static libraries. As you might know, you can’t really pack swift code in static libraries, and dynamic frameworks only came available in iOS 8 (There is of course the CocoaPods workaround, but we’ve decided against using it). We couldn’t therefore afford to abandon Objective-C just yet. As iOS 9 adoption rate grows and that of iOS 7 dwindles though, the time draws closer to finally drop iOS 7 support and leap into the future.

So here we are. Lets start with Swift!

Before we start, we are going to have to think up a project. Most people would probably make some kind of example app, but not me. I’ve been reading The Clean Coder (I’ll do a post on some nice new books i’ve read soon) by Uncle Bob Martin a while ago, and he proposed to do coding katas on a regular basis to hone your programming skills. The idea is presumably first coined by one of the writers of another quite famous book, The Pragmatic Programmer. There are a few websites that collect katas, and there are those that go a step further and build a whole suite around them. One I have to mention is Code Wars, which has literally dozens and dozens, provides a ranking and honour system, and allows you to take it up against others as well in the process.

For now, we’ll do with picking one from Coding Dojo and start with the Poker Hands Kata. In the next post we’ll start coding.

Hiatus and Future

MrJre Leave a comment

Im aware I’ve left this blog bare for the previous few years. I’ve decided it is high time to do something with it again.

I’ve been working in the mobile industry for the past few years, so I have some new ideas for topics regarding iOS development mainly, and Android development secondly. Next, we are currently deploying scrum in our organisation, so i’ll give some insights in how that works. Furthermore I’ve been exploring some new hobbies, so expect some posts on board games, running, cycling and hiking.

Enough to talk about, now lets find the time to write it down as well ;)

/MrJre out

Global Game Jam – Tips from the trenches

MrJre 1 Comment

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 ;)

On waypoint graphs

MrJre Leave a comment

As promised, a first post on path finding solutions for games. The first structure I’m going to treat are so called waypoint graphs, and are still commonly used in games regardless of their downsides, mainly because of their simplicity.

A waypoint graph is actually a very simple concept; positions in the free space (so, the area that a character is supposed to be walking on) are sampled either by hand or by algorithm, and n‑nearest neighbor points are connected to the newly sampled point by an edge if no obstacles are detected between the two points. It is one of the most classical solutions used in games, and is still being used by games today. Short paths are found by applying A* on the graph. Start and goal configurations would be added to the graph as temporal waypoints and characters would move from waypoint to waypoint until the goal is reached.The problem with this is method of course is that it doesn’t give any idea on the boundaries of the free space, so the coverage cannot be optimal by definition and is dependent on how many waypoints are used. In other words, characters are stuck to using waypoint routes, and deviating from the path isn’t really possible unless you perform a collision test on the intermediate path to check if it doesn’t hit any obstacles. On of the games that recently came out still uses this technique; Alien Swarm by Valve. 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.

Next time more on waypoint graphs ;-)

By the way, Alien Swarm is freely available on Steam.

Some nice new videos on Path Planning

MrJre Leave a comment

So, recently there have been a couple of new videos that illustrate ‘new’ techniques in path planning and especially crowd simulation for games. The first is on so called flow fields in supreme commander. Although it is a really nice new way of doing things, especially in the example where large units move to a group of smaller ones the behavior to my opinion is still unnatural as small units literally get pushed out of the way:

And the second is on path planning in the upcoming Starcraft 2; I don’t really know much about the techniques used here, but it looks as if they combine local force methods with A*. It looks cool but again the behavior of the zerglings sometimes is a bit unnatural still, some odd patterns can be seen when the units are packed together: