Jump to content

  • Log In with Google      Sign In   
  • Create Account






First Entry - What I'm doing

Posted by MiniMigi, 04 July 2014 · 305 views

what how why first post cdk cuboid engine space hi
First Entry - What I'm doing Hi fellow GameDev's!

This will be my first journal entry, and my last ( nah, it wont be ), so throughout this journal I'll hopefully post the most interesting developments in my engine or my game.

Just so you're warned, I have absolutely 0 experience in how to write these journal entries, so either it's boring or worth reading right now. And there's no screenshots of anything since I'm not near my pc for a few weeks.

So, my real beauty is my engine, which I have put a lot of work into, although development is going rather slow due to obstacles ( school, etc... ). I like to call her Cuboid Engine, the reason for this name is because the first accomplishment I made was the rendering of a brilliant simple 3d cube ( And the code wasnt even mine! ). From there on I continued to add onto the sample code and encapsulated everything into classes, and things went fast from there. Although after a while, I saw that my code base was messy as hell, so after a good while, I decided to re-do everything, which surprisingly took about 2 weeks ( with the obstacles... ), and the final product was much faster, nicer and cleaner. The part about the engine that I'm very satisfied with is its ability to be very general, in the sence that it doesn't serve a strict purposes, although it's mainly a game engine (Although I like to put the focus on the rendering).

When coding, my greatest fear/problem is making classes as general as possible, allowing me to re-use them later on, sadly sometimes this isn't as easy as it sounds.

Something that I learnt the hard way was that I like to start something and then quit very early on, but I finally think I got something that can keep me occupied, a game of mine in development, called Cuboid Space using my slowly developing engine. The game is block based (No, its not another Minecraft copy), the envoirernment is located in space. The actual plot is not made up, and the development is still very early, all you're left with is a platform and some base materials/blocks that you can place.

The game is very modding friendly, both for modders and the developers, this is due to the structure of the game: ( MS Paint FTW )

Posted Image

So basically Game uses the Singleton DLL Interface (Yeah, Singletons are bad, I know...), now the job of Interface is to keep track of all Blocks registered ( the register basically tells the Game that "this" block exists ), and to hold the pointers to the engine (Rendering, Physics, Sound, etc...) so that the Blocks can access these components, since I do not want the Blocks to be able to access the Game. The way I made the Interface aware of the Blocks was by employing a little hackish solution:

( I dont have the sources at the moment since I'm away from the main PC for a while, so this is from my memory )
struct ObjectRegister
{
ObjectRegister(Object* (*c)(), cex::CEString &s) 
: _call(c), name(s)
{
}

Object* (*_call)();
cex::CEString name;
};

class _BASEAPI Interface
{
private:
std::vector<ObjectRegister*> g_vRegister;

public:
// Material Manager
MaterialManager *pMaterials;

// Texture Manager
TextureManager *pTextures;

// Sound Engine
cex::CESoundCore *pSound;

// Engine
cex::CEEngineCore *pEngine;

// Create the interface
void Create(cex::CEEngineCore *p, cex::CESoundCore *ps);

// Get Object Register
ObjectRegister* GetObjectRegister(cex::CEString &p);

// Global Object Register Function
bool Register(Object* (*in)(), cex::CEString &Name);

// Get Singleton
static Interface* Instance();
};
As you see there, the Blocks themselves are responsible to call Register(...). Now this is where it gets messy and tricky, so I chose to make it easy for the block to register itself like this:

The header file of "a" block
#pragma once

#include "Blocks.h"

// Declare Auto Register Module
BLOCKS_ARMODULE(Metal);

// Metal Class
BLOCKS_START(Metal)
{
public:
// Create Object
void Create(Interface *pInteface);

// Update Object
void Update(Interface *pInteface);

// On Signal
void OnSignal(Interface *pInterface, int signal);
};
BLOCKS_END
The source file of "a" block:
#include "stdafx.h"
#include "CMetal.h"

// Namespace
BLOCKS_USE;

// Run Auto Register Module Constructor, identifier "Metal"
BLOCKS_ARRUN(Metal, "Metal");

void Blocks::Metal::Create(Interface *pInteface)
{
// Set Texture Metal
SetTexture(pInteface, "metal01_small.jpg");
SetNormalMap(pInteface, "metal01_small_NORM.tga");
SetMaterial(pInteface, "texture_norm.cs");
}

void Blocks::Metal::Update(Interface *pInteface)
{

}

void Blocks::Metal::OnSignal(Interface *pInterface, int signal)
{

}
So basically the auto register module is a class with a constructor which is instantiated inside the source file, now since this is a DLL, when loading this DLL file the constructors will get called and the blocks will get registered.

Is this messy? Indeed!
  • Singletons (Check!)
  • Global Instantiated Classes (Check!)
Will it change? Yes, but it works great!

And then finally in the Game, it creates the Interface class, and then loads the Blocks DLL to register all Blocks. Then when the user selects a new block the game simply finds the block by name, like: _pBlock = pInterface.GetObjectRegister("metal"); Although the searching method will also change. So basically everything will change, eventually...

Now the physics part, the idea of blocks made the management way easier. The way I manage my blocks is with two classes, BlockGroup and Block, each single block is attached to a group, and the actual position of a block is always in local space with respect to the group position (This makes it very easy to find blocks close to other blocks, like sending a power signal to a neighbour block ). Now the group is the living thing, so when rendering each single block is transformed by the transformation of the group to create the movement. Each single time a new block is placed, it is assigned to a group, the group is found by finding the block that the user has clicked on, since each block holds a pointer to the group. Then the physics library receives an updated shape of the group, and the same happens when a block is removed.

Enough chit-chat.

So this was basically a start to my journal, hopefully I'll continue to add entries with developments. ( And screenshots )

A bit of personal information, currently I haven't had much time for further development, since my brother has to share his pc ( which happens rarely, though I assembled it ), since mine died. And by the obstacles I'm talking mainly about the school, since it's putting a whole lot of pressure on us. And currently I'm on a vacation with my family, then I'll get one week of break, then onto a school related travel, and then one week left of the summer holidays. So it's not the holiday I had hoped for, since all I asked for was some time to relax and, well, code on Posted Image.

Although, you'll have to take my word for this, the engine is much more organized and cleaner than this system, as this almost fits for a coding horror! Posted Image

The fact that you even reached the bottom is amazing! Thanks for your time!




Welcome to Journal-land

Welcome!  :)

Thank you all :)

July 2014 »

S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728 29 3031  

Recent Entries

Recent Comments

PARTNERS