Switch to the Czech version

Monday, 23 January 2012

Alecraft :: progress report 5

New features just keep on coming. Here are some screenshots so you don't feel left out :-)

1. Sitting by the river.

2. Getting scared in the evening.

3. Feeling better in the morning.

To sum up the changes:
- created a water simulation system. It is dynamic and tile-based.
- activated a day / night cycle.
- light now changes during the day.
- added a sky simulation that changes during the day.

Thursday, 19 January 2012

Diamond in Java 7

After writing this kind of line of code...

Box<Integer> integerBox = new Box<Integer>();


...my all-knowing IDE (NetBeans) has suggested that I use the diamond operator. What is that? Good question. Apparently this is one of the new features in Java 7. If the compiler can infer the type arguments, you can leave the brackets empty, i.e. use a diamond. The code then looks like this...

Box<Integer> integerBox = new Box<>();

...which is a bit better, because I always hated having to type the same arguments on two places (on a single line). Nice one, Java!

More on this: docs.oracle.com - generics tutorial
Also, this is why we don't just drop the diamond all together: stackoverflow.com thread

Alecraft :: Alpha version 1.0.0 released!

BOOM! Ka-POW!
 ... and here it is.

I have updated the Alecraft homepage, now there is a link to start the new version 1.0.0 via Java Web Start. If you liked the old game (we all did!), don't worry. It is still there, the links are still the same. If you want to reach them through the main page, you just have to use the "Old Alecraft homepage" link.

So what is in the newer version? To be honest, a lot is missing compared to the previous one. There are no battles, no crafting, no main goal, ... it is just a block-building game so far. But don't worry. This new engine gives us new and exciting possibilities. I will slowly start enhancing it and hopefully bring it back to its previous function-filled glory.

The game controls are as follows:
WASD / arrows - movement
C / left mouse button - attack, destroys a block in the current direction
X / right mouse button - menu, places a wooden block
Mouse left & right - rotates the camera around the avatar
Mouse up & down - changes the viewing angle
Mouse wheel - changes the viewing distance

And that is it. Tell me what you think. Feedback is appreciated.

Oh! And one more thing...just be safe, don't fall over the edge of the world :-)

Tuesday, 17 January 2012

Alecraft :: alpha release? nope

Thought I would release an alpha version of Alecraft today. Well, I was wrong. After a few hours of fiddling with it I still can't get the Web Start version or the applet version to work (each ends with a different kind of exception). Web Start can't find some Nifty GUI class, applet has some problem with signing digest. Only the native Windows / Linux / MacOS versions work. Oh well, gotta try tomorrow...

Update 18.01.2012:
I managed to fix the Web Start bug. It can be started from the web. BUT it is unplayable. It is somehow hogging all the memory and the CPU overloads for a short time every second. No idea why.
The native version (*.exe for Windows) works a lot better, but it could still use some polishing.
One more thing: Java? ... I hate you!

Update 18.01.2012  #2:
A breakthrough! The problem was I've got both JRE 1.6 and JRE 1.7. While debugging the code I used 1.7 and after trying to run the game as a regular user, it ran in JRE 1.6. Who could have known that Java 1.6 had such a crappy JVM, right?
It was probably caused by the garbage collector - it periodically stalled the whole app and it had a gigantic memory footprint (about 1.6 GB). I better look into this a bit more, but the alpha release could be here any day now.

Alecraft :: optimizations

Funny thing, this "optimization". The project development looks kind of like this:
  1. A great idea for a new feature comes up.
  2. I start adding the feature, the FPS drops down rapidly. It becomes unplayable.
  3. This sends me out on a crusade to optimize the code, FPS returns to the original playable range.
  4. I go back to the first step having enhanced the code with no real FPS loss.
To make this article a more technical one, lets take a look at some examples I encountered and would like to share:

Large cube world
Situation: the world is built from thousands of cubes.
Problem: this means thousands of triangles to be rendered. Most of them are not even visible.
Solution: render only the visible polygons. It is quite an obvious answer, but the real question is - how do I know which of them are visible?
Part of the problem is solved by jME3 (the game engine). It knows which objects are inside the camera viewing frustum and it ignores the rest.
The second part (which has to be handled by the game itself) is how to handle large amount of cube blocks, which block each other from the view. For example: if there is a large mountain, all you can see is its surface. No need to show what is inside the mountain. You have to mine it to get there first. And this is how it has to be done here as well.
My solution was to make each cube block "look around", find if it is completely surrounded by other cube blocks and if so, it would just sit there, not rendering a thing. This can be extended to render only the sides of the cube which are not hidden by a neighbour-cube. In the end this results in a nice "wrapper" of every compact mass of blocks.

Mesh batching
Situation: the scene consists of lots of small objects - cubes, trees, ...
Problem: graphics cards hate to deal with a lot of different objects. They are all right with rendering tons of triangles, but they all have to be of the same type.
Solution: batch the objects together, join the meshes into a few large objects.
This helps quite a lot, the graphics card can easily render large scenes when the meshes are joined together. On the other hand, if we join everything together it is not possible to skip the rendering of parts of the scene which are not visible. This again brings FPS drops. It is also not possible to selectively hide only parts of the scene.
My solution was to partition the scene by levels (layers of tiles based on the height) and then subdivide them into a grid. This gives me a smaller number of larger objects while allowing me to work only with the visible portion of the scene.
Again jME3 was a great help here, it comes with a scene node optimizer. I had to alter it slightly, because it changes the original meshes, which is not suitable for me. I maintain the original meshes (and do not render them), every "back-end" part (tile, etc.) changes the original node data. These are then optimized (copied and altered), put to the scene and rendered. After another change they are simply discarded and replaced by a newer optimized version.
The only remaining question is to find the perfect granularity of the scene. But this can be easily tweaked by changing a single number setting.


Changing mesh batches
Situation: the world is a changing environment, every now and then there is a new patch of grass, someone digs out a piece of dirt, ...
Problem: mesh batching is a complicated and time-consuming process and cannot be done every time something changes.
Solution: optimize only the nearest visible parts of the scene.
This one occurred to me when I finished some batching optimizations and turned the growing-grass feature back on. The game dropped to 0-1 FPS. No wonder - it had to recreate the meshes for most of the scene almost every single frame.
The first thing I tried was introducing the "how long has this region been dirty?" information. Using this I managed to lower the number of mesh rebuilding, because there was a timeout before every rebuild. The problem was this resulted in a really slowly changing environment, player had to wait a few moments for the scene to adapt to any changes.
What helped even more was when the rebuilding process started ignoring distant regions. If it cannot be seen clearly by the player it does not need to be updated (at all). I also added a condition which disqualified regions outside of the camera view frustum. Again, if it is not currently visible, just ignore it.
In the end the result is that any changes to the environment are handled only if the player can see them, otherwise it is pointless.

Sunday, 15 January 2012

Alecraft :: progress report 4

The entrance to my new mine. Lets get digging!

Just a quick info about my current project status:
- added mouse controls - the camera can now fly around the dwarf + the direction of walking is now relative to the viewer.
- basic wooden-wall building implemented.

Alecraft :: 3D perspective

Just goofing around with the 3D perspective...

More 3D-like. I will probably use this.

Whoa! The acid is kicking in! :-)

Alecraft :: progress report 3

Here are some newer screenshots:

Out above the ground....

Building an underground complex...

So what's new?
- the tiles can be mined-out to go deeper and deeper below the ground.
- camera :: automatic layer removal - tile layers are automatically hidden based on the location of the avatar (so you can see him).
- new 3D trees (although I still don't like them)
- some optimizations - blocks of map are batched together and rendered as one mesh.

Thursday, 12 January 2012

Smilies on Blogspot

I hoped that there would be some simple way to add smilies to Blogspot. Well, there is not. No widget or anything you could activate from the administration.
But, that shall not hold me back :-) . I actually found some tutorials on how to achieve this using JavaScript - just include this *.js, add some code here and voila, there you go. The problem was that these codes no longer work. It needed some tinkering with JS and CSS to get it going, but I now have smilies on all of my blogs. Furthermore, everything is managed centrally. That is - from one JS script.

Just a quick walkthrough (so I can use it in the future ;-) ):
1. Prepare the *.js script and post it somewhere accessible: 2. Fix the smiley image style in the "Custom CSS" section of template editor: 3. Include this just before the closing body HTML tag to activate the script:
(Don't forget to change the %%%SERVER_LINK%%% to something meaningful.)

Done.

Alecraft :: progress report 2

I've been playing around with Blender. It is indeed a professional-grade 3D rendering tool. If you learn how to use it, that is. It has a rather newbie-killing kind of controls, but once you learn a few basic things it lets you do wonderful graphics.
But lets not get distracted. The thing I wanted to share was this Alecraft logo preview:

It's not much, but the possibility to use the same models I use in the actual game was tempting. And this image came out. Hopefully it could replace the original retro logo:

The contrast between these two images nicely shows how different the two versions of the game are :-)


Update 12.01.2012: A bit better version of the logo.

Alecraft :: progress report 1

Great news from the land of Alecraft! We have spotted some progress, here are the photos we managed to obtain. What can we see here...

This dwarf looks pretty pissed. Well, don't blame him. He is stuck on this piece of rock with no ale!
This looks a bit better! He is enjoying his daily walk...
There is also this bird's-perspective kind of view available...
Just to comment it a bit more:
- maps are now fully 3D, consisting of layers of grass / dirt / stone etc. You can go freely up and down the hills, jump around, ...
- the main character is a 3D model (no animations so far, it is not my priority right now)
- added some fog to make everything look darker and to make the horizon disappear
- maps are randomly generated with geological layers simulation (the deeper you go the harder rocks can be found). This will be used for mining.
- you can change the angle in which the camera is looking at the player
- it took a lot of optimizations...and it is still not perfect.

That is all for now. Stay tuned!

Saturday, 7 January 2012

Alecraft in JME3

jMonkeyEngine (JME) is a great thing! I have recently found out about this SDK while searching for some tools to build my new game (Alecraft). And I must say - it is a great set of tools! And a wide community support, which is always a must-have.

I have been keeping busy these last few days. In fact I can't keep my hands from this project. It is starting to look quite promising. Here are some sneak-peek pre-alpha screenshots from the new Alecraft:


The graphics (tiles) are just for testing purposes, they are likely to change.

Update 08.01.2012: Better menu!

Wednesday, 4 January 2012

The king is dead. Long live the king!

As I read my Twitter feed, I stumbled upon this series of messages by @notch:
(for those who don't know him - this is Markus Persson, the author of Minecraft and Minicraft)

Minicraft, my Ludum Dare game, is not Open Source. It has the source available because of LD rules, but there is no license.
Feel free to play around with it, but if you want to use if commercially, you need to talk to us at Mojang first.
You also can't re-release the code as open source. So those github things are technically not legal. ;)
As I am one of those people hacking around with the code of Minicraft (not to mention that its repository is on Github), this information concerns me. Officially, what I am working on is pretty much illegal. Notch probably won't do anything about this (he said that unofficially he doesn't care what we do), but that doesn't mean everything is all right.
Because of this I am forced to cease my work on Alecraft as a Minicraft mod. I reject to work on something that I couldn't officially call my own creation.

Nevertheless, I have put too much time and lines of code into Alecraft, so this is not the end of it! I have already started a new game based on the LWJGL engine and I have ported some of the code I have created previously. The graphics and sounds had to be dropped and replaced. But what came out as a result is a totally new and independent game. It borrows ideas from Dwarf Fortress, Minicraft and others. I call it - Alecraft! ... What? The same name as before? Yes! The name is mine and I like it. Get over it.

Alecraft is dead. Long live the new Alecraft!

Monday, 2 January 2012

Alecraft in OpenGL available

I have released the first testing version of Alecraft in OpenGL. It is available via the main Alecraft page or using this direct link:

Sunday, 1 January 2012

Alecraft in OpenGL

I am currently working on an upgrade of the graphical engine used in Alecraft (my Minicraft mod).
The original version simply copied pixels to and from byte arrays and then copied the result to the main window. This is somewhat limiting - the number of available colors is small, everything has to fit into a grid of few times few pixels, also the performance is penalized by this approach.
I changed the engine of the game (surprisingly it wasn't that hard, Minicraft is pretty well written), so now it is using OpenGL. Not that this game needs any 3D graphics, but because it can only lead to a more powerful engine. Everything is naturally backwards compatible, meaning the game could look totally the same, if I wanted to. And as you can see from the screenshot, not much has changed. Currently only the fog-of-war took advantage of the new technology. It looks a bit more natural while keeping its old-school low-res look.


I might add some special effects or more 3D-ish elements into the game in the future, who knows. But I prefer this simple rogue-like style, so the change shouldn't be that drastic.