• Register
Post news RSS Montague's Mount - Development Update 27/01/13

It has only been a couple of days since the last update but quite a lot has happened in the world that is Montague’s Mount. 1. Localization, 2. Save game system, 3. GUI pages, 4. Optimised terrain, textures, mesh poly counts and LOD, 5. Postprocessor rain the the eyes effect.

Posted by on

It has only been a couple of days since the last update but quite a lot has happened in the world that is Montague’s Mount.

  1. Localization.
  2. Save game system.
  3. GUI pages for save game system.
  4. Optimised terrain, textures, mesh poly counts and LOD.
  5. Postprocessor rain in the eyes effect.

1. Localisation
To get the game ready for different languages I had to go through the source code and find *ALL (I bet some have slipped through the net for QA to find!) the text. This in itself was a massive task and something that wasn’t the most rewarding of jobs! (I’m glad I don’t work in a localisation role). With being an indie developer, just getting a project finished is a major achievement and my initial goal. To that end, I can safely say that any languages other than English were far from my mind whilst making the game. Most of the in-game texts were hardcoded as string variables. With the game getting ever nearer to completion, I thought I would spend a day or two getting a semi-robust localisation system in place and *ALL those embedded strings swapped out for method calls. This has left me with all *ALL the strings just sitting in one text file. So when the time comes to get the language translations, all I need to do is send the one text file with English, and hopefully new versions will come back from the translators in the new languages. These just need ‘plugin’ into the system which is a no brainer.

2. Save game system
Just like the Localisation issue, I thought I would spend a bit of time now thinking about a save game system before the project gets any larger. I have made the decision to go for a checkpoint system instead of a ‘save the game anywhere you want’. I generally don’t like the ‘save anywhere’ systems as it makes people hit save every few minutes just in-case something happens. With Montague’s Mount being exploration and puzzle based, the checkpoint system seems to fit nicely. The game’s environment is naturally split into areas which revolve around a number of puzzles, and when these puzzle have been completed, the game creates a checkpoint automatically. This also has benefits from a programming point of view as I don’t really need to worry too much about the objects in the world, just what puzzles have been completed.

3. GUI pages for the save game system
I also rustled up some images for the save-game checkpoints. 30 minutes in Photoshop and we’re all done.

4. Optimised terrain, textures, mesh poly counts and LOD
With the game getting bigger, bolder and more asset laden, Unity has started to drag it’s heals a bit; especially with the Mac version. It was always going to be a problem to get the Mac version running as smoothly as its PC counterpart due to the lower spec’d hardware. With the animations running at 30 FPS, that is the benchmark to keeping things moving smoothly in Montague’s Mount. On my nVidia GTX580 the PC version was running at a stable 80-100fps which was great; and with the extra fps in hand I am confident I can get 30-45fps on most PC graphics cards, even older ones (I still haven’t benchmarked properly though). 30-45 may not seem that high, but the pace of Montague’s Mount is not rushed and is perfectly fine. That said, people who do have high-end hardware will get a fantastic experience!

The Mac is a different story. My iMac testing machine is from early 2010 and the GPU is a mobile version of an ATI Radeon 5670. These laptop-type GPU’s just don’t have the horsepower required for something as graphically intensive as Montague’s Mount and we fell below the magic 30 fps number! So I was left with a dilemma… do I make a lower detailed version of the game or go to ‘plan B’?

‘Plan B’ it is (for now)… I revisited the terrain and cut back on poly count. To be honest, I should have done this a while ago as most of the terrain’s finer details are meshes anyway. After quite a bit of tweaking I managed to shave of about 400 drawcalls! Gulp, that was a worthy saving! I then turned my hand to the textures and saw which could have their resolutions cut. I was surprised just how many 1024’s could be 512’s without any noticeable artefacts (well, there are always artefacts, but when you are walking past a rock, who really spends any time examining it). I then had a bash at the models and reduced polycounts like you wouldn’t believe; again without any real noticeable difference. This shaved the memory footprint and killed about 1 million polys in places.All in all a good days’ work and the Mac version is back up to 35fps and smooth. Plus all these saving get passed onto the other platforms, so everyone benefits.

5. Postprocessor rain in the eyes effect
With all this less than stimulating coding and tweaking, I thought I would spend a few hours on eye candy… so we have a new effect to simulate rain on the lens. Yes I know it’s physically not correct, but it is a nice effect and adds to the ambience. We will see if it ultimately stays in based on player feedback from the Beta.

A very bleak day on the island

It is not really noticeable on a still image but if you look to the lower right of the picture you will see the blurred spots.Well, that has been my last 3 days… bye for now!

- Matt (PolyPusher Studios)

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.