The Long Journey

2012-07-17T16:49:00.000+10:00

Playing with soundtracks, here is the one for bone\ivory biome:

Introducing the Ninja

2012-07-13T12:27:00.002+10:00

Hey guys, time for my new post has come. I'm done with all exams I had this half of year, so I was working on the new engine's design for some time. The new engine was given the code name of Ninja. We decided that its main features must be support of cross-platform and multithreading technologies and also it must be modular. The engine's core is be combined from several manager objects. Each manager represents definite system that do its own work. Some of them are: platform manager (platform-related functionality), task manager (multithreading and work tasks), system manager (handles external systems' modules, which will do all the gameplay work - rendering, sounding, physics, AI, etc.). BOOST and SPARSEHASH help a lot with memory and objects management. I made about 1/3 of the planned work to make a limited but working alpha. Stay tuned for more news.

Development process.

2012-07-12T22:22:00.001+10:00

As described in previous posts, game style is going to be designed as abstract, something people have forgotten in the 3D era of video games. And gameplay is going to be designed to provide a deep strategic experience, richly rewarding players with extensive knowledge of game mechanics.

These design choices reflect two main points of the development process of this game.

As a developer - clarity as a quick way to formulate what to do in our next step of development at any given time, and rationalism as an effective distribution of resources will be prevalent. To reflect these two key attributes of development, the game world is an abstract, comical presentation of basic laws of physics.

As a gamer - main questions are "How can a game improve my understanding of our world and what original ideas can it raise?" and "How can the efficiency of games be improved? How can both players and developers make them more enjoyable as an art and as an information medium?". This is why the gameplay concept is designed to stimulate and reward player logic and imagination.

We are not making a game to waste our and our players time. We are making a game to improve ourselves and to provide an example of how to improve the industry. This is our main goal and we intend to follow it clearly and efficiently.

The game itself

2012-06-21T21:58:00.000+10:00

While working on the game engine, we slowly formed a concept-like structure for the game world. Which eventually led to this "event history"-type description that we will use.

It begins with empty 4-dimensional space that contains dust-like substance.

Dust attracts to itself, forming 3-dimensional pockets(bubbles) where dust condenses into dense force-field-like crystals made of dust orbiting within the crystal.

Resulting 3D pockets have a finite volume, within which the crystal asteroids are scattered, and an "atmosphere" layer with winds of dust flowing around the 3D bubble in 4D space. A "lithosphere" layer (around which the 3D bubble is wrapped) also exists, made of solid crystal.

In the bubble, simple compounds form in the crystal asteroids. Different combinations of dust orbitals give parts of crystals properties like propulsion, dust detection, signal processing. Without propulsion, which throws out unused dust orbitals back into space(thus cleaning the inner orbital structure) a crystal quickly gathers dust onto itself and loses its functions, thus becoming inert. Through this process, natural selection slowly creates simple crystalline lifeforms, that are able to propel themselves within the 3D pocket, evade collisions and areas with high-density dust, grow and multiply by adding complex orbital combinations to their structure, communicate within themselves sending signals about known dangerous areas, etc.

Sentient lifeforms eventually evolve on this crystalline basis. Settlements are formed in the pocket, and an industry based on mining crystal asteroids begins. As a byproduct of harvesting useful dust orbitals from crystals, large amounts of dust are exerted into the pocket and its atmosphere layer.

To get rid of high dust concentrations in the pocket, this sentient life builds regeneration plants that transform free dust into lumps of organised miniature mechanisms, capable of maintaining the resulting jelly-like substance. Regeneration plants are launched into dense clouds of dust and left there.

Generated substance develops in a similar manner to its creators, and begins showing signs of intelligence.

As a result, we have an ecosystem with three components - dust in its free and compressed forms, intelligent life with settlements and mining operations in low dust density areas and near compressed dust asteroids, and wildlife with tribes near regeneration plants in high dust density areas.

Ideally, we would like to create this world as a whole, real-time ecosystem. We will start with high-density dust areas and regeneration plants that grow wildlife. We are planning to then add low density areas and crystal asteroids, then intelligent life with mining bases and settlements. Most of these objects will be player-controllable in-game. When the whole ecosystem is done, we will think about journeys through 4D space including the atmosphere and lithosphere layers.(the atmosphere layer will most likely be included early as it is essential to the ecosystem)

Gameplay concept.

2012-06-18T22:09:00.000+10:00

I think it's important to write down specifically what you want to create. Because in the long run it's surprisingly easy to forget what you were actually trying to do.

So, basically, the game we are trying to make should have something in the lines of:

-No grinding. We should try to avoid boring and overall numb activities. Gameplay should be dynamic and provide variety. If we manage to make a smart enough AI, there should be an option to assign most simple tasks to NPCs.

-Complex gameplay mechanics. It should not be in any way simple to master. Newtonian physics, air friction, resource management, a variety of tools and materials. A fully working ecosystem in-game would be great.

-An element of freshness and discovery. Reading wikis should not be mandatory. For a game to not feel like some tool with a manual, basic controls and elements should be simple and readily available at the start of the game. Figuring out how to use these tools should be a part of the experience, not a chore.

-Providing a tough challenge. For both tacticians and engineers. Travelling vast distances through the vacuum of space. Stealing resources from enemy factions. A heavy requirement for strategic thought should be in place, inexperienced players will not make it out of the starting area.

-No victory/loss/munchkin conditions. Amassing unimaginable power and crushing your foes with an iron fist is nice, but there is a lot more to games(and life) than silly win/lose situations. The main currency in the game should be knowledge of its mechanics, and an experienced player should be able to rebuild from zero in a matter of hours and evade any conflicts he doesn't consider necessary. Especially with players and NPCs that go out of their way for no other reason than to annoy someone.

Obviously, most of these points contradict each other and can go horribly, horribly wrong. We shall see.

Mesh editing!

2012-06-03T16:10:00.001+10:00

Finally, I've managed to write a fast enough algorithm to regenerate the mesh real-time. Woohoo! What that means is we basically have deformable landscape(or whatever that is on the screenshots - you can bite a piece out of it now, yay!)

Here are a few screens of me eating holes through stuff. Hopefully, Anry will tape a video soon. He's working on some awesome music tracks right now btw.

Testing physics

2012-03-24T19:57:00.002+11:00

Ok, the object physics is done. Mostly. Still have them clipping through each other at low speeds when too many contact points are checked. Anyway, it looks great in most cases except when the annoying camera starts going through solid objects. Have to remember to fix that.

Basically, we can finally start doing some gameplay coding now.

Collision

2012-03-06T07:31:00.002+11:00

Today I've finally got a decent collision for one slimeball. It flies around like an edgy green ping pong ball and collides with things quite adequately. Now to optimize the calculations and implement them for more complicated shapes! And not forget angular momentum this time.

It's nerdy physics time!

2012-02-21T07:50:00.002+11:00

Imagine collision for this thing. From scratch. Because you're too lazy to figure out how to make it work in PhysX or Havok. I've been having nightmares of bloodthirsty teddy bears from hell because of this!

On the plus side - there's quite some progress with the game's concept.

Adding detail

2012-02-06T08:03:00.002+11:00

Okay, we have something that resembles textures now. So I started to work on the generation code for plants. Or something similar. Whatever it is, it's supposed to grow so it needs a functional structure. So far, I've come up with a layout involving a core and something resembling huge deformed mushrooms growing from it.

Now, some polish on the shaders and textures could be nice, but I think it's going in the right direction. Hopefully, I'll finish the generator settings by the time Anry will have time to move area loading into a separate thread.

Textures!

2012-02-01T21:38:00.002+11:00

Somehow, I've managed to get the locations loading properly and decided that we need new textures as the old ones were kinda made in MS paint.

Looks... weird. But I like it.

A few months later

2012-01-28T07:18:00.002+11:00

So... After several months of playing Terraria and Borderlands(btw, Borderlands 2 is said to come out this year! sweeet!) I've finally found some time to sit down and start writing the code for loading/unloading locations.

I still ain't got a slightest clue on what the hell I am doing, but best not question it if it works. If I somehow manage to get seamless transitions between areas I'll... I don't know, really. What would a guy do with a universe full of huge creepy slimeballs and whatnot? Possibilities are endless I guess.

The first sound from the Shquarkz space

2011-11-01T16:10:00.002+11:00

Today I had spent some time with sound editors and created some sort of test example of the melody for the game. At the moment it's unfinished test version with cyclic melody with length about 4 minutes.

Progress

2011-10-28T20:15:00.002+11:00

While Anry is doing some Direct3D stuff and digging around in binary files, I decided to make some graphics for testing purposes. The asteroid generation algorithm seems to be working well, so I added some shaders and textures to see how it handles different block types. It lags, looks like hell, but, hey, it works! We got some green slimy things, a bunch of eye-thingys and... well... something else. I have no idea what it is. Yet.

Ok... So now I have to make an entire universe of this...

What we had some time ago

2011-10-28T02:38:00.003+11:00

We slightly changed the name of the game. Now it is called the "Shquarkz: Meatrified!" and I had designed the first version of it's logo. I have some time at the moment to tell you a little about the development history and show some related screenshots.

Shquarkz: Meatrified logo.

At the beginning we decided to create dedicated cells filled with asteroids which are combined of the atomic elements which are called blocks. We thought that it would be enough for the first time. So we've created three base classes - the "Cell" - a dedicated cubic 3d location in a space, the "Asteroid" - a chunk combined of smallest elements which could exist in the game universe, and the "Block" - exactly that smallest element. On practice this process wasn't so simple and we spent some time on coding, adjusting and optimizing our code. So we got some sort of basic geometry without graphics, not to speak of audio or physics engines.

After that we had started to develop algorithms for universe generation, so we thought about the graphics engine. It is required to see real objects not to mention their existance looking at the hexadecimal numbers in the debugger. We decided to use the OGRE graphics rendering engine, because I had used it before. As the visual part for blocks we used 3d models created in a 3d modeling software.


Simple 8-vertex cubes.	Jammed cubes as bone blocks.


Some experiments at the first stages.	Bones' blocks look like bones.

      As every other game that is in the development stage, the "Shquarkz" game is changing - we're adding new elements, adjusting gameplay and game objects design to get more or less finished image at a certain stage. That's because like a professional game developer could say: "you can't finish a game, you can only release it at a certain development stage". We are getting a lot of new ideas every day which are being filtered and screened and then being added or not added into the game. Anyway we aren't planning anything as development stages and we aren't using any project documentation at the moment. I can't say it's good, but it suits us. Every day we're creating new code or replacing old code pieces with new ones, more optimized and fast. We are searching, studying and using non-standard technologies such as fast dense hash-maps from Google, which perform operations 10-15 times faster than STL maps. We have replaced standard maps with Google maps lately and we got great speed boost during the world generation and saving (7 seconds instead of 20 using maximal asteroid size that is acceptable for OGRE).

      Now let's return to the development history. I want to note that all our cell geometry that is used in the project scene representation is integral and moreover we are using bit-arrays as a storage for the most of required data. A block has 64 bits, which are used for position (3 coordinates), type and flags. Flags are used to determine how the block should be processed. An asteroid also has 64 bits for all its data, and they include its position, orientation quaternion, its biome type and additional flags. 8-byte numbers which we're using to represent blocks and asteroids data allow us to save on a memory. It's RAM when we are creating objects or reading them from the file and it's hard drive space when we're saving our universe into files.

      The geometry system and world generation algorythms worked fast enough. But graphics part that used separate blocks didn't provide us good speed and asteroids size during the rendering process, because tens of thousands and even hundreds of thousands blocks were created at the same time. You can calculate easily that a dense asteroid (an asteroid without hollows) with a just 100 units radius contains much more than 4 millions separate blocks. OGRE and any other graphics engine and any modern CPU\GPU can't render so much triangles (about 48 millions for 6-sided cubes) with somewhat reasonable FPS.

      We improved the generation algorithm, to detect surface blocks and leave only them visible. Such step provided us with some rendering speed boost but it was not enough. We had experiments with the OGRE's static geometry, paging landscape manager, adjusting it for 3d objects and 3d space "pages". But nothing of that gave us expected and desired results. Then we had decided to use the procedural geometry. I had spent some time studying the OGRE's documentation, then I wrote new code (it was really bulky) that could create objects which you can see a bit lower.


The colored box that represents nothing but itself.	The simple smoothed colored box that represents a detached block.

After a while, procedural mesh generation has been done and a bit later we added textures.


The procedural asteroid.	The textured procedural asteroid.

Stay tuned for more news.

"Mad as a weasel" Jod

2011-10-28T01:22:00.002+11:00

Being tired of mainstream games of the 21st century not being so good(understatement, really), Jod has ventured into the obscure world of game modding and indie games, searching for what he can do on the matter.

Gone through 4 years of modding The Elder Scrolls, I've got a taste of what it actually takes to finish a project, got extensive testing experience, and gone quite mad. What else does one really need to be a game developer? I guess I'll find out one way or the other, as I got this crazy idea of making a game from duct tape, C++ and voices that haunt me in public transport.

"Savage Angel" Anry Narleyn

2011-09-25T09:23:00.000+10:00

     Time runs fast and life passes through bringing new thoughts and changing views. Something that was interesting some time ago became forgotten. The mind craves for new ideas, realized in games, but there are really not so much places where they can be found. It's pity. Another year and other "new" games are out - new graphics, physics, some realism. But there are no new ideas in all these shooters, RPGs and RTS and I'm asking myself the same question - are they all really new? I'm getting a demo of certain new game, installing it onto my computer, trying to play and I'm getting bored in few hours. Time after time the story is the same.

     Not so long ago I saw some great games. Quite simple, without these overdone graphic effects and animations, quests and pre-scribed storylines. Their inner systems allow player to create his own worlds and his own stories, bounded only by his imagination and certain laws. One of them allow player to create something great, others also allows communications between multiple players, offering imposible and unique stories each time when player starts new game. Playing such games is not boring for me, and while I'm playing such games I'm thinking about what can I create. These thoughts are accumulating in my mind, are maturing and becoming finished conceptions.

     It impels me to create something new by my own hands and my own mind. So it was great for me to have Jod as my partner, because when we have first told our ideas to each other, we have saw that we have similar view of games, and we decided to realize our ideas learning, thinking and walking among this road. Let us see what we will achieve.

     Below you can read some information on my game developing background if someone interested.

     I had decided to log my experience that I get by developing and designing games and performing some experiments so I had created this blog. At the moment I'm working at two projects, which are the Andoran: Prologue, well-known add-on for The Elder Scrolls game; and the Shquarkz project that is organic nanocosmic multiplayer game.

     When I was a schoolboy I learned BASIC programming language (on really ancient computers), wrote some simple programs, drew pictures and even created simple games. At that moment I had not my own computer.

Screenshot from the TES3: Morrowind game.

In 2002 The Elder Scrolls 3: Morrowind was released. I saw this game in the first time 17 May 2003, when I was in the 10 grade, and I was really impressed with its huge world, rich features, interesting gameplay and quests. Also I was absorbed with its Construction Set. I tried to create my own world, locations and gameplay elements. I started to learn 3ds max to be able to create new 3d models and animations. Then I got access to the Internet. There I saw the Russian TES community and entered one of the modders team that worked on the Kagrenak's Sons mod. We had released the demo version of the mod and then it was closed. So I started my own project called the Battles of the Legionnaire. My team made a great progress, there were cool locations and quests but we could not finished it, because of TES4: Oblivion release.

There are some screenshots from the old (2005) and new (2011) versions of the Battles of the Legionnaire mod.

2005


Solitude castle.	Barrel of honey tavern in Solitude.	Battle at the Northern Fort.	Solitude street.

2011


Sun rises above the Red Mountain.	Ascadian isles.	Duke Vedam Dren's office.

Next page in my history is the Russian TES4: Skyrim mod with its truely rich history of useless arguments and revolutions. Between the argues in the team I learned C# and C++ programming languages including such libraries as XNA, DirectX API, OGRE and PhysX.
When we had all troubles settled down and when we had screened all the problem members we received an invite from the Vikart, the leader of the Andoran team. Some time ago we had talk about amalgamation of our two teams to work together first on the Andoran project and then on our Skyrim project. But as you can see, Bethesda Softworks had been developed TES5: Skyrim since TES4: Oblivion release date. So our Skyrim's design groundwork, sketches and artwork were used in the Andoran. Here are some of them.


Falmers underground valley map by Auran.	A northern bay by Alius.	The nords' temple by Alius.	Dawnstar city art by Alius.