Comments - Tseng

Nice ones. I was disappointed by the lack of armors and schematics in the current Alpha. Hope there will be more in the 0.6 release

Voted for it too.

Works great so far, way better than the 0.4 version. However, one little complain so far: The ammo for ranged weapons is automatically detached when switching to a melee weapon or tool (shovel, axe etc). Which is a little uncomfortable, as one requires one more slot and always having to re-equip the ammo in order to use the weapon. Not very nice when you get attacked by surprise and quickly want to fight back ^^

That's exactly what I thought when I tried out the demo.

The idea and the procedural stuff is great, but the game won't have much chance at it's current state. On the screenshots it looks quite decent, but once you try the demo it drags you really down and the bad UI really kills most of the fun.

Also the graphics looks outdated or "out of the place" as Orteil said it. I never noticed it that much on the screenshots (they were probably photoshoped a little before being uploaded). But seeing the real graphics in the demo was really like... a punch of the face.

From the screenshots I would have it expected to be similar to Legend of Grimrock. Grimrock had nice graphics and still brought the good old school feeling on the screen.

If you could get the graphics and UI on par with Grimrock, I'm sure Malevolence will be an success (if the final game gets rid of the login stuff, this is not something people tolerate with indie games - I can accept it for the beta/alpha, but not for a final product).

edit:
Also the choice of the font is very unfortunate and quite hard to read (this Diablo-esque font)

I've sent a mail with two savegames & two output_log.txt files (one for each save) to admin@pathea.net (sorry didn't found a mail for bug reports).

You *can* generate the collision in a separate thread, but you are not allowed to interact with Unity Objects from, because for Unity.Object derived objects the same rules applies as for UI elements in Windows programming: They can only be accessed (or changed) by the thread that created then: the main thread.

Since a mesh (and a colider is basically a special form of a mesh) is just a collection of Vectors you can generate it in a seperate thread. You will just need to have a copy of the terrain data instead of directly accessing MeshFilter.mesh.

Depending on the size of the mesh it may or may not take a significant amount of memory to hold a copy of the data while working on the thread. After all the calculation is done.

Once the calculation is done, one could notify the class handling it. Unity do not have a way to invoke the main thread from a worker thread, so one would have to keep some kind of TaskQueue that is checked regularly in an Update() method and invoke the triggered event from there. Or simply add a bool variable, which is not a very clean way of doing it and feels more like an hack.

i.e.
void Update() {
if(bColliderReady)
meshCollider.mesh.vertices = newColliderVertices;
meshCollider.mesh.uv = newColliderUv
meshCollider.mesh.triangles = newColliderTriangles;
}
}

You can not modify the "meshCollider" from a separate thread, but you can calculate the data into array and then assign it in the main thread. Or alternatively use the approach of a coroutines and spread the calculation over several frames, which is in no way replacement for multi-threading but could spread the 400ms calculation over 8 frames a 50ms per frame.

Well, the issues I had (that loading fails or if it not fails the frame rate is unreasonable low, though the framerate was ok BEFORE the load) are kind of game breaking. No matter which settings I selected, if I had a save game that caused that issue I was unable to ever load it again or get the fps up.

I don't think having Unity3d source could could even help you. Most optimizations nowadays comes from optimizing the algorithm, not that much from compiler side.

You basically have several options on how to go:
1. Simplify the algorithm as mentioned above (probably most important: be careful not to trigger garbage collection too often, as Unity3D runs on an outdated Mono version, 2.6, with old and slow garbage collection)
2. Move the time critical code (i.e. voxel-terrain calculations) to a "plugin". Basically a dll. This requires Unity3d pro in order to communicate with a native plugin (one written in C/C++).
You can't use pointers in C# code directly, because Unity3d disabled unsafe code
3. If the calculation of one black do not depends on results of the other, consider using a Compute shader (new shader feature in Unity 4)

However, the FPS bug after loading a save game is somewhat weird of a bug and hard to explain why fps is ok (20-25 fps at the point of saving at 1024m range) and after loading either freezes forever in the loading screen or fps drop to 0.5 fps.

It's nice that you keep adding new stuff, but shouldn't you first fix the more obvious problems? Like the horribly performance? The memory leak (game keeps crashing when it hits ~2 GB memory?

And after a while of playing, the game freezes when loading a save game, making it basically impossible to progress. Either it will freeze/crash during loading or it will load but the frame rates will be like 0.5 fps. Seems to happen more often when saving while it's night/dawn/dusk. Sometimes saving at the second camp (where the second ship crashed) will cause this issues, but i.e. saving and loading 200m away from it seem to work.

This issues are more important than adding new stuff

Expack: I hope you are kidding? The Unity source would be somewhere in the hundred-thousands. Even "just" an Xbox/Wii/PS3 license is in the several 10.000$ range (+ the console license itself that's around 20.000-30.000+ for a single project)

Disappointed to see, that you didn't mention anywhere that Frayed Knights is up for voting on Steam Greenlight. More votes wouldn't hurt it

I have hard time believing this statement. An Indie wishing to work for the industry? This can't be a true indie, because "Indie" means independent, and working for "the industry" means losing that independence.

So either he never had the indie spirit or there is more behind it, i.e. inconstancy within the team.

Spaming friend request, can be hardly called "working hard"

Why should Bethesda join the WTH club lol.

Bethesda Soft already created procedural generated worlds, long before these guys even knew what procedural worlds are and Bethesda stopped it for a reason: procedural worlds, quests, npc generation tend to be very buggy and you have less/no design control.

Which is the reason that all Elder Scrolls games starting with Morrowind, are "hand designed" instead of procedurally generated, as it's much easier (and better) to tell a sophisticated story, which is... well not really possible with procedurally generated worlds.

I don't want to sound like jerk, but... in the previous 2 or 3 new posts you post over and over the same stuff. It won't make it easier for people who didn't understand it before to understand it now if you repeat almost the exactly same stuff every time.

And seriously, it sounds to start like some propaganda in some remote dictatorship. You used the same wording in every of the last few news posts, what you don't understand is: If someone don't understand what you're explaining to them, you should NOT repeat it, but repharse it as it's obviously badly explained, right? ;)

Also you use terms which are common for programmers like me (procedural) but the average joe user has no idea what it means. For example instead of writing "procedural content generation", you could say "the content is generated by a special/unique algorithm" and that "this algorithm always create the same world, when you feed it with with the same data" (what we programmers know as seed)).

Well, it's not like you didn't knew that laws before starting to make the game in the first place, so why you still choose to do it and instead go for a less "controversial" theme?

It's same as making a mainstream game for the US where you show nudity and the ultra-conservative republicans start screaming about it.

Unity, the engine we're using currently only runs on Windows (Desktop & Webplayer), Mac (Desktop & Webplayer), iOS (iPhone/iPad) and Android. There are also Xbox, Wii and PSN ports of Unity, but only for registered developers on these networks (5-digit licensing costs).

Currently we only have Webplayer, Desktop and Android. In order to build for MacOS (Standalone Build, Webplayer should already work on Mac) a Mac computer is required and for iOS one needs an additionally Mac computer, iPhone or iOS, Unity iOS License and AppStore access. But if the Android version is successful and money flows in, we definitely want to go for a iOS Version too. It's just, the costs for an initial iOS Version are quite high ^^

Linux is currently not supported by Unity3D. But Unity3d is working on a Flash support (will require at least Flash 11), which will then also work under Linux too.

Pretty interesting game idea