Game Project – Orthographic Material

20160111-20160117:

After taking some time off, I just wanted to setup an orthographic 3D camera to get the same isometric view that I´m working with in 2D.

First I needed to rotate the camera 54.736° around the X-axis or “Pitch” so that the camera would “look down”. Then I could rotate my objects 45° around the Z-axis or “Yaw” and the isometric angle for the camera would be ready.

Now I could render isometric images from 3D-objects, but in my 2D view I´m using a near-isometric view with a 2:1 pixel ratio.
These “true” isometric images would have a slightly different angle along the edges and not the same pixel ratio.

Will go through this more later…

Game Project – 3D Modeling (Clusters)

20151214-20151220: 3D Modeling, Cell-clusters

Started to model clusters instead of single cells.
I am planning to create images from these models to use in the 2D-view later, and by using a fixed amount of cells on each floor, it will be more about adding cell-clusters on different levels in a building. Buildings with cells will have a fixed width & depth too and maybe I will add bridges between buildings so that elevators won´t be so crowded.

Game Project – Near-Isometric Projection

20151123-20151129:

Deeper analyzes about isometric projection, which angles and height I wanted to work with before creating images. The “true” isometric projection with 120° between each axis had the “look” that I wanted (instead of the “military perspective”), but as in a lot of other games I went for the 2:1 dimetric projection instead because of the relations between width and height.

20151130-20151213: Implementing the near-isometric projection view.

The conversion to canvas coordinates will now be altered as I´ve illustrated in this picture.
The dotted square represents a 1x1x1 Cube seen from above. When rotating it 45° around a surrounding circle (red dotted square), the width and depth of the cube on screen will grow to the distance between its corners (using Pythagorean theorem) or diameter of the surrounding circle (1*d). By dividing the rotated Z points with this distance, the depth will shrink to 1 again (1*d/d). And by multiplying the rotated X points with this distance, the width will grow to 2 (1*d*d) since the distance is the square root of 2. In this way, I don´t need to do further calculations with Y and the rotated view will have a 2:1 relation as the lined red cube.

I´ve tested my formula on rotations in world-space and then in object-space and it works for me. Now I can create images to represent a displayed 1x1x1 area like the cube in my illustration and be able to use it anywhere in the world.

Earlier I tried to divide the rotated Z with 2 and Y with the distance to have this 2:1 relation, but this led to more calculations everywhere in the code. So when I redesigned the rotation with this, things got easier to read and work with.

Game Project – 2D / 2.5D

20151102-20151108: Rotation

This week I started to think about how to display buildings with height in the 2D-view. When the x-axis was horizontal and z-axis vertical on the screen, I didn´t want to have the y-axis vertical or combined. So I decided to rotate x and z 45 degrees and then have only the y-axis vertical (as in games like StarCraft, SimCity etc.).

First I did some tests at the place in my code where coordinates are converted to canvas dimensions to get a working rotation. I also tried to rotate the drawing object (ctx context) prior to drawing, but this made things more complicated later in code so I kept working with conversion of coordinates.

Then I added drawing of walls for buildings, vertical offset when Y is higher than ground and some tests with drawing of cells in general.

Game Project – Synchronizing

20151026-20151030: Node.js

Last week I started reading about node.js while searching for multiplayer-solutions:
http://gamedev.stackexchange.com/a/60440/73841

I wanted to try faster alternatives to MySQL for real-time updates about every objects position. After setting up a server and writing a smaller server-side-version JavaScript, I´ve decided to import needed code from the project through an http-call. In that way I didn´t need to copy the whole project and keep changes synchronized across both versions.

So this is my setup:
“TheNest.Server” is defined in the server and listens for incoming connections. When TheNest.Server starts, it will load objects from the MySQL-database and import world-functions and brain-prototypes. Then it will run a game-loop and send back data that is being requested. (like objects positions)
“TheNest.Data.SyncClient” is defined in the browser and will try to establish and keep a connection to the server. When a connection exists, the browser will run a sync-function at regular intervals to update objects positions. If any changes are made from a browser, (like setting a destination for an object) the changes will be sent to the server.

I think this is working fast now (20 sync/second with only about 1% notice on CPU), especially after making some filters (only update objects in view and selected properties like “x,y,z”).
Maybe I will go back to using only MySQL later anyway since I´m not sure if I want to run a server. In the MySQL-case, I would probably not use 20 sync/second but instead use some status-pushing and guessing between updates.

When the server is down, the game-loop in browser will call the world-brain-function instead of synchronizing.

20151031-20151101: MySQL

I went back to synchronizing with MySQL since I want the project to be up and running even if my computer is off. This also means that I don´t need to pay as much attention to security as if I were to expose another server to the Internet, but with a drawback in performance that I will try to work around.
The first thing I improved was the updating. I made a batch-update query by using aliases on the same table like in this answer on StackOverflow (instead of sending a query through an http-request for each object to update): http://stackoverflow.com/a/3439/4181348

Later I will need to add things to keep multiple browsers/views working together instead of overwriting each other’s changes. For now, a save in intervals will do fine.

Game Project – Restructuring

20151020: Structure of The Nest

I have collected all parts of the project and defined them as sub-objects to my main object “TheNest”. So when calling the world-method to draw, “TheNest.World.CtxDraw()” is used, and the loading of data uses “TheNest.Data.Load()”. This makes it easier to add and remove functionality without getting errors of undefined objects since “TheNest” is always defined and it´s properties/methods will return false if they don´t exists.

While working on the AI part, I decided to reorganize the “Brains”.
My idea of The Nest as a world would define it as a “living” thing where everything inside it is made of and connected to it. The creatures are born only to do some part of work which they are programmed to do, and when they eventually don’t perform enough they are recycled to make place for new creatures.
I try to keep this in mind while choosing where to put abilities.
So when I looked into the game-loop, I found it more appropriate to have a “Tracker” operated by the world-brain instead of letting every creature use their “Orientation”.

TheNest.World will handle all the drawing/rendering, the new gravity, collision detection, status checking, requests for a free lair and things like that. This will be the largest object.

TheNest.Objects will hold all currently loaded objects and definitions of types. (Simulated Enums to check against, like this “object.type==Types.Creature” for better readability instead of this “object.type==1”) and some defaults when creating new objects.

TheNest.Meshes will create, remove, construct, load and update everything that involves 3D-objects as an addon.

TheNest.Brains will hold prototypes for all AI (world-brain included). A “TheNest.Brains.Creature” is added to every loaded creature and is given a “pulse” in every game-loop (their main function get called) so that they can do their tasks like moving/working/sleeping. Without this part, nothing would be happening besides interactions from the user.

Then there is Data, Camera, Console, Pointer & Editor as usual.

20151021: Redesigning Editor (Again)

After editing the console to take up more space, I needed to redesign the editor too.

20151022: Node.js

Started reading about node.js while searching for multiplayer-solutions. Will write more about this later.

Game Project – First Person View Controls

20151012-20151013: First Person Camera Controls

Added support for looking around with pointer and move like in a FPS-game.

Keyboard: WASD/Arrow-keys move the camera forward/back/left/right.
Mouse: When this camera-mode is turned on, pointer position delta will turn the camera around.
Touchscreen: A press in the center of the screen will move the camera forward while dragging/swipe will turn the camera around.

Features I will improve later:
* Mouse: A pointer-lock to enable endless movement with the mouse without pointer going out of the window.

20151014: Targets

I´ve optimized target-finding by replacing old messy code at which world-coordinates and display-coordinates were calculated back and forth just because the code had been moved from different places while writing. (Object > Display > Pointer > Object). Various arrangements.

20151015-20151018: Console

The console is updated and the §-key will toggle it´s visibility (like in the early versions of Quake that I played around 17 years ago).
It will take up 50% of the canvas height and I added a few commands:

GOHOME: Make the selected creature go to its lair.
FINDLAIR: Will attach a free lair to the selected creature, if there is any.
FINDME: Focus the camera at the selected object.
+ Some commands that’s already represented with editor-buttons like “KILLME”, “SPAWN”, “BUILD”.

Create your website with WordPress.com
Get started