I've gotten a lot of great feedback from you guys here, and elsewhere, about the latest releases (both the Windows and the multi platform release). Some bugs have been fixed and a lot of polishing has been done on a lot of aspects of the game. Newly additions were among others a secrets counter, a breakables counter (for those of you that have OCD) and a toggleable button counter, which is handy after saving a game and returning several days later. It's hard then to know how much buttons you still had to press at that point, making Grimm tedious which is not the point of the game.

Gameplay and Balancing
Monsters have been balanced and fine tuned since the last release. The Elite Ventril (those mine throwing tough bastards) have become a lit less tough and the kick from their mines has a bit less bite, making them a more balanced mini-boss in the game. A bug where monsters would wait several seconds before spawning has also been fixed.

Grimm Quest for the Gatherer's Key: News UpdateI've not been able to work a lot (at all actually) the last few weeks due to an insanely busy schedule, but I've received some good news last week which should promise me more time for the development of Grimm. In the mapping department, some new areas have been blocked out that were 'on the shelf' so to speak. Currently, if you play Grimm completionist style then there's about 3.5 hours of gameplay to be found in the game. It's getting pretty long which is making it far more interesting in terms of development. No more major adjustments from here on in, a big one could upset all the maps and gameplay within and could mean having to go back to do a lot of work. Grimm is all about balancing and there's yet a long way to go before I'll be completely satisfied with the way the game sets up tension in each skill level.

New Media!
For your pleasure I've updated the images section with ten new images.
If you 'watch' this mod on moddb (Why not? It's fun!) then you'll find the images section is updated at least twice a month with new images and regular media updates, actually... it's filled right now with a lot of media you may not have seen yet, so stop reading and pop over there to check it.. cllllllllliiiiiiiiiiiiiickk!

BloodRayne this looks great! a small criticism the round metal part in the enemy in this shot is way rounder than the round part in the weapon, shouldn't this weapon have more polygons? i love the rooms with the big cog gears!

have you thought about levels containing endless and impossible libraries? like the cyclopean libraries in the Quoth map campaigns for quake 1: like libraries that rise towards the sky like dark spires, with black pits in front, whose darkness still reveals the walls full of book shelves that apparently floats in the void as no floor can be seen down below, and an endless selection of the most dreadful books, and moving bridges which seem to move to random places, and to random rooms which it entrance lays in the middle of the fall in those books shelves pits, but that the attentive explorer will find that the bridges actually move to selected "reading" rooms: small rooms with benches to read the dreadful books with the entrance attached, with endless candles lightning the dark environment, and secret alcoves behind selected shelves, whose content might benefit the explorer in his progress thought the Eternal Library.
A place like the eternal waiting entrance to hell within the purgatory, a place to rest and to let the time pass reading a huge amount of strange books in your eternal wait before you're sent to either hell or to heaven or both. :twisted:

Thanks! I am working on some maps that are more themed in a manner you're describing.

New screenshots!

Of course, I've been sick as a dog this last month but now finally things are looking up in the health department. I can't wait to invest some quality time into Grimm!

These shots show off the ground clutter system in action, all the stuff on the floor is spawned dynamically depending on the clutter preferences in the mainmenu. The clutter is non-solid and is added to maps either at set places, or by using a so called 'ground_clutter_surface' which spans the ground and spawns a number of groundclutter models depending on settings. The density can be controlled via density settings and clutter can be turned on/off at will. The same goes for all the models that are inside cupboards, on tables and on other places. If turned off then none of it is spawned. Other things shown here are the dynamic gibs system, which spawns gibs depending on the creature. There are still issues with decals on the walls, blood decals are sometimes really stretched giving an unnatural look to them. I'll hammer out such bugs when Grimm goes stand-alone.

In terms of standalone, the build is ready for it. I just haven't found a stable enough community source yet and the whole BFG thing is also up in the air so I'm waiting this out for a bit.

Click here for the entire image set: http://www.moddb.com/mods/grimm-quest-f ... key/images

just compile the stock source & include your own icon.

then release standalone!

You're welcome to use my cleansource if you like

http://code.google.com/p/realm/downloads/detail?name=doom3-cleansrc-29-10-2012.7z&can=2&q=

Its engine only all tools have been removed besides the game dll code (easy to add back in) so its somewhat smaller when compiled.

Notable changes are ->

Uses GLEW for OpenGL calls (makes it a ton easier to add new extentions).
Updated image handlers (Jpeg-8b/Tga2).
Slightly optimized VBO code.
Old backends removed it now needs an ARB2 capable gfx card, you can also toy with GLSL interactions but the GLSL backend only handles rendering not shadows or anything else. (could do a parallax shader in GLSL).
Tons of fixes from around the net + some i cooked up from PVS-Studio recommendations.
Better FPS counter (more precise).

TODO.
Had reports of bad performance on some ATI cards (If someone spots something im all ears as this bug has been eluding me).
BFG edition merge without breaking compatibility with Doom3.
Multiprocessor optimizations.

Im also working with one of the darkmod guys on a merger and might start to use boost for threading etc.

looks awesome.

not much else to say, except for that.

Duff wrote:

looks awesome.

not much else to say, except for that.

Thanks Duff!

Some major steps have been made towards going standalone in the last week or so. I've been going over the code and have been ironing out the last assets to replace. There's still some work to be done there in terms of the animation department. There are two major enemies that need to be re-rigged and reanimated because they make use of Vanilla Doom3 animations. After that is finished there are no ties whatsoever any more to Doom 3. Normally I don't do changelist updates, but because so much has been done, and because I want to share with you some of the progress that has been made, I've made an exception this once. Not sure when the next release will be, I'm planning for it to happen soon though, so stay tuned for news updates and more right here on Moddb!

Changes since the last major release:
- Increased entity limit
- Made several performance enhancements in the gamecode
- Moved breakables system to game code
- Implemented truly integrated skill settings for the world (traps) and combat (enemies) so players can now play Grimm in their own style.
- Skill levels were balanced further since last time, the elite Ventril is now a bit easier to kill
- Added new weapon: Cannon. Primary fire: a single cannonball with destructive power that bounces around. Alt fire: 6 small cannonballs with similar power in a large spread to quickly thin out enemy ranks.
- Moved clutter system to game code, increasing performance.
- Moved breakables system to game code.
- Removed all script hacks to add new CVars and moved all of them to proper implementations in gamecode.
- Made all traps solid for players
- trigger_hurt entity now can have damage defs set per entity type it touches
- Added several visual effects to item pickups
- Added screenflash to item pickups (configurable from the options menu)
- Added alternative attacks to all Scythe weapons, primary works the same as always (hold to charge the power, release at the right moment for a greatly charged attack). Alternative power: Repeat alternative attack at the right moment to gain power. When the powerbar is full (after 5 succesfull hits) use the primary fire for a charged attack that kills anything in the room. Difficult but very rewarding.
- Added new gameplay bonuses: 'Impressive' after 3 kills (or more) in a row, several shortcut paths and secret routes.
- Completely finished 6 maps, including lighting, detail and clip brushes.
- Made all breakables and gibs lifetime configurable from the options menu (g_gibslifetime, g_breakableslifetime).
- Remodelled and reanimated the Scythe weapons from scratch.
- [edit] Almost forgot an important one, added new launchProjectile method that takes a projectile def, for proper alt-fire implementation. One weapon can now have any number of projectile defs.
- Much... much... more...

As always I update the image section 2-3 times per month so check it out!

I'd be interested to know what the gamecode performance enhancements were.

Moving all the scripting I did to the dll really helped with performance. I had to set up all sorts of loops to check for things in script, which I could make event based while in the dll. It's mostly there where I gained performance. I'm currently thinking about moving all the other scripting to the engine as well, cutting out scripts all together.

Makes sense. I keep toying with that idea of doing that for the scripts used in MP.

It was pretty important to do it for Grimm as it was, up to a week ago it was a script only mod. But there was just so much I could do. I definitely wanted true check pointing and a bunch of other features that were simply completely impossible through scripting.

Uploaded a new gameplay video!

Looking good

Is that my engine running it ? seems a lot more responsive now

No, not yet. Didn't get around to merging objects yet.
This is the latest sdk build with the current D3 engine.

Fair enough

btw i spotted a bug in the Doom3 gui code where it tries to delete the paddle. The BOBRICK destructor needs to be changed to virtual ~BOBRICK since the constructor has virtual elements. Should take care of some leaking

BloodRayne wrote:

Moving all the scripting I did to the dll really helped with performance

You should get a couple dozen cookies just for now making a package people can use for their own standalone projects w/o rewriting the AI, weapons, etc. scripts!

The Happy Friar wrote:

BloodRayne wrote:

Moving all the scripting I did to the dll really helped with performance

You should get a couple dozen cookies just for now making a package people can use for their own standalone projects w/o rewriting the AI, weapons, etc. scripts!

I can release the SDK as is, but there's still lots to do and port. I'll release the proper code when it's finished to a degree where I can package some assets around it so anyone can use it as base. For the moment though all my spare time goes into making Grimm (or promoting it.

).

Oh, almost forgot an important one: I added a new launchProjectile method to script that takes a projectile def, for proper alt-fire implementation. One weapon can now have any number of projectile defs. And I added a method where you can call any 'exec' or 'cmd' from script, e.g. 'god' or 'loadmap' or 'savegame <a>' etc..

What I mean is that since you ported most of the scripting to code, when you release it standalone it'll be GPL, so people will have a base to start with. Wait all you want!

bkt wrote:

Have you done much with the cross level triggers yet? I've seen them in the events.script and such, but haven't looked into them very much as my current project is a single map.

I never looked at those. For hubbing and cross-level stuff I'll most likely use persistantArgs.

Crosslevel triggers are pretty handy. They date back to either Quake 1 or 2. The trigger in the other map can do anything (call a script, move stuff, open/close things, etc) and it's inter-level persistent when you switch across maps.

Very cool.

But they aren't Vanilla Doom 3, right? I mean I never found a func_crosslevel_trigger.

gb_remake wrote:

The video looks very good. I especially like the rotating platforms and swinging obstacles. I look forward to playing this myself.

The levels are good, but I'd imagine they could be spiced up with a little setpiece / visual hotspot from time to time. Here are some examples of what I mean:

http://pixeltheater.files.wordpress.com ... anging.png

http://www.visualwalkthroughs.com/biosh ... uare/7.jpg

Just memorable things that especially catch the eye and don't need to be functional - one or two of these per level can make it a lot more memorable and also help players with orientation.

The other thing that occurred to me was that the levels could be more three dimensional - what I mean is, more stairs and vertical movement can break things up. A nice staircase can also lend a lot of character to a room as a side effect.

http://images.wikia.com/bioshock/images ... _Foyer.png

This room ^ is *defined* by that double staircase - simple yet effective.

Excuse the Bioshock references, it really just serves as a technical example. I also haven't played the mod yet, so it's possible that you're already doing this.

Poeh! Almost missed this post. Thanks for the pointers, I agree. Just one thing, wait up for the rest of the maps and play the game, you ain't seen nothing yet.

This is Purgatory and all that's been designed so far is the gameplay and 'clean' environments. So there will be a lot more references to both Heaven and Hell.
I'm definitely going to add a lot more gore, death and destruction to the maps in the near future. Such details will part of be the final detailing phase.

But I will also add some 'heavenly' places. One part will be a very sterile set of maps set in Heaven, where the war will be a staunch contrast to it's clean environment.

Yup, in stock d3:

Code:

entityDef target_levelTrigger {
   "editor_color"         "1 1 0"
   "editor_mins"         "-8 -8 -8"
   "editor_maxs"         "8 8 8"

   "editor_usage"            "Trigger this to trigger a trigger an upcoming map. It will be triggered when the player spawns"
   "editor_var levelName"      "level name to fire trigger in, this is the map name minus the path, i.e. admin"
   "editor_var triggerName"   "trigger name to fire"

   "spawnclass"         "idTarget_LevelTrigger"
}

EDIT: what is the time span (so far) from the day you said "I'm going to do this" and now? I'm curios.

The Happy Friar wrote:

Yup, in stock d3:

Code:

entityDef target_levelTrigger {
   "editor_color"         "1 1 0"
   "editor_mins"         "-8 -8 -8"
   "editor_maxs"         "8 8 8"

   "editor_usage"            "Trigger this to trigger a trigger an upcoming map. It will be triggered when the player spawns"
   "editor_var levelName"      "level name to fire trigger in, this is the map name minus the path, i.e. admin"
   "editor_var triggerName"   "trigger name to fire"

   "spawnclass"         "idTarget_LevelTrigger"
}

EDIT: what is the time span (so far) from the day you said "I'm going to do this" and now? I'm curios.

I'm going to check that out seems interesting, lol I never saw it.

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

BloodRayne wrote:

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

18 months and you're about, what, 1/3rd way through your game, all by yourself? Impressive.

What are your commercial plans (if any) for it? These maps you've been showing as the "demo" & the rest of the game for sale?

The Happy Friar wrote:

BloodRayne wrote:

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

18 months and you're about, what, 1/3rd way through your game, all by yourself? Impressive.

What are your commercial plans (if any) for it? These maps you've been showing as the "demo" & the rest of the game for sale?

Thanks, there is a reason that it went fast and that's because I've put a lot of effort into standardisation. Instead of creating each wall and each asset uniquely I've opted to make my assets so that I can drag/drop them into maps without a lot of effort. So the first 6 months it was just me creating the func_movingtrap entities, weaponscripts and gameplay feel etc..etc.. When all of those were made I decided on a set of basic rules that would help me not lose time on the details. My experiences with EOC really helped me there. I could circumvent all the pitfalls I've ran into in the past and really 'work production'.

It was that and a nearly blinding drive to work at least one hour per day on this, no matter what. Due to illness this wasn't always possible, but most of the time I managed to keep this up.

So getting quick and good results is a combination of work-ethic (just do it even if your not in the mood at all) and standardisation (make sure that you can quickly create maps by mainting a pre-set ruleset for each map). These rulesets define which textures I'll use, how high a door is, how high the walls are, which cupboards are used, which cluttertype, which traps etc..etc..
An extra advantage there is the fact that this standardisation also creates consistency in the maps and artwork!

There are definitely commercial plans. But I am not going to go into any details there unless all the plans are set in stone and I am sure that all copyright and trademark issues are solved. I currently have a lawyer figuring out all the legalities regarding the GPL, a trademark for Grimm (turns out there's a TM on Grimm, some TV show I never heard of in the US that's not even aired here in Europe) and other things I need to keep in mind when going commercial. So until all of those details are clear (and I know my rights) I won't divulge any details.

The only thing I can say is that I am hoping to release this as a full commercial title at the end of 2013 and I am currently looking into ways to simply take 6 months off full time to work on it.

Man I wish I had been that efficient in the last 18 months. Credit to you for that level of commitment! As I said earlier my project is a single level and it's been almost 3 years since I started work on it... mind you I did get a degree in that time, but that's a poor excuse

I also tried to standardize a lot of the development, but it's easy to say you've done a far better job than I. Even after prefabricating a lot of the themes throughout I still took weeks to great the geometry for some areas.

Is your visual style locked in now? Or do you think you'll come back and add more geometric detail later on. As I'm sure (because it always happens...) you're last few levels will look amazing and looking back on the first few just won't feel as nice

Well, that's how I find it at least.

Not sure in the EU, but in the USA trademarks are for names and their area of creation. IE if the guys who made "Grimm" in USA didn't trademark it for video games, it's clear.

I don't believe it would be an issue though, that's not the name you're going by. You're going by "Grimm Quest for the Gatherer's Key" and the TV show is "Grimm".

It would be interesting what your lawyer says about the GPL though. I'm assuming they're going by the laws in your country but it shouldn't be a problem with what you're doing.

How did you go about designing your levels/creatures? I'm working on something and I decided that I want the environment based on what the creatures I'm making can do, so I'm designing some of the creatures first, then the levels around them (I'm sketching out maps now, but actually implementing creatures). Normally I'd design a map around what I want and then always have issues when placing my monsters (in D3 or Q2): wouldn't fit, bbox to big, they get lost, etc.

I figured that this way, putting together the maps will be easier because I already know what will happen (by the drawing designs) and will know how the AI will react to circumstances (so I can setup traps/sceneros the way I want).

I'm a play-test designer. So I create a room, a puzzle, an idea, something to focus on for that area then I finish it, play it, add monsters, test it. Then I go onto the next area.
When you do that a lot there comes a point where you think ahead because you know the pitfalls that you need to avoid (too small areas, etc..etc..). So I've had sessions where I created nearly half a map in one night without playing it. Then testing and tweaking things a bit.

I don't do sketching, planning or any other such things besides thinking a lot about what I'd like to play and what it should look like.
I have a basic rule set: Each style spans 3 maps, then I go for a new style. For that style I have one basic wall texture, one basic trim texture, one basic model for the cupboards, one set of 6-8 models for the clutterobjects and one style for the doors. That's about as fixed as the maps are.

Before I start mapping I try to figure out some sort of idea for the map. For example, in the dark warrior complex this was to make the players feel nearly claustrophobic with areas that become smaller and smaller as the player progresses. Then suddenly it opens up into a huge vertical area where the player spends nearly 5 minutes of gametime. So I try to use stuff like that to play with the players emotion a bit. The other 'set in stone' rule is to always prevent frustration and/or ragequit.

The trick is to keep your texture set small, your model set small then create the maps with that limited set of resources. This gives you coherence, lots of practice with the texture set, and a lot of time gains because you aren't creating and searching for the right textures in each environment. Then you can always come back later. Currently I'm working pretty much simultaneously on all 6 maps. Sometimes I play the entire game, make screenshots of issue areas 'for the next time I'm working'. Then I open the screenshots and work my way through them, tweaking and refining the maps in sweep after sweep.

I've gotten a lot of great feedback from you guys here, and elsewhere, about the latest releases (both the Windows and the multi platform release). Some bugs have been fixed and a lot of polishing has been done on a lot of aspects of the game. Newly additions were among others a secrets counter, a breakables counter (for those of you that have OCD) and a toggleable button counter, which is handy after saving a game and returning several days later. It's hard then to know how much buttons you still had to press at that point, making Grimm tedious which is not the point of the game.

Gameplay and Balancing
Monsters have been balanced and fine tuned since the last release. The Elite Ventril (those mine throwing tough bastards) have become a lit less tough and the kick from their mines has a bit less bite, making them a more balanced mini-boss in the game. A bug where monsters would wait several seconds before spawning has also been fixed.

Grimm Quest for the Gatherer's Key: News UpdateI've not been able to work a lot (at all actually) the last few weeks due to an insanely busy schedule, but I've received some good news last week which should promise me more time for the development of Grimm. In the mapping department, some new areas have been blocked out that were 'on the shelf' so to speak. Currently, if you play Grimm completionist style then there's about 3.5 hours of gameplay to be found in the game. It's getting pretty long which is making it far more interesting in terms of development. No more major adjustments from here on in, a big one could upset all the maps and gameplay within and could mean having to go back to do a lot of work. Grimm is all about balancing and there's yet a long way to go before I'll be completely satisfied with the way the game sets up tension in each skill level.

New Media!
For your pleasure I've updated the images section with ten new images.
If you 'watch' this mod on moddb (Why not? It's fun!) then you'll find the images section is updated at least twice a month with new images and regular media updates, actually... it's filled right now with a lot of media you may not have seen yet, so stop reading and pop over there to check it.. cllllllllliiiiiiiiiiiiiickk!

BloodRayne this looks great! a small criticism the round metal part in the enemy in this shot is way rounder than the round part in the weapon, shouldn't this weapon have more polygons? i love the rooms with the big cog gears!

have you thought about levels containing endless and impossible libraries? like the cyclopean libraries in the Quoth map campaigns for quake 1: like libraries that rise towards the sky like dark spires, with black pits in front, whose darkness still reveals the walls full of book shelves that apparently floats in the void as no floor can be seen down below, and an endless selection of the most dreadful books, and moving bridges which seem to move to random places, and to random rooms which it entrance lays in the middle of the fall in those books shelves pits, but that the attentive explorer will find that the bridges actually move to selected "reading" rooms: small rooms with benches to read the dreadful books with the entrance attached, with endless candles lightning the dark environment, and secret alcoves behind selected shelves, whose content might benefit the explorer in his progress thought the Eternal Library.
A place like the eternal waiting entrance to hell within the purgatory, a place to rest and to let the time pass reading a huge amount of strange books in your eternal wait before you're sent to either hell or to heaven or both. :twisted:

Thanks! I am working on some maps that are more themed in a manner you're describing.

New screenshots!

Of course, I've been sick as a dog this last month but now finally things are looking up in the health department. I can't wait to invest some quality time into Grimm!

These shots show off the ground clutter system in action, all the stuff on the floor is spawned dynamically depending on the clutter preferences in the mainmenu. The clutter is non-solid and is added to maps either at set places, or by using a so called 'ground_clutter_surface' which spans the ground and spawns a number of groundclutter models depending on settings. The density can be controlled via density settings and clutter can be turned on/off at will. The same goes for all the models that are inside cupboards, on tables and on other places. If turned off then none of it is spawned. Other things shown here are the dynamic gibs system, which spawns gibs depending on the creature. There are still issues with decals on the walls, blood decals are sometimes really stretched giving an unnatural look to them. I'll hammer out such bugs when Grimm goes stand-alone.

In terms of standalone, the build is ready for it. I just haven't found a stable enough community source yet and the whole BFG thing is also up in the air so I'm waiting this out for a bit.

Click here for the entire image set: http://www.moddb.com/mods/grimm-quest-f ... key/images

just compile the stock source & include your own icon.

then release standalone!

You're welcome to use my cleansource if you like

http://code.google.com/p/realm/downloads/detail?name=doom3-cleansrc-29-10-2012.7z&can=2&q=

Its engine only all tools have been removed besides the game dll code (easy to add back in) so its somewhat smaller when compiled.

Notable changes are ->

Uses GLEW for OpenGL calls (makes it a ton easier to add new extentions).
Updated image handlers (Jpeg-8b/Tga2).
Slightly optimized VBO code.
Old backends removed it now needs an ARB2 capable gfx card, you can also toy with GLSL interactions but the GLSL backend only handles rendering not shadows or anything else. (could do a parallax shader in GLSL).
Tons of fixes from around the net + some i cooked up from PVS-Studio recommendations.
Better FPS counter (more precise).

TODO.
Had reports of bad performance on some ATI cards (If someone spots something im all ears as this bug has been eluding me).
BFG edition merge without breaking compatibility with Doom3.
Multiprocessor optimizations.

Im also working with one of the darkmod guys on a merger and might start to use boost for threading etc.

looks awesome.

not much else to say, except for that.

Duff wrote:

looks awesome.

not much else to say, except for that.

Thanks Duff!

Some major steps have been made towards going standalone in the last week or so. I've been going over the code and have been ironing out the last assets to replace. There's still some work to be done there in terms of the animation department. There are two major enemies that need to be re-rigged and reanimated because they make use of Vanilla Doom3 animations. After that is finished there are no ties whatsoever any more to Doom 3. Normally I don't do changelist updates, but because so much has been done, and because I want to share with you some of the progress that has been made, I've made an exception this once. Not sure when the next release will be, I'm planning for it to happen soon though, so stay tuned for news updates and more right here on Moddb!

Changes since the last major release:
- Increased entity limit
- Made several performance enhancements in the gamecode
- Moved breakables system to game code
- Implemented truly integrated skill settings for the world (traps) and combat (enemies) so players can now play Grimm in their own style.
- Skill levels were balanced further since last time, the elite Ventril is now a bit easier to kill
- Added new weapon: Cannon. Primary fire: a single cannonball with destructive power that bounces around. Alt fire: 6 small cannonballs with similar power in a large spread to quickly thin out enemy ranks.
- Moved clutter system to game code, increasing performance.
- Moved breakables system to game code.
- Removed all script hacks to add new CVars and moved all of them to proper implementations in gamecode.
- Made all traps solid for players
- trigger_hurt entity now can have damage defs set per entity type it touches
- Added several visual effects to item pickups
- Added screenflash to item pickups (configurable from the options menu)
- Added alternative attacks to all Scythe weapons, primary works the same as always (hold to charge the power, release at the right moment for a greatly charged attack). Alternative power: Repeat alternative attack at the right moment to gain power. When the powerbar is full (after 5 succesfull hits) use the primary fire for a charged attack that kills anything in the room. Difficult but very rewarding.
- Added new gameplay bonuses: 'Impressive' after 3 kills (or more) in a row, several shortcut paths and secret routes.
- Completely finished 6 maps, including lighting, detail and clip brushes.
- Made all breakables and gibs lifetime configurable from the options menu (g_gibslifetime, g_breakableslifetime).
- Remodelled and reanimated the Scythe weapons from scratch.
- [edit] Almost forgot an important one, added new launchProjectile method that takes a projectile def, for proper alt-fire implementation. One weapon can now have any number of projectile defs.
- Much... much... more...

As always I update the image section 2-3 times per month so check it out!

I'd be interested to know what the gamecode performance enhancements were.

Moving all the scripting I did to the dll really helped with performance. I had to set up all sorts of loops to check for things in script, which I could make event based while in the dll. It's mostly there where I gained performance. I'm currently thinking about moving all the other scripting to the engine as well, cutting out scripts all together.

Makes sense. I keep toying with that idea of doing that for the scripts used in MP.

It was pretty important to do it for Grimm as it was, up to a week ago it was a script only mod. But there was just so much I could do. I definitely wanted true check pointing and a bunch of other features that were simply completely impossible through scripting.

Uploaded a new gameplay video!

Looking good

Is that my engine running it ? seems a lot more responsive now

No, not yet. Didn't get around to merging objects yet.
This is the latest sdk build with the current D3 engine.

Fair enough

btw i spotted a bug in the Doom3 gui code where it tries to delete the paddle. The BOBRICK destructor needs to be changed to virtual ~BOBRICK since the constructor has virtual elements. Should take care of some leaking

BloodRayne wrote:

Moving all the scripting I did to the dll really helped with performance

You should get a couple dozen cookies just for now making a package people can use for their own standalone projects w/o rewriting the AI, weapons, etc. scripts!

The Happy Friar wrote:

BloodRayne wrote:

Moving all the scripting I did to the dll really helped with performance

You should get a couple dozen cookies just for now making a package people can use for their own standalone projects w/o rewriting the AI, weapons, etc. scripts!

I can release the SDK as is, but there's still lots to do and port. I'll release the proper code when it's finished to a degree where I can package some assets around it so anyone can use it as base. For the moment though all my spare time goes into making Grimm (or promoting it.

).

Oh, almost forgot an important one: I added a new launchProjectile method to script that takes a projectile def, for proper alt-fire implementation. One weapon can now have any number of projectile defs. And I added a method where you can call any 'exec' or 'cmd' from script, e.g. 'god' or 'loadmap' or 'savegame <a>' etc..

What I mean is that since you ported most of the scripting to code, when you release it standalone it'll be GPL, so people will have a base to start with. Wait all you want!

BloodRayne wrote:

For the moment though all my spare time goes into making Grimm (or promoting it.

).

Could you share stats? How many people downloaded the mod to the date? How many active users does it have (the ones who returns regularly for updates or return to the game's page)? What region of the world play it the most?

BR - it's a delight to see your game evolving with your skills to new heights. I love continuous improvements over big leaps and you seem to really follow the rules of IT development which is the equal importance of technical optimization and artistic input.

Keep it up!

Since you ported to code recently, can we get some timedemo's, r_speeds, etc? I'd love to see how much the game was sped up by.

A friend told me for each line of script D3 uses 7 lines of code to access that. I'd hope you'd get a 7x performance increase.

The Happy Friar wrote:

Since you ported to code recently, can we get some timedemo's, r_speeds, etc? I'd love to see how much the game was sped up by.

A friend told me for each line of script D3 uses 7 lines of code to access that. I'd hope you'd get a 7x performance increase.

There's one problem here. BR's got sikkmod running which affects performance drastically, however sikkmod isn't compatible with timedemos. A while ago I tried measuring performance increases in a dynamic environment, but the result though noticeably improved (reading the FPS counter myself during play) wasn't something I could actually measure because without sikkmod features (during a timedemo) the game itself didn't stress my system enough to hit performance.

I've found that Doom3's performance is now held back almost exclusively by CPU power and without something like sikkmod running, it takes a lot to slow it down significantly. However your FPS will be very sensitive to batch size/light counts once sikkmod is running.

bkt wrote:

I've found that Doom3's performance is now held back almost exclusively by CPU power and without something like sikkmod running, it takes a lot to slow it down significantly.

Really? Try this viewtopic.php?f=26&t=26011

motorsep wrote:

BloodRayne wrote:

For the moment though all my spare time goes into making Grimm (or promoting it.

).

Could you share stats? How many people downloaded the mod to the date? How many active users does it have (the ones who returns regularly for updates or return to the game's page)? What region of the world play it the most?

All stats are public on my moddb profile.

BNA! wrote:

BR - it's a delight to see your game evolving with your skills to new heights. I love continuous improvements over big leaps and you seem to really follow the rules of IT development which is the equal importance of technical optimization and artistic input.

Keep it up!

Thanks BNA!

The Happy Friar wrote:

Since you ported to code recently, can we get some timedemo's, r_speeds, etc? I'd love to see how much the game was sped up by.

A friend told me for each line of script D3 uses 7 lines of code to access that. I'd hope you'd get a 7x performance increase.

Not really sure I can compare anything to anything right now. Tweaks and ports go from script to script. I slowed down stuff by using brainfrying script to begin with. :mrgreen:

The video looks very good. I especially like the rotating platforms and swinging obstacles. I look forward to playing this myself.

The levels are good, but I'd imagine they could be spiced up with a little setpiece / visual hotspot from time to time. Here are some examples of what I mean:

http://pixeltheater.files.wordpress.com ... anging.png

http://www.visualwalkthroughs.com/biosh ... uare/7.jpg

Just memorable things that especially catch the eye and don't need to be functional - one or two of these per level can make it a lot more memorable and also help players with orientation.

The other thing that occurred to me was that the levels could be more three dimensional - what I mean is, more stairs and vertical movement can break things up. A nice staircase can also lend a lot of character to a room as a side effect.

http://images.wikia.com/bioshock/images ... _Foyer.png

This room ^ is *defined* by that double staircase - simple yet effective.

Excuse the Bioshock references, it really just serves as a technical example. I also haven't played the mod yet, so it's possible that you're already doing this.

bkt wrote:

BR's got sikkmod running which affects performance drastically, however sikkmod isn't compatible with timedemos.

Then let's remove sikkmod for a timedemo. I'm more interested in seeing what the performance gain was for moving stuff to code. I don't use sikkmod anyway.

The Happy Friar wrote:

bkt wrote:

BR's got sikkmod running which affects performance drastically, however sikkmod isn't compatible with timedemos.

Then let's remove sikkmod for a timedemo. I'm more interested in seeing what the performance gain was for moving stuff to code. I don't use sikkmod anyway.

I'm not sure this is clear, but I was the cause of the performance issues to begin with. All I can say is that by moving all my (while(1)) and (eachframe) scripts to the engine code (where such things belong) CPU usage went from 32% to 26% on my rig.

What kind of computer are we talking about here? I ran your mod on my PC and I didn't have any issues util I enabled all of the Sikkmod's features.

motorsep wrote:

What kind of computer are we talking about here? I ran your mod on my PC and I didn't have any issues util I enabled all of the Sikkmod's features.

The new build which has not been released yet has breakables, clutteritems, lots of timers and new scripts that were affecting performance badly. This was one of the reasons why I chose to move from scripting to SDK finally. So there were none of these issues in that build. I have an Intel I7 with 6GB of memory, using a GTX 285, the pc is not the issue.

But having 10 or 12 threads like these running..:

Code:

void startMapTimer() {
   mapstarttime = sys.getTime();
   totalplaytime = 0;
   totalplaytime = sys.getPersistantFloat("totalplaytime");
   
   float playtimeSeconds;
   float playtimeS;
   float playtimeM;
   float playtimeH;
   
   float tplaytimeSeconds;
   float tplaytimeS;
   float tplaytimeM;
   float tplaytimeH;
   
   while(1) {
      playtimeSeconds = sys.getTime() - mapstarttime;
      
      playtimeH = (playtimeSeconds / 60) / 60;
      playtimeH = int(playtimeH);
      
      playtimeM = (playtimeSeconds / 60) - (playtimeH * 60);
      playtimeM = int(playtimeM);
      
      playtimeS = (playtimeSeconds) - (playtimeM * 60);
      playtimeS = int(playtimeS);
      

      tplaytimeSeconds = totalplaytime + playtimeSeconds;
      tplaytimeSeconds = int(tplaytimeSeconds);      
      sys.setPersistantArg("totalplaytime", tplaytimeSeconds);   
      
      tplaytimeH = (tplaytimeSeconds / 60) / 60;
      tplaytimeH = int(tplaytimeH);   
      
      tplaytimeM =  (tplaytimeSeconds / 60) - (tplaytimeH * 60);
      tplaytimeM = int(tplaytimeM);
      
      tplaytimeS = tplaytimeSeconds - (((tplaytimeH * 60) * 60) + (tplaytimeM * 60));
      tplaytimeS = int(tplaytimeS);

         
      sys.setcvar("maptime", playtimeH + "h " + playtimeM + "m " + playtimeS + "s");
      sys.setcvar("totalplaytime",tplaytimeH + "h " + tplaytimeM + "m " + tplaytimeS + "s");
      
      sys.wait(1);
      sys.waitFrame();
   }
}

Was a problem...

Imagine this:
- I wanted to show a map timer on the mainmenu.
- you cannot send anything from script to the mainmenu so I had to circumvent this by misusing cvars.
- Now I didn't have these in code, so I stuck them in autoexec.cfg (otherwise the hud and mainmenu bombs out).
- I was using editDefs to show simple static info
- I was pingponging data from script to the engine, to the gui, back into the script... just to display some times.

In the SDK this was much simpler, I could take out the CVars, use regular GUI vals and skip the entire script all together.

Now imagine 12 of these kinds of scripts running in scriptthreads, called each frame from (player_think), one to take care of the background music, one to take care of the dashing routine etc..etc...etc.. chaos!

Was, not any more.

All right, so you moved all the player-threads to the code that you talked about MONTHS ago.

I remember you saying how awesome player threads were. And you didn't move any of the weapons or AI to the code. Bummer, I was hoping to see how that increased performance.

The Happy Friar wrote:

All right, so you moved all the player-threads to the code that you talked about MONTHS ago.

I remember you saying how awesome player threads were. And you didn't move any of the weapons or AI to the code. Bummer, I was hoping to see how that increased performance.

They are AWESOME. :mrgreen:

Weapons, AI that will be my next experiment, then you can benchmark yourself.

And I secretly still have a challenge or 2 regarding the move from script to code...sjjjj...

The Happy Friar wrote:

bkt wrote:

BR's got sikkmod running which affects performance drastically, however sikkmod isn't compatible with timedemos.

Then let's remove sikkmod for a timedemo. I'm more interested in seeing what the performance gain was for moving stuff to code. I don't use sikkmod anyway.

You're forgetting that timedemo playback bypasses the gamecode logic and simply plays back the OpenGL calls, so you won't see what the gain is there.

Couldn't you build a scripted loop that does nothing but iterare till x and logs the difference in seconds between start and end time?

BloodRayne wrote:

Weapons, AI that will be my next experiment, then you can benchmark yourself.

I couldn't actually. I'd assume you've done enough changes between now & last release benchmarking them wouldn't be an accurate test.

It's interesting to see you tackling issues you're encountering while making your D3 game. If I had PD I'd interview you again about it!

I miss PD. It was really good exposure for me.

How big do you plan on the game being once it's finished? You said you have 6 maps done now, how many will make up the full game?

I am aiming for 12-14 hours of gameplay. 6 maps is roughly 4 hours of gameplay.
So that would make 18 maps in total, for a full game.

But I am considering the next 6 maps to be real HUB, where the player has puzzles that can cross multiple maps.
That would extend the playtime but would also give me a new set of challenges.

Have you done much with the cross level triggers yet? I've seen them in the events.script and such, but haven't looked into them very much as my current project is a single map.

bkt wrote:

Have you done much with the cross level triggers yet? I've seen them in the events.script and such, but haven't looked into them very much as my current project is a single map.

I never looked at those. For hubbing and cross-level stuff I'll most likely use persistantArgs.

Crosslevel triggers are pretty handy. They date back to either Quake 1 or 2. The trigger in the other map can do anything (call a script, move stuff, open/close things, etc) and it's inter-level persistent when you switch across maps.

Very cool.

But they aren't Vanilla Doom 3, right? I mean I never found a func_crosslevel_trigger.

gb_remake wrote:

The video looks very good. I especially like the rotating platforms and swinging obstacles. I look forward to playing this myself.

The levels are good, but I'd imagine they could be spiced up with a little setpiece / visual hotspot from time to time. Here are some examples of what I mean:

http://pixeltheater.files.wordpress.com ... anging.png

http://www.visualwalkthroughs.com/biosh ... uare/7.jpg

Just memorable things that especially catch the eye and don't need to be functional - one or two of these per level can make it a lot more memorable and also help players with orientation.

The other thing that occurred to me was that the levels could be more three dimensional - what I mean is, more stairs and vertical movement can break things up. A nice staircase can also lend a lot of character to a room as a side effect.

http://images.wikia.com/bioshock/images ... _Foyer.png

This room ^ is *defined* by that double staircase - simple yet effective.

Excuse the Bioshock references, it really just serves as a technical example. I also haven't played the mod yet, so it's possible that you're already doing this.

Poeh! Almost missed this post. Thanks for the pointers, I agree. Just one thing, wait up for the rest of the maps and play the game, you ain't seen nothing yet.

This is Purgatory and all that's been designed so far is the gameplay and 'clean' environments. So there will be a lot more references to both Heaven and Hell.
I'm definitely going to add a lot more gore, death and destruction to the maps in the near future. Such details will part of be the final detailing phase.

But I will also add some 'heavenly' places. One part will be a very sterile set of maps set in Heaven, where the war will be a staunch contrast to it's clean environment.

Yup, in stock d3:

Code:

entityDef target_levelTrigger {
   "editor_color"         "1 1 0"
   "editor_mins"         "-8 -8 -8"
   "editor_maxs"         "8 8 8"

   "editor_usage"            "Trigger this to trigger a trigger an upcoming map. It will be triggered when the player spawns"
   "editor_var levelName"      "level name to fire trigger in, this is the map name minus the path, i.e. admin"
   "editor_var triggerName"   "trigger name to fire"

   "spawnclass"         "idTarget_LevelTrigger"
}

EDIT: what is the time span (so far) from the day you said "I'm going to do this" and now? I'm curios.

The Happy Friar wrote:

Yup, in stock d3:

Code:

entityDef target_levelTrigger {
   "editor_color"         "1 1 0"
   "editor_mins"         "-8 -8 -8"
   "editor_maxs"         "8 8 8"

   "editor_usage"            "Trigger this to trigger a trigger an upcoming map. It will be triggered when the player spawns"
   "editor_var levelName"      "level name to fire trigger in, this is the map name minus the path, i.e. admin"
   "editor_var triggerName"   "trigger name to fire"

   "spawnclass"         "idTarget_LevelTrigger"
}

EDIT: what is the time span (so far) from the day you said "I'm going to do this" and now? I'm curios.

I'm going to check that out seems interesting, lol I never saw it.

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

BloodRayne wrote:

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

18 months and you're about, what, 1/3rd way through your game, all by yourself? Impressive.

What are your commercial plans (if any) for it? These maps you've been showing as the "demo" & the rest of the game for sale?

The Happy Friar wrote:

BloodRayne wrote:

I checked the starting date yesterday and the first check-in I did in my first source-control check-in May 27th 2011.
So I've worked on this for 18 months so far. That's pretty swell considering how far I am.

18 months and you're about, what, 1/3rd way through your game, all by yourself? Impressive.

What are your commercial plans (if any) for it? These maps you've been showing as the "demo" & the rest of the game for sale?

Thanks, there is a reason that it went fast and that's because I've put a lot of effort into standardisation. Instead of creating each wall and each asset uniquely I've opted to make my assets so that I can drag/drop them into maps without a lot of effort. So the first 6 months it was just me creating the func_movingtrap entities, weaponscripts and gameplay feel etc..etc.. When all of those were made I decided on a set of basic rules that would help me not lose time on the details. My experiences with EOC really helped me there. I could circumvent all the pitfalls I've ran into in the past and really 'work production'.

It was that and a nearly blinding drive to work at least one hour per day on this, no matter what. Due to illness this wasn't always possible, but most of the time I managed to keep this up.

So getting quick and good results is a combination of work-ethic (just do it even if your not in the mood at all) and standardisation (make sure that you can quickly create maps by mainting a pre-set ruleset for each map). These rulesets define which textures I'll use, how high a door is, how high the walls are, which cupboards are used, which cluttertype, which traps etc..etc..
An extra advantage there is the fact that this standardisation also creates consistency in the maps and artwork!

There are definitely commercial plans. But I am not going to go into any details there unless all the plans are set in stone and I am sure that all copyright and trademark issues are solved. I currently have a lawyer figuring out all the legalities regarding the GPL, a trademark for Grimm (turns out there's a TM on Grimm, some TV show I never heard of in the US that's not even aired here in Europe) and other things I need to keep in mind when going commercial. So until all of those details are clear (and I know my rights) I won't divulge any details.

The only thing I can say is that I am hoping to release this as a full commercial title at the end of 2013 and I am currently looking into ways to simply take 6 months off full time to work on it.

Man I wish I had been that efficient in the last 18 months. Credit to you for that level of commitment! As I said earlier my project is a single level and it's been almost 3 years since I started work on it... mind you I did get a degree in that time, but that's a poor excuse

I also tried to standardize a lot of the development, but it's easy to say you've done a far better job than I. Even after prefabricating a lot of the themes throughout I still took weeks to great the geometry for some areas.

Is your visual style locked in now? Or do you think you'll come back and add more geometric detail later on. As I'm sure (because it always happens...) you're last few levels will look amazing and looking back on the first few just won't feel as nice

Well, that's how I find it at least.

Not sure in the EU, but in the USA trademarks are for names and their area of creation. IE if the guys who made "Grimm" in USA didn't trademark it for video games, it's clear.

I don't believe it would be an issue though, that's not the name you're going by. You're going by "Grimm Quest for the Gatherer's Key" and the TV show is "Grimm".

It would be interesting what your lawyer says about the GPL though. I'm assuming they're going by the laws in your country but it shouldn't be a problem with what you're doing.

How did you go about designing your levels/creatures? I'm working on something and I decided that I want the environment based on what the creatures I'm making can do, so I'm designing some of the creatures first, then the levels around them (I'm sketching out maps now, but actually implementing creatures). Normally I'd design a map around what I want and then always have issues when placing my monsters (in D3 or Q2): wouldn't fit, bbox to big, they get lost, etc.

I figured that this way, putting together the maps will be easier because I already know what will happen (by the drawing designs) and will know how the AI will react to circumstances (so I can setup traps/sceneros the way I want).

I'm a play-test designer. So I create a room, a puzzle, an idea, something to focus on for that area then I finish it, play it, add monsters, test it. Then I go onto the next area.
When you do that a lot there comes a point where you think ahead because you know the pitfalls that you need to avoid (too small areas, etc..etc..). So I've had sessions where I created nearly half a map in one night without playing it. Then testing and tweaking things a bit.

I don't do sketching, planning or any other such things besides thinking a lot about what I'd like to play and what it should look like.
I have a basic rule set: Each style spans 3 maps, then I go for a new style. For that style I have one basic wall texture, one basic trim texture, one basic model for the cupboards, one set of 6-8 models for the clutterobjects and one style for the doors. That's about as fixed as the maps are.

Before I start mapping I try to figure out some sort of idea for the map. For example, in the dark warrior complex this was to make the players feel nearly claustrophobic with areas that become smaller and smaller as the player progresses. Then suddenly it opens up into a huge vertical area where the player spends nearly 5 minutes of gametime. So I try to use stuff like that to play with the players emotion a bit. The other 'set in stone' rule is to always prevent frustration and/or ragequit.

The trick is to keep your texture set small, your model set small then create the maps with that limited set of resources. This gives you coherence, lots of practice with the texture set, and a lot of time gains because you aren't creating and searching for the right textures in each environment. Then you can always come back later. Currently I'm working pretty much simultaneously on all 6 maps. Sometimes I play the entire game, make screenshots of issue areas 'for the next time I'm working'. Then I open the screenshots and work my way through them, tweaking and refining the maps in sweep after sweep.