Game Design Article

I've recently written an article for For Devs By Devs. Check it out on their website.

Summer break's almost over.

You haven't heard from me in a while. This is because I have hardly been working on Clockwork Wanderlust over the summer, but work will start again soon.

I've been looking into OpenGL to get more performance and more efficiency. I will post my findings soon.
In the meantime, OpenGL is opening the road towards proper shading of used textures. Tiles will look red in the sunset and blueish during the night. Got to add that to my list of planned features, actually.

I've had the "game" so far tested by a few people, and they were complaining the rotation of the camera leads to eyestrain. Therefore I am going to decrease the resolution from 16x16 to 8x8.

Everything is coming along nicely so far, and hopefully I can soon start on coding the game itself rather than the rendering.

Hope you're all well,
- Gamesaucer.

Quick update on Java port

I'm getting there, and since I already have all the functions I need to draw things (I just need to port them) I don't really expect any trouble.

Fully fake-3D rendered 3D world.

I'm pretty happy that I can report some more progress:

However, I am running into performance issues that I cannot properly address as long as I am using Game Maker.

The trouble is, I need to do a lot of math in Game Maker, whereas in Java I only need a few lines of code.

So I'll be busy getting the exact same thing to work in Java right now and then I'll be continuing from that.

Demo

Explanation of isometric mechanics.

Quick explanation of how I drew the dotted grid last post.


xlocation = ((xi-xorigin)*cos(degtorad(rotation))-(yi-yorigin) *sin(degtorad(rotation)))*blocksize+room_width/2;

ylocation = ((yi-yorigin)*cos(degtorad(rotation))+(xi-xorigin) *sin(degtorad(rotation)))*blocksize/2+room_height/2;

Wow, that seems quite complicated. Let's dissect this.

Remember we had a little array going?

the indexes are displayed along the axes.

Blue is the X-axis, yellow the Y-axis.
The origin is the point the grid will be rotating around. It is, in fact, the position of the player on the grid.
It has an X and Y value too. Here, both xorigin and yorigin are 1,5.

The location to draw a tile in is calculated for each tile.
That leads us to the nature of our loop straight away: a FOR-loop.
FOR-loops work with indexes, and that's exactly what xi and yi are.

then we have some vars that are meant to display it properly:
blocksize is the size of the displayed blocks, or rather, the blocks that would have been displayed if I had finished the drawing of primitives for this build. If I didn't use it, each block would be 1 pixel wide and half a pixel tall.
room_width and room_height are built-in variables to get the size of the 'room'. For now, that's simply the screen size.
rotation is the current rotation around the character.

We want to draw the origin exactly at the center of the screen, because we are following the game character, LAG.

As you can see here, if we draw LAG at the origin that is calculated, he will stand invariably in the middle.

Whereas the origin on the grid was at x1.5 y1.5, the origin on the screen is displayed at x(rW/2) y(rH/2).

If we now dissect the original formula:

(xi-xorigin) is the location of the tile to be drawn relative to LAG, our character.

Therefore we could say: {xRelative = (xi-xorigin);}

The same goes for the Y location: {yRelative = (yi-yorigin);}

If we do the same for the calculations needed to display the tiles properly, we get:

{xDisplay = blocksize+room_width/2;}

{yDisplay = blocksize/2+room_height/2;}

And finally we can take care of the rotation:

{cosOfRot = cos(degtorad(rotation));}

{sinOfRot = sin(degtorad(rotation));}

If we now fill this into the function it looks easier.

xlocation = (xRelative*cosOfRot-yRelative*sinOfRot)*xDisplay;
ylocation = (yRelative*cosOfRot+xRelative*sinOfRot)*yDisplay;

As you can see, the part between the parentheses is simply Matrix algebra.
I don't exactly know how that works, but I might update you on that later if I can find the time.

Build 2: Full rotation

Isometric? Check.
Fully rotatable over 360 degrees? Check.
Character movement? Check.

I think it's about time to call Indev version 0.02.
You may notice that the tile textures are gone, but that's because I'm still switching to primitives for drawing them.
But that's going to be in Indev version 0.03.

Implementing theory into the game

Sorry that it's taking a while, I am busier than expected with other projects.
However, that does not stop me from making progress with this one:

Still need to transform the tiles themselves, but I'm getting there.

Vertexes demo

Well, I got the drawing itself sorted out, as you can see:

It behaved exactly as I wanted it to behave, so minimum effort on this part.
The hard part now is calculating the grid nodes to draw the texture at.

Quick break

No, I'm not dead.
I was very busy last week so I didn't get to work on  Clockwork Wanderlust.
I used the weekend to take a bit of a break to recover some energy, and I think I can continue work this week.

New team member

We're adding "eurooma" to the testers.

There's not much to test right now, but as soon as version 0.1 is done I'll start needing them.

Linkthrough

I found a nice blog which focuses on Game Maker.

I use Game Maker to build my prototypes in because it is so fast and easy to use.
The syntax is very similar to Java's syntax, so I can copy over my code for the most part, I'll only have to re-optimize it.

If you are interested in Game Maker, do check out this blog.

Isometric view: Solution?

It occurred to me that, if normally the square on which the texture is drawn can't be transformed properly, why couldn't I simply make a primitive?

So I'll research using primitives for my isometric view now.
Here's what I understand so far:

(Fixed as of May 27.)

Notice the 2 triangles (ABD) and (BCD) the primitive gets split up in.
This way it is easy for the computer to draw the shapes.

Now I can have my texture:

And map the texture to the primitive as follows:
(WA), (XB), (YC), (ZD)

Can you imagine a field full of those?
This is how it looks:

Not bad at all. The texture is a bit blurred, but I will scale it down in the final game instead of making it larger, which will reduce the blur but hopefully retain the feel of the texture.

But all we have now is still a grassy plain, without any hills whatsoever - I'll have to add an extra dimension to my array soon, and recalculate the drawing height. Wish me luck.

Isometric tutorial

During my quest to research isometric views that can rotate, I found this:

It's very clear and understandable, and describes almost exactly what I mean, drastically reducing the research that I still have to do.

Build 1: Testing the isometric grid & explanation

So I managed to get some plain isometric game mechanics going.

This is just a quick tech demo, nothing extraordinary, but I plan on using the mechanics in the final game.
(which will be cross-platform btw, since I noticed there is one guy with linux viewing this blog as well. Blame Google's statistics.)

Meet L.A.G (Long Arms Guy).

It is a quick and ugly stick figure, but it's great for quick testing, since only enough effort to make things clear needs to go into the game.

LAG can move in eight directions on the grid of isometric tiles.
(The tiles themselves are isometric. I am still looking for a way to render square tiles transformed properly)

The fun thing is, if you try and control the prototype, the floor seems to move and LAG seems to stand still.
That's kind of right as well. The tiles move on screen, whereas LAG stays invariably in the center.

Now here's what's special: LAG is actually moving along a grid of square tiles, in the normal eight directions, whereas he seems to be moving along the isometric eight directions.

Here's the difference to illustrate my point:

And the grid is not even really a grid - it's merely an array of values, filled with "1"s to indicate grass:
[1][1]
[1][1]

So in fact, LAG is not moving along an isometric grid, but along indices in an array.
And still, it's displayed on the screen like it's walking through a proper (if a bit abstract) 3d world, all in less than 30 minutes of work.

As you can see, the development of the mechanics is going smooth.

Isometric view

I'm running into some trouble when making the isometric view.
I'll try to explain my problem.

I have an original image. It's a square 32x32 tile.
I want to rotate it and scale it down vertically for it to be able to fit into the isometric grid.
I want to keep rotating it under different angles before scaling, because I want to smooth 360 degrees turn.

The top example is what I want to happen.
The bottom example is what happens in every tool I tried out so far.

I cannot add transformations to the graphic seperately.
Scaling seems to be prioritized over rotation by default, and I have no idea how to chnage this behaviour.

I'm of course working on a solution, but what I'm trying to achieve here is way more default to process for a computer than having to render an actual 3d view.

I will resort to 3d if I cannot find a way to change this, but either way, the results will not be seen in the final game. Unless you have a slow computer.

Clockwork Wanderlust

Welcome to this blog.
It is about a game in development called "Clockwork Wanderlust".

It's a survival RPG sandbox.
Sandbox because everything is destructible and creatable.
RPG because of involved skills and NPC interaction.
Survival because of player restictions.

The game is going to be isometric and it will provide a nearly endless world, the size of the world only being limited to the size of your hard disk.

Current team:
"Gamesaucer", lead developer

"Xemhinor" and "Scheurneus", test panel.

I'll keep you informed.