Creating graphics for games can be quite technical at times. A game artist needs to keep in mind that there’s a finite amount of memory available for graphics in the game. In essense the less an individual art asset takes memory, the more of them you can have which results in visual diversity. Basically that means more varied wallsets, monsters, items etc.

Textures are real graphics memory hogs. That’s why in game art we use all kinds of tricks to keep texture count and sizes low. In this post I’m going to be talking about a method of using the same pieces over and over again to create multiple different assets without any new textures. Sometimes this is called kitbashing.

Exhibit number uno: Wooden supports for the mine environment


(click on the pictures to enlarge them)

I was tasked to create a wooden support structure for our mine wallset. The environment required multiple kinds of configurations ranging from a fence like wall piece with support pillars and beams to a bridge piece for connecting over chasms.

It wouldn’t have made much sense making every asset unique, meaning that every asset has it’s own set of textures, since that would have taken a lot of memory. The assets needed had also pretty big surface areas which means that to keep texel resolution (size of texture pixels in the 3d world) consistent, the textures would’ve had to be big. In grimrock we’ve aimed to keep our texel resolution 1024×1024 pixels per 3x3meters. (our grid size)

So with these limitations in mind I set out to design the assets needed. First we made a simple sketch of what the assets and the environment might look like with Antti. Antti described requirements from a gameplay standpoint and dished out some environment artist wisdom from his Alan Wake days. I also looked at some reference pictures of how supports like these are usually built.

Next step was trying to figure out what kind of pieces I’d need to create them in 3D.

I tried to keep the number of pieces to a minimum, and to figure out how to accomplish that I used a technique we call whiteboxing. It’s essentially just another type of a sketch, but in 3D and placed in game. Using this technique has the advantage of seeing very early on how the asset might appear in game and what kind of dimensions it occupies. Later after the high detail modeling is done, it’s usually difficult to make changes if problems like intersecting with other objects in the environment arise. For example, some of our bigger monsters might intersect through the asset while prowling through the caverns of our mines if the assets are not carefully measured. This technique also helps with making sure the pieces have correct proportions. It’s easy to make planks, nail heads, etc. too big so that they appear cartoonish in game compared to the surrounding environment.

My solution to making multiple mine assets from a single set of textures (diffuse, specular and a normalmap) was to make a collection of different sized planks, beams and some metallic binders I’d use to attach the wooden pieces together. It’s probably what you’d get from a trip to the hardware store in the grimrock world! To create the textured assets I took the whiteboxed pieces to zbrush and sculpted them into what I needed and then created game resolution meshes and textures from the sculpts.

After that it was just a matter of assembling the pieces into what I needed.

When I was finished with assembling the assets we could let Antti off the leash and create our exciting environments!

The added benefit of this techique is that these pieces can then be used elsewhere also!
… and in the case of this collection of hardware store material, everywhere. :)

Aaaand that’s it. I hope this was an interesting read and if you have questions just post them in the comments and I’ll try to answer them!
- Jyri

 


Big news indeed! Oh boy we’re super-excited to tell you that we are now officially in BETA! And it’s about time! We have been burning the midnight oil for so long that all our dreams are now filled with visions directly from the Isle of Nex. The game, a raw diamond which we have been carefully chiseling and polishing so long, is now finally coming together and it’s starting to feel really good. That doesn’t mean that the work ends here. Beta is actually a beginning, a beginning to make the game meet all your high expectations. It’s time to balance all the thousands of gameplay parameters and finetune the gui and optimize the game, and… You get the point! All the features we’ve planned are in and just waiting for some TLC

But before you mail us offering to kindly join the beta-test team… It’s going to be a closed beta again, sorry. Closed beta worked really well with LoG1 and we’re looking to repeat the process. By giving beta access to a carefully selected group of people, we can personally interact with the testers much better and thus get better and more accurate feedback.

The game has been playable from the beginning to the end for some time now and now that we have had one complete playthrough and several cheated speed-throughs we have some idea about the length of the game. It’s looking like Grimrock 2 is going to be around 25% longer than Grimrock 1 but more testing by us and our betatesters is still needed to confirm this.

Like mentioned, all the features of the game are in, but there’s still much work to do. Our Venerable List of Things To Do is constantly getting added with new entries even as we are hammering on the things at the other end of the list. But we are fighting hard to empty the list before the launch. Btw. on top of the list we have things like memory and performance optimizations and tutorial. Below that lots and lots of smaller tweaks and fixes and then of course testing, testing and more testing…

To celebrate all this, we have published a new teaser trailer for Legend of Grimrock 2. Here you go:

But that’s not all (I’ve always wanted to say that)! Many of you may be wondering what the heck happened to the iOS version of Legend of Grimrock!? And rightly so. The truth is we really, really would have liked to work on it, but there never has been enough time to truly make it happen. We care so much about the quality of our games that hiring some random dude who we do not know personally to do the porting work just did not seem right to us (no offence to “the random internetz folks!”). But now things have changed. A friend of us and a coder extraordinaire, Juha Pinola has now been working on the iOS version of Legend of Grimrock 1 for some time and the game is shaping up really well. We do not know the release date just yet other than “when it’s done” but we’ll let you know when we know, ok? The game isn’t just a direct port from the PC version of Legend of Grimrock. We have always felt that the game wouldn’t work on touch screens straight out of the box but needed a few custom mechanics to get the benefits of the touch interface.

So there you have it! No more secrets between you and us (or is there?!?). We’ll keep you posted on the progress of the iOS version and the development of Grimrock 2. We also hope to be able to soon officially announce the release date of Grimrock 2…

Be excited, be very excited!

-Juho and Petri on behalf of the Almost Human crew

Aug 132014
 

As a ratling you may seem weak and disease ridden on the surface, but you are actually one of the most adaptable and hardy creatures in the world. You are hoarder in nature and greatly enjoy fiddling with mechanical contraptions…

As some of you may know, we’re introducing a new playable race in Legend of Grimrock 2. There is no place in the Northern Realms without them scurrying around. They have spread all over the lands as they seem to wander around endlessly and seldom stay in one place for a long time. Those creepy rodents are sometimes hated and feared for their scruff looks and contagious diseases they bear. But hardly anyone denies the fact that they find their way around the realms and that they are known to be some of the most seasoned creatures there is.

When you pick a ratling in the game’s character generation section, you get to choose your looks from the portrait gallery, done by our friend Emile Denis. Read more about the creation of the new portraits in here. In game terms ratlings have Strength -4, Dexterity +2, Max Load +15kg and are immune to diseases. Ratlings also get a chance to pick a special racial Mutation trait which boosts one randomly chosen ability score by 1 at level up.

But ratlings are not only found in your party. Like mentioned above, ratlings are everywhere and I mean everywhere, even on the Isle of Nex. Ratlings often enlist to ship crews and pirate galleys to roam the seas of the realms and some of them have shipwrecked and get stranded on the Island. On the Isle of Nex they have nested in the western parts of the island, but they often wander about the island but carefully avoid “The Boss”. Whenever you smell gunpowder in the air, you’re sure to know there’s ratling pirates around.

 

We are getting nearer to the finish line and one of the remaining things on our todo list for Grimrock 2 is music production. Like in Grimrock 1, in-game audio will only consists of ambient sounds and sound effects. This is a deliberate design choice and we think it really helps immerse you as the player to the world we have created. In Grimrock 1 we only had the Grimrock theme playing in the main menu, but this time we also have intro and outro cinematic videos and for those we need a cinematic score.

Enter Scoring Helsinki. Scoring Helsinki is a group of four music industry professionals with a studio conveniently located in Helsinki just a fifteen minute ride from our office. The guys approached us a few months ago and simply blew us away with their demo tracks. It did not take long for them to convince that they were the perfect guys for this job. Simply put, Perttu, Hannu and Henri of Scoring Helsinki are super-talented and the most hardworking guys we have had the pleasure working with. We can really recommend these guys, should you need Hollywood grade music for a movie, or soundtrack for a game, these guys can do it.

I’ll end my part here and let the guys do the greetings from their end.

“Hello dudes and dudettes!

We’ve been busy scoring the game for the last few weeks, and it’s coming together nicely. Currently we’re doing some final polishing for the tracks, doing some sound designing and getting started with the mixing process, so practically the production’s almost wrapped. It’s been extremely fun, lots of excellent live musicians, lots of various atmospheres, can’t wait for you to get to play the game and hear everything in context!

Grimrock on,

-Perttu, Hannu and Henri/Scoring Helsinki”

 

Hey, our summer vacations are starting just in a few hours so here’s a quickie Grimrock 2 status update before we vanish into oblivion (aka. the beautiful Finnish summer). I myself have been dueling against a cursed todo-list which, when one item is struck off the list, grows back to its full size! The speedy regeneration of the list is made possible by a full-time albeit temporary tester, Erik, we have had here in the office playing through the game for the last two weeks. That means that there’s been a barrage of tiny tweaks and improvements to all the areas of the game: a lot of detailing, fine tuning and balancing! So a LOT of small things have happened but despite the small size of the tweaks, they’ve been so numerous that game has really taken a huge leap towards being a finished product.


Here Erik is seen carefully advancing through the game

Despite the big advances we’ve had lately, the best way to progress with the project right now actually is to take a short two week break so we can get some fresh air and see the game with fresh eyes again. It’s been long journey, longer than we initially even set out to do, and it’s very easy to start suffering from a sort of a development speed blindness where it gets real hard to judge your own work, and judgement is what we need when we get back to work and start to wrap things up! After the vacation we intend to get the game to a beta status ASAP and continue extending the testing efforts to find all the remaining bugs and balancing issues. And like with the previous game, when we talk about beta testing, we don’t mean an open beta so no need to send in any applications. I know you mean well but we’d rather have you playing the finished, well-polished product instead since we already have a pretty secure supply of friends-n-family testers. :)

That’s all for now, thank you for reading and we’ll see you again after the vacations!

PS. one thing we forgot to mention a while back was that me and Petri took part in the previous Ludum Dare 48h game jam. So, if you’re dying for some sweet, “Almost Human certified” gameplay, check out The Monastery, an oldschool RPG by Petri, and Bathyscaphe 11, a fast paced top-down shooter by Antti. ;)

 

We sneakily went past a very important milestone just a while ago. Legend of Grimrock 2 is now in alpha! The definition of milestones of course varies from one company to the next but I think our alpha is, relatively speaking, a “strong alpha” (since we don’t have any publishers or investors who we have to deliver to to get money for progressing in development, we can use terms that are actually useful and descriptive ;) ). Alpha in our case means that the game can be completely played from beginning to the very end and that all the planned features exist. The last missing piece from the alpha we had was the ending of the game but now that we got that done, the deal is sealed. :) Of course at alpha, there are still features and content that lack polish and refinement, and balance and progression of the game is not complete, but in a sense the game is now “whole”! To celebrate the milestone, we have a new screenshot for you… The herders are back!

 
And like the natural order of things typically is, after alpha comes beta and that’s where we’re heading next! To get there, me and Petri have been doing a systematic polishing round for all the levels. Or maybe I should be talking about “areas” instead since each area that we tackle contains, technically speaking, 1-4 levels of varying sizes. Each day we pick one area of the game that we concentrate on and for the duration of the day we work only in improving that one place. Basically what we do is that we fix the biggest issues that arise from playing the level but we don’t limit ourselves on only improving the levels themselves (like the level layout, monster placement, puzzles, items and secrets) but we also work on game design issues (for example underwater gameplay, herbs and potions), visuals (lighting & atmosphere, particles, items & environment objects), audio (ambient & environment sounds, monster sounds) or even the game interface (automap and such) if need be.

One day for each area is not a lot of time but doing a pass like this over the whole game really improves the overall experience since this way we always tackle the weakest spots of the game without getting stuck into details for too long. This also helps us by breaking down the game into more digestible bits that we can focus on since trying to polish the whole game at once feels like an overwhelming task and it would always be difficult to decide what would be important to do next.

Oh and if you want more details on the progress of the development, Petri often tweets about things he’s been working on with the game.

 

Hello everyone and welcome to another episode in the acclaimed “Hey, Look at What We’ve Been Up to Lately” -series! It’s been a while since we’ve had one of these posts so there’s been a lot of stuff that we haven’t covered. So sit on tight because there’s gonna be a lot of text!

Alright, let’s jump right into the deep end and start with the skill system! I’m not going to go into too much detail here since it’s still a little work-in-progress and the details can change once we clock in some more testing hours with it, but finally we seem to be reaching an equilibrium where we feel comfortable with how the skills and character traits work. Now we have a system that’s easy to approach but which still offers plenty of depth, tactics and replayability for all players and which should be more extendable and flexible for modders (and us too). It’s so nice when everybody wins! :)

Character creation screen also got a much needed makeover, partly due to the ripple effects from the improved skill system, and it’s looking very slick now. Even though a lot of players will only see the screen just once (or not at all if they opt in to go with the default party), it’s still super important since it’s a major part of the first impressions that the game will give.

We’ve also redone the automap. The automap in Grimrock 1 was pretty good but since the sequel features outside areas and a less linear level structure (levels are side-by-side as well as on top of each others), the old way didn’t really work anymore. Now we have a smoothly scrolling and zoomable map which handles the environments of the new game much more elegantly. It’s not 100% complete though since it’s missing the ability to write down notes, some of the icons are still placeholders and a few interface elements are missing but hey, we’re almost there!

One major milestone that we’re also rapidly approaching right this moment is getting the end combat done. We have a very interesting prototype brewing and if it proves to be working the end fight is gonna be one hell of a ride! As a matter of fact, the end fight is really the only major missing bit I can think of that we still need to make the game whole (which, mind you, is not the same thing as finished).

Speaking of prototypes, I threw together a quick test about a herb growing or farming mechanism but we’re still on the fence if it’s a good fit for the game. We’re going to meditate on it for a while and see if the idea feels worth implementing properly.

Things have been galloping along in the realm of graphics and audio content creation too. We now have a few glorious landmarks for the bigger structures of the game world and an assortment of decorations to spice up the underground portions of the game. I’ve done a couple of new spooky ambient tracks too and polished some older ones as well so that they suit the mood of the game better. And like always with the posts in these series, we’ve got new monsters and plenty of new items! ;) Oh yeah, Juho also has done some key art (or box art or whatever you want to call it) for Grimrock 2 and it’s looking glorious although I think I’m not allowed to show it to you yet since I think Juho would want to do the honors… Sorry, I hate to be a tease but I’m sure you’ll see it sooner or later. :)

That’s it for now from us but if you’re hungry for some more Grimrock right now, you should try out One Room Round Robin 2 mod. It’s a massive mod built in collaboration by 22 master modders and they’ve really pushed the Grimrock 1 engine to its limits! Check it out!

 

It’s time to shed some light behind the dusty curtains that cover the massive art department of Almost Human and take a look at some behind the scenes action. A lot of new shady creatures have been creeping around the studio walls and this time we’ll try to catch one of them. Be very, very quiet, we’re hunting Zarchtons. Zarchtons are one of the first monsters you’ll come across in the beaches of the Island. At first you’ll hear their croaking calls and before you know what hit, you realize you’ve been ambushed.

Zarchtons are amphibious creatures that are as home on dry land as in water, but they never leave too far from water, because they are dependent of water and need to dampen their skin from time to time. That’s why Zarchtons are usually seen around water, but that doesn’t limit to natural water sources. Overflown dungeons are also perfect environment for them too…

The origin of Zarchtons is highly debated topic in the Natural Science Department of the Nothampton’s University. Some say Zarchtons have evolved from fishes and some say they we’re originally land creatures that have moved to live partially in water. Sometimes Zarchtons are seen far in the open sea and they are often mistaken for mermaids. Being amphibious creatures, Zarchtons have both lungs and gills, so they can breath air and in water. Zarchtons have primitive culture system and they make use of resources from the sea to create clothing and accessories from shellfishes and other small creatures they hunt. Swimming in water and walking on land have developed Zarchtons’ leg muscles to enable them to take long leaps to help them hunt their prey and attack anyone coming to their territory…

What goes to actual development of the Zarchtons, the process was pretty standard stuff. We thought of some features and characteristics we needed in a monster and based on that data I started roughing it out. And this is what I ended up:

 
Then it was off to Zbrush to create the high resolution model using Zspheres as a base and just dynameshing the living crap out of it.

 
After the high resolution model was done, it was decimated a bit and exported to 3dCoat, we’re I retopoed and unwrapped it ending to around 6200 polygons. High resolution data was baked into normal map and rest of the textures were painted in Photoshop.

 
And finally, here’s a final posed model for Zarchton. I bet you’ll end up peeking under his skirt.

 

Normally the last few weeks of development before launch are really stressful because everything has to come together in a nice clean package. Usually this means frantically trying to fix the remaining bugs, making sure the game runs great on all supported hardware while at the same time polishing the game. The last weeks are very critical to achieving that certain high quality feel. That’s why this time I’ve decided to ease the pain of the last few weeks with a head start. In this blog post I’ll talk about the most important performance optimizations that I’ve been working on for the last two weeks.

Performance Profiler

Some might think that optimizing is boring and tedious because the work is very time consuming and nothing seems to happen to the game on the surface. To help with this I’ve turned opimizing into a sort of game for myself. Whatever I’m optimizing I first come up with some metric, usually a number whose value I can track and try to make it as small as possible. I set up a challenge for myself to see how low I can push that number. Some things are easy to measure like memory consumption of the process with Windows Task Manager or the time needed to process a single frame. But to really dig deep into performance issues it’s necessary to breakdown the measurements into smaller bits to get a better idea what to optimize. Therefore I built a performance profiler directly into the game that I can summon with a press of a button.

The profiler shows milliseconds and percentage of frame time spent in each subsystem of the game and various other statistics. To run at 60 frames per second the computer can spent up to about 16 milliseconds to process each frame, including updating the game world and rendering the view. The profiler also shows amount of temporary memory allocations (Malloc column) during the frame — more about that later.

Memory optimizations

Legend of Grimrock 2 is a 32-bit application on Windows so that means that the application can use up to 2GB of memory without hacks. To make matters worse in my experience the real limit is closer to 1.5GB presumably because DirectX resources eat up virtual address space. Textures and other assets eat a lot of memory so 1.5GB is not that much today. Optimizing memory usage will also help with load times, and can potentially increase overall performance too. It’s important to get the memory usage as low as possible without sacrificing quality of assets.

After cleaning up unused assets we determined that we still needed to shave off some more memory so I begin looking into what could be done on the code size. One easy optimization which was already planned for Grimrock 1 but I never had time to work on was a simple animation compression technique. In Grimrock 1 animations are stored as “array of structs”, where the struct contains position, rotation and scale. This was not optimal because, for example, scaling is very rarely used. In fact most skeletal animation nodes have only rotation movement. A simple optimization is to store keyframes as “struct of arrays”, meaning that position, rotation and scale keys are optional. For many animation nodes we just need to store constant position and scale values and varying rotation keyframes. This optimization cut the memory usage of animations by 20 MB.

Another big optimization was compression of vertex format used by models. Previously all model vertices had normal, tangent, bitangent and texcoord vectors stored as 32-bit floating point values. Floats have a very big range and high precision, more than we need so I compressed those into 16-bit integers. Also a common trick is to leave out the bitangent needed for normal mapping because it can be reconstructed in the shader by computing the crossproduct of the normal and tangent vectors (TBN handedness still need to be stored but it fits nicely into tangent vector’s fourth component). Vertex format optimization yielded about 75 MB saving.

Rendering optimizations

Grimrock 1 didn’t need a geometry level of detail system but Grimrock 2 has much longer view distances and has many more models on the screen so the number of triangles drawn can get quite large. I had implemented a very simple level of detail (LOD) rendering system some months ago where we simply swap between high detail and low detail meshes based on their distance from the player. While this increased the frame rate this resulted in ugly snap when the lod level was changed which limited the usability of the system. When doing the performance optimizations I revisited the old lod system. After doing some initial tests with the artists we figured that a crossfade between the LODs would be the ideal solution. Unfortunately alpha-blending the models is out of the question with a light prepass deferred renderer. A pretty common technique is to use alphatest dissolving instead. I used the technique successfully in Alan Wake’s rendering engine and it still works great today. The end result is quite good and it’s hard to see the LOD transition even if you know what’s going on. We also use the same dissolving technique to fade out small objects like grass.

We are using distorted planar reflections for our water rendering and this requires rendering the scene twice, once for the main view and once mirrored upside down. This can get really heavy on frame rate. Fortunately it’s not necessary to draw the reflected scene with full detail. In fact many object don’t need reflections at all, usually those that are far away from the reflective surface (except if they are really tall like towers). Making an automatic solution that handles all cases nicely is pretty hard, so we gave a few hints to the renderer to help pick the objects to reflect. Objects in Grimrock 2 have three reflection modes: “never” means that the object is never reflected. It’s used for small objects like most items. “always” means the object is always reflected, like the sky and very large structures. “cell” is the default option and used by almost everything. With this option we take advantage of our grid structure. The level designer can paint in Dungeon Editor which cells in the level have reflections enabled. Static objects with “cell” reflection mode will then skip reflection rendering if their cell is not reflective. For dynamic objects we currently use either “never” or “always” mode so that we don’t have to check constantly where they are and update their reflection enable flag.

Game world update

Years of object oriented programming tends to produce bad habits. One good example is the game object update logic that was in place two weeks ago. In Grimrock 2 game objects such as monsters, doors and teleporters are made from components such as lights, models, clickable zones and particle effects. In the object-oriented way each game object had a update() method which calls update() for all its components. Can you see what’s wrong with this? There are at least two big problems (and a few other missed optimization opportunities). First the code has to iterate through all components regardless if they actually need to be updated. For example models do not need to be updated at all because there is nothing dynamically changing about them. Secondly the code has to “megamorphically dispatch” to the component update routine, meaning the code is jumping between different component types all the time. This code branching is very slow. A much better approach is to update all components of given type in one go, i.e. update all particle systems in one pass, update all animations in one pass and so on, something like this:

...
updateComponents(LightComponent)
updateComponents(AnimationComponent)
updateComponents(FloorTriggerComponent)
...

This restructuring of update alone saves several milliseconds per frame. It also has other very nice properties. The code is easier to profile and it’s easy to toggle updating of component by type. It’s also trivial to change the update order of component types. For example, animation components should be updated after monsters so that animations start playing immediately, not one frame after the monster’s brain has decided what to do.

With all of these optimizations in place the average frame rate seemed decent (we haven’t tested on low end setups yet though so we may have go back to optimizations later). I have a frame rate number displayed on the screen all the time and I’ve set it up so that it turns bright red if the frame rate dips below 60 fps. While testing I noticed that every now and then, apparently for now reason, the frame time spiked above 16ms. I immediately began suspecting Lua’s garbage collector and added Lua memory statistics to the profiler. It turned out we were allocating about 40 KB per frame, at 60 fps that’s about 2.5 MB per second! After a few seconds of this Lua decided that enough is enough and collected garbage which dipped the frame rate. We were very lucky that this problem had not surfaced with Grimrock 1. Lucky because garbage collection issues are really hard to fix. I suspect that the working set and garbage generated was much smaller in Grimrock 1 so the problem did not exist.

I began hunting down the source of garbage. Thanks to the update restructuring it was easy to add per component type mem alloc statistics and a few culprits were quickly found. Some cases were easy to optimize away, like the creation of temporary tables here and there. Much more problematic was vector math code that created a lot of temporaries. Lua garbage collector is not particularly good at short lived temporaries like these. I decided to try an experimental technique, to make a separate vector and matrix classes that would be allocated from a pool. At the end of the frame the temp vectors and matrices would be returned back to the pool. The only problem was how to handle “boxing”. Temporaries could not be stored permanently in objects’ fields because their values would become corrupt at the end of current frame. A simple solution is to use boxed vectors as member variables and copy the values explicitly from temporary to the boxed version. It’s a bit of a chore to do it but it seems to work okay.

I still haven’t gone through all the places but the most bad behaving temporary allocating routines have now been optimized. As a result temporary memory allocations per frame has gone down from over 40KB to about 4KB per frame. My goal is to keep optimizing it below 1 KB. Garbage collection is already pretty harmless but I want to beat it so there’s no doubt about it.

That pretty much sums up the work of the past two weeks. Together with content optimizations the game now uses about 25% less memory and runs 25% faster. Not bad for two weeks of work! Hopefully this was an interesting read. If not, then prepare yourself for some more artsy blog update coming next! :)

 

Information about Grimrock 2 has been a little scarce lately so it’s about time we unravel some of the mysteries. Let’s get going!

The events of Legend of Grimrock 2 will happen on the Isle of Nex, a secluded island faraway from civilization. An island is a perfect place to setup an unforgettable dungeon crawling experience because we can mix indoor and outdoor locations seamlessly while still maintaining that atmosphere of mystery and danger, and the density of interesting things that is at the heart of Grimrock. If you think about it, the island is the perfect microcosm, where the party may explore dark woods, misty swamps, underground tunnels and ancient ruins without need to travel great distances. For us, an island is the perfect “dungeon” with a welcome variety of different types of environments.

At the start of the game, a party of four prisoners has ended up on the island against their will and start to explore the island. Pretty soon they will realize that they are not alone on the island and that the island is not an ordinary island at all… What are the mysterious towers on the island and who built them? Why is the island full of puzzles and traps? The story of Grimrock 2 will not be a direct continuum to Grimrock 1, but will be a completely new story with new characters that will expand the Grimrock universe.

A big part of Grimrock is, of course, the brain-teasing puzzles and for Grimrock 2 we have been busy developing new types of puzzle mechanics. Talking about puzzles is a tricky subject to discuss. We believe that the less you know about them in advance the better. So without ruining the surprises ahead, let’s just say that you’re not the only one stuck in the puzzles…

One of the few things some reviewers criticized about Grimrock 1 was monster behavior in combat. We have attacked this problem directly and rewritten the monster AI entirely. As a result monsters are now smarter and they know how to use their larger numbers to their advantage. The repertoire of tricks they know has been expanded greatly. For example, some monsters can call other monsters for help and can use group tactics against you. Of course the behavior of monsters depends on their intelligence so the most stupid and most fierce monsters are still, well, fierce and stupid as they should be. And talking of monsters, there will be lots of new monsters with some of the old, familiar faces making an occasional appearance for old times sake.

As explained in an earlier blog post , the character skill system has been completely redesigned and replaced with a perk-buy system that allows for more flexible character skill development. The design goal is make each level up meaningful and at the same time contain a tough choice. At level up, each character gains only one perk that changes the character in some way. Every perk gained is important. There are no in-between levels.

Tied to the skill system is the item system, which has also been expanded. Many items now have secondary powers that can be triggered by holding down the right mouse button on the action icon. The powers consume energy and range from special attacks to non-combat actions. In contrast to Grimrock 1, primary actions of items can be most often used by any character but the true powers can be used by a character with the right skills.

Potions can now be mixed directly in hand without going to inventory.
Spells can be cast using mouse gestures with less mouse clicks.

We have also improved the spellcasting and potion crafting systems to reduce the required number of mouse clicks. Potions can now be mixed without going to the inventory. Using an empty flask in hand will open up a miniature potion crafting panel (see screenshot) which you can even use in the middle of combat much like the spellcasting interface.

The new spellcasting panel allows mouse gestures to be used to cast spells. Spells are cast by holding the mouse button down while doing a swipe with the mouse on the correct sequence of runes. Talking of magic, the Mage character class has also been redesigned. The requirements to cast spells of different schools have been relaxed so that mages can cast larger variety of spells. In Grimrock 2, mages need not be one trick ponies.

Of course, Grimrock 2 also has new spells, a new playable race (with portraits to go) and a new character class. These combined with over a hundred new items, 22 new monsters, new environments, day to night cycle, plus as much more as we have time to crank in, means a lot of new stuff to have fun with!

In other news, we also have a big reason to celebrate today. Legend of Grimrock: The Series from Wayside Creations, the makers of Fallout: Nuka Break, has just been successfully funded on Kickstarter! WOOHOO! Wayside did a fantastic job with Fallout so we are super excited to see how Grimrock will translate to the new medium. Naturally we will assist Wayside and make sure the series will be true to the lore of Grimrock. There are still 4 days remaining on the Kickstarter, so if you want to take part in the development of the live series, there’s still time!

This post is getting rather long already, so let’s stop now to oogle at these shiny new screenshots!

© 2013 Almost Human Ltd. Suffusion theme by Sayontan Sinha