Scarba camping adventure!

This weekend just gone (Nov 5th), me and my fellow colleagues and friends went on a 4 day camping trip to Scarba; a diddy little island in Argyll and Bute. Here's a summary of the long weekend.

The total trip was from four days, Thursday to Sunday; but it lasted a little longer than that, I'll tell you why later.

I went with 4 others, 3 of which were from SCE and 1 was a friend of a SCEite.

The trip started as I got picked up by David, who very very kindly offered to drive me and Nick. The others were making their own way there. The drive time was about 9 hours and he did the whole lot, there and back, more or less in one go. Bravo to him. We hastily got all our things together, then we started the epic drive which took us through Birmingham, between Manchester and Liverpool, through Preston, Lancaster, Kendal, Carlisle then Glasgow. We stopped at one or two services for a break and a few supplies. The next part of the route took us through Argyll and a variety of beautiful Lochs through Inveraray. This was the time it got to be a real site, even though it was dark. It was great to see the lights of houses and cars reflected in the water. We even stopped a few times to take a look. I think we were also testing out the temperature :)

The dock where we were going to take the boat trip to Scarba was in a place called Ardfern. Which is a little village on the edge of the sea. We three took a look around Ardfern and decided to check out a place a local map said had a castle ruin. We didn't find too much of a ruin but we did find a dock or bridge of sorts and some old ruined buildings which did have an element of eeriness in the dark. We also found a fire still alight, where presumably some of the locals had lit a fire and shot some fireworks. We soon met up with the other two and decided to set-up camp for the night. Surprisingly this was the only time we used our tents.

In the morning we took the boat trip from the dock. The trip took about an hour and half apparently, but it seemed much shorter than that. We saw that the sea was quite active as there was a fairly strong wind, the boatmen said there was a gale warning as we neared the island. At this point the wind picked up. In fact they had some problems docking with the wind, a few of us had to get out and help secure the boat to the moorings after a few attempts at getting close to the rock. They advised we head for the bothy on the other side of the island. When we got our things off, that's exactly what we did.

The trip to the Bothy was, to be honest, long and hard with all of our supplies and kit. I for one struggled in the rain and the wind. This was of the more gruelling times we faced, and not the first time my fitness challenged me.

After some time, we made it to the Bothy, thanks to Rich's mostly faultless map reading skills. What we found when we got there surprised all of us. We all expected a bunch of stones loosely resembling a small house. What we found was a great little home on the top of a beach facing the sea. It had a bunch of rooms with tables and chairs, some supplies others had left, even some camp beds. It was in great condition. We started a fire and got settled in. We later cracked out a some fireworks and some sparklers :)

The next day we did some good exploring, following the rocky beach and cost around, finding some interesting geography, like caves, streams and pools. Lots of the caves showed fairly recent activity by other people, which I was a little surprised about. We also saw some great wildlife. Scarba has quite a large deer population and it was great to see them running around in herds, poking around on hills and steering clear of us as we potted around the coast. One of the coolest things to see was the various birds, particularly the birds of prey. We saw a few different birds, a few riding the currents staying motionless in the air looking for prey. The best by far for me was a pair of huge eagles, which I'm guessing were Golden Eagles or Sea Eagles. It was great to see these majestically swoop up past, along a small cliff-face next to us.

Next we made our way to the summit of Scarba, which I believe is around 450 metres high. Passing on the way a lake in the hills. Not all of us quite made it to the summit though. By the time we got near the summit it was getting dark, which was the disadvantages of going in the winter, with its short days. Although there is a fairly trodden path, it was made a bit more difficult to walk in the dark, especially as it was so wet and muddy.

That night we decided to stay in one of the caves we saw earlier, as it seemed perfect for it; and something to write home about. I was initially hesitant after the exhausting trek of the day, but after some food and a rest I was excited about the prospect. We collected all of the kit we needed and made a way around the coast from the Bothy. This was the route we took earlier in the daylight. Next to the cave was the perfect site for a fire. We got a great fire going and got stuck in to some of the beers and whisky we had. This was the highlight of the trip; nothing beats the warmth and atmosphere of a natural outdoor fire (alongside a touch of amazing whisky). The cave was actually very warm and we all slept fairly well and comfortably. Sleeping caves are something I highly recommend!

The next morning we woke early so we would catch the boat, sort our kit out and clean the bothy, so it would be as close as we could to the great condition we found it in. The sight of the sun over the water in the morning light was something to behold as I crawled out of the cave mouth. Unfortunately I missed the sun-rise, being one of the later of us to wake up.

That day we reached the dock for our boat trip home. We were there in plenty of time which was a relief. The boatmen soon told us that a fishing boat had called for assistance though. They gave us the choice of whether to go back to the dock in Ardfern (as we had hired their time for that) or help them and the boat in trouble by allowing them to reach them quicker. We couldn't refuse, partly to help the fishing boat and partly because of the adventure. The boatmen estimated 3 or 4 hours based on the fishing boatmen's description of their distance out at sea. This turned out to be a much longer and chillier affair. From jumping on the boat at around 12.15pm, we weren't in Ardfern until around 19.30pm, by then it was well into darkness. It wasn't all bad though, it was cool to see the fisherman's boat being tugged into the next village along the coast.

A few remarks on the trip:

I was surprised and pleased to see how well people had provided for others who would follow in their footsteps. We found useful things in the bothy, everything in good or reasonable condition, and plenty of fire wood.

The boatmen were great guys, they gave us a few coffees and chatted to us during the trip and the rescue.

It's best to go in the longer days where you have more daylight with which to do things.

Overall though, it was a great time, with lots of great sights and hijinks - and also a few challenges, but ones that made the trip all the more satisfying.

Floating point precision ... I didn't think it worked like this

I thought floating point numbers were more accurate than this:

-0.48f + 0.02f = -0.46f .. right?

Nope. The answer is -0.459999979

Just some background. 0.2f is my drag factor to apply to the character's velocity, ie. gravity. The background/level is a set of horizontal strips. These are scrolled to the characters velocity each frame.

Reading around, ie. the result above should be precise to 6 decimal points. As I understand it, after 6 decimal points accuracy isn't precise.

This really screwed things up when scrolling the background, as the errors seemed to accumulate and I'd see seams. What I've got in place at the minute is to round to two decimal places, which gives me enough accuracy. Two other options are to use doubles or fixed point numbers (ie. ints).

If anyone's got a better idea. Let me know!

Glad I found a solution though, this has been bugging me for ages - this must trip a lot of people up if they have any type of sub-pixel scrolling.

Future

Me and Gaz had the opportunity to do a Show n' Tell with the XNA UK User Group alongside Beatnik Games and their project, Plain Sight. It was really great to meet the Beatnik guys, play their project and see a few more peeps play Sumo Squash. I had fun playing Plain Sight, I thought it had some great ideas and shows a lot of promise. Having since seing Plain Sight at the Eurogamer Expo, Alex at Beatnik Games told me that they had be beavering away for the Expo based on some of the feedback they recieved at the Show n' Tell, and I like where its headed!

The Show n' Tell also gave us a chance to get some feedback for our game, as small and simple it is compared to Plain Sight. When we show our game, people always seem to have a good time playing it, and this time it was no exception. After some drinks and chat with the people at the Show n' Tell, we decided that we should spend some time polishing and adding features that we had liked to put in, with the added possibility of submitting it to Community Games in a couple of months.

Whilst doing this, we are also thinking of other game ideas for future projects, using Sumo Squash as a stepping stone to them. For the next projects we plan to start making prototypes/ white box testing for game mechanics, so we know they work before developing a full game, and to refine mechanics that we can draw upon later.

Next up on the grand agenda are plans to improve the tools that we are using at the moment. First off, as mentioned in other posts, the LevelEditor only contains the barebones, I plan to spend some time refactoring and adding features. The idea is to make everyone's life easier and take some of the work from me, as it is all to easy for me to become a bottleneck. -So there plans to create tools, or make the Level editor support the visual creation of animations and menu UI's.

Sumo Squash Development

I thought I'd take the opportunity to talk a little about the development of Sumo Squash for DBP for anyone who may be interested.

Even though the game output hadn't got anywhere practical after Herriman: Under Pressure, I started developing a 2D framework sometime after, with one of my friends and colleagues. This involved a data-driven architecture, that was designed to provide a standardised interface for Sprite Management, Animation, setting values, Resource Management, Input Management, Level Management. After we created a stable version, I also started on a very early version of a compatible Level Editor.

Anyway ... back to Sumo Squash. So we started on getting a basic character up and running. As I remember I started off with some basic programmer art of some blocks for the level and a block for the character, with this I got the basic collision response of a platformer. Gaz later animated an early version of the Sumo and this spurred me on to better refine the control and collision response. These were suprisingly difficult to get right, this was the first platformer I had done - they were later refined even more as the feel came along for the game. At this early stage, Gaz and me debated the layout of the levels and started with the idea of a retro feel for the game and some corresponding levels. We liked the idea of block based levels, where the 'state' of the blocks could change. Gaz liked the idea of having 'procedural' levels that were created randomly within some parameters; where the position, state (such as Ice, friction) would change, and we also thought about some blocks that could have different stages of breakability. After some thought, we realised that there must be some rules to constrain the random blocks, but I couldn't foresee a simple way to do this. After some more work to polish this build/prototype of the game, as well as after the development of an early level editor (that could basically just place objects) we showed this to our good friend an trusted artiste, David Faulkner. He was luckily, up for collaborating on the project!

It was around this time, we were reading about the development and playing Braid, and as you may see this influenced the level design for the game, it also inspired us in the way to do the collision (ie. for slopes) and how to integrate it into the editor. Dave started coming up with amazing design for level objects and backgrounds. Seeing Braid (gamasutra article by David Hellman, artist for Braid) and Dave's designs made us, thankfully re-think the block idea.

It was shortly before this that the Dream Build Play competition reared its head and made us notice. We have to confess, we first entered to get the free creators club memership (we'd always planned to develop something with the Xbox 360 in mind), but we thought what the hell, lets step development up a gear and try get something playale for the competition. Although we were about 2-3 months away from the deadline, we thought we could get something up and running that was at least half fun.


For the next few months, we put our all into the project. I kept improving the editor so it was more useful, collision could be added and modified and the way it was displayed was more helpful. I added a delete and clone option and removed some annoying bugs (development of the tool was far from ideal and it was never more than the bare essentials to help the game). Me and Gaz worked after work hours when we had the energy and all weekend when we could. Dave built many levels on Snow and a more seasonal theme. Gaz designed and went through a few iterations of the UI, including the menus and the in-game display.

As all the team are distributed around the country we took advantage of Subversion (Tortoise SVN), google docs and lots of e-mail. I only had the idea or inclination to set-up SVN access midway into the project as we needed to synchronize and exchange our work more and more. I took the decision to make access read-only to simplify matters; this was the way Dave and Gaz updated their local build. Access to SVN was made available through VPN and Hamachi. It soon becomes apparent that when working over the internet that the transfer speed makes things difficult.

With Google Docs, I set-up a very rough Game Document with:
- Basic design overview/explanation
- A brief explanation of the aesthetics, control and general gameplay
- Ideas for characters, moves, pickups, game modes
- Basic, and Desired features
- A few pie in the sky ideas
I also set-up a Task list document, for both the game and the level editor. This became a visible area for anyone to see what I was up to and what I had done. I used this area to keep any notes about task and continually updated it.

When the competition was nearing the submission date, we had a few play-test sessions. They were all absolutely essential, the first one was useful in revealing many bugs. The game was played, and options chosen that were different to what I had tested by myself. A number of visual and gameplay points were discussed, by the end we all had very long list of changes. The next few play tests allowed us to improve the level design, the controls and more visual points. By the last play-test we were a few days away from submission, although we felt some features could be added, we were fairly confident with what we had made following the requirements we set out for it. Any new features by this point could have potentially introduced bugs or been a detriment to the game mechanics.

Present: Announcing Sumo Squash

This is the new project I referred to in my previous post. After the previous project was put on hold, we spent some time and decided on doing something simple that we knew would definitely be fun and would be defnitely achievable. We had a random idea to do a game based around a great freeware game called Jump n' Bump.



We felt the core mechanic behind was very solid, but somewhat simple and under-utilised. As we hadn't created anything of much worth by then, we decided to go with something simple, achievable that would help us on the road to something more innovative, complex and altogether richer; once we had proved ourselves with a bigger project than Herriman: Under Pressure. The general idea was to make it wacky, so Gaz and his near infinite creativity came up with the plan to use sumos as the battling characters.

Once we had got a working prototype up and running, David who worked with us on the Herriman project agreed to join forces once again. Development was roughly about 3 months. Here's are link to a video.

Game object component system

In this system, the idea is to replace the traditional hierarchical game object system based on inheritance. The need for this system was inspired by the disadvantages of the traditional system, the biggest one being class explosion. Normally, you would start with a base Object or GameObject class, in a 2D game, you might call it Sprite. This would contain the basic functionality of a game object in the scene. Each time you want to have different or more specific behaviour, for example, you may want to Draw or Update an object differently, such as with a pickup, a collidable piece or the scenery etc., in this case you will override these equivalent methods with your own or added behaviour. In a complex game with many different types of objects you may have to start creating and subclassing from a myriad of classes. An example of this would be, where you might create a Character class than will move and collide a particular way in the world, you then might have a Player class for characters that users control, that inherits from Character, then you might also have a Enemy class that inherits from Player or Character. Then, when you want a new form of enemy, some people might create a new class for each. If you had an enemy that, say, tracks the player in the world and another than moves randomly, all though its not a good example, you might create a class for each, then you might later want one that has behaviours and inherits from each (a better way would be to use the Strategy pattern, and use composition rather than inheritance to determine the new behaviour; you just swap a MovementStrategy object that an enemy calls). This could apply to many game objects, and if you do this, your class hierarchy may become large and unmanagable. A big problem you might meet is the Diamond of Death, where you trap yourself into a corner. -In this case you might start duplicating code or hacking around, just so you can get your new game object type in the world. This is never a good situation to get in.

One solution to this is the aforementioned GOC system. The idea with this to use composition, rather than inheritance to form your game objects. In this design, you start with a base object that contains a list of components that will get called either when the base object is Updated or Drawn each frame. Here's a description of how the Tony Hawk team used it.

The way I tried to use this system was by having a hierarchy of components for movement, control, drawing. Also at this point, I was thinking about integrating a physics system in an engine, so there was a component type that governed how the phyics reacted with the composed object. I've always designed my games systems to be completely data driven, so the public properties of an object can be set from a data file, this allows integration with an editor, which was one of the things I was implemeting at the time (Winforms app with XNA window). The obvious use for this is to speed up creation of a game, enable re-usability and allow artists to design levels and games (if you start adding events) without digging into code.

While I still like the idea of this system, it is, in concept, the ultimate in flexibility, and its this generality that software designers aim for, to make the possibilties of an application all the more wider, data-driven, and re-usable. There were though, a number of problems I ran into with trying to implement the system. It was too flexible. I think all software systems are a comprimise between flexibility and specific function. Flexibilty allows the function of a system to be changeable, whereas specific functionality can be more targeted. Specific systems are easier to write, as you don't need to think about the general case, just the task that needs to be currently satisfied, this allows for more performant systems.

The problem I found, was that I had to start knowing specific things about my components, especially when physics were concerned. I was implementing it in C# at the time and came up with a system that used reflection create and initialise the properties of each component. For the games that I was intending to write at the time, and the same now, this system, (even though I got quite far on the implementation) would have been far too complicated for its own good. Coming up with a reliable interface so that components could reference and call each other, while keeping them independant would have taken me a long time to achieve, and I'm not sure if it is even possible with intertwined needs that are bought about by the use of things like physics. Maybe I will return to this system, sometime in the future, but I don't think my previous use of it beats the design of the current, traditional game object hierarchy.

Past, Present, Future

Past

After some free time on a train, I've decided to write a set of updates on the progress of the (yet un-named) team that I belong to, what I've done in the past, what we've done recently and what we've got planned for the future.

After Herriman, way back last year I started writing an admittedly overly complex engine and editor based around a component system, or GOCs (game object components). I'll post a bit more about this system and my experiences soon.

Sometime after trying to prototype a game with this system and it proving to be unfruitful, me and Gaz had came up with another idea. We are both big fans of 2D platformers, and Gaz is primarily a 2D artist and animator. We had the idea to cross the character, story of a traditional platformer with the speed of a top down shooter, as I never seen it done before. This evolved into an acrobatic lead protagonist with a whole backstory (who shall remain un-named for now). We came up with a prototype, which demonstrated (very roughly), the lead character, running and sliding around, climbing and grabbing platformers and shooting in directions that was reminiscent of Earthworm Jim.

By this time I had landed myself a job after the Herriman project and was working full time, as was Gaz (as well as through the Herriman Project). The general direction we were going, was very demanding on both of us. One of the biggest problems, was that, unlike Earthworm Jim, we wanted the player to be able to shoot in the air, while climbing and grabbing at all all times. The requirement for fluid movement was at odds with this requirement, so we put this project on hold for a while. I would very much like to re-visit this idea, perhaps with a simpler character and a prototype in the future, hopefully when we finish with the current project (more about this later). This also inspired us to think about a game that was more focused on puzzling and acrobatic platforming rather than shooting action ... but this is also an idea to concentrate on for the future.