Jump to content

  • Log In with Google      Sign In   
  • Create Account

Helixirr

Member Since 27 Jan 2013
Offline Last Active May 07 2013 02:46 AM

Topics I've Started

How could one implement voxel-based level editor for a game?

09 April 2013 - 03:05 PM

Hi! smile.png

 

While searching for good ways to implement level editor to my game, I bumped into voxels as a good alternative. As far as I know, they are three-dimensional representations of pixels. They're not necessarily cubic, they can be, but not necessarily. Together they form a game world and it's up to renderer to decide how voxels are rendered. Please correct me if I'm wrong. wink.png

 

Now, based on this, I came to think of one possible voxel-based editor implementation. Here's the class definition (in C++):

class Voxel{
public:

    /// Constructors & destructors:
    Voxel(void) = default;
    Voxel(Voxel const& voxel_) = default;
    Voxel(Voxel&& voxel_) = default;

    /// Member functions:
    inline Material const& material(void) const;
    Voxel& material(Material const& material_);
    Voxel& material(Material&& material_);
    inline bool const& visible(void) const;
    Voxel& visible(bool const& visible_);
    Voxel& visible(bool&& visible_);

    /// Member functions (overloaded operators, assignment):
    Voxel& operator=(Voxel const& voxel_) = default;
    Voxel& operator=(Voxel&& voxel_) = default;

    /// Static member data:
    static Voxel const voxel_null; // This is invisible, default materialized block/voxel.
 
private:
    /// Constructors & destructors:
    Voxel(bool&& visible_, Material&& material_);
    /// Member data:
    bool _m_bVisible;
    Material _m_oMaterial;
};
 

Voxels can be quite tiny. In my case, I intend them to be that way (adds a possiblility of having more details in terrain). I might add
solid()-method later on (don't know if it's necessary, though). Note the static member variable voxel_null, which is an empty voxel with no interesting data in it.

 

I have ChunkVoxel-class, too (also in C++):

class ChunkVoxel{
public:

    /// Constructors & destructors:
    ChunkVoxel(void) = default;
    ChunkVoxel(ChunkVoxel const& chunk_voxel_) = default;
    ChunkVoxel(ChunkVoxel&& chunk_voxel_) = default;

    /// Member functions:
    inline bool const& visible(void) const;
    ChunkVoxel& visible(bool const& visible_);
    ChunkVoxel& visible(bool&& visible_);

    /// Member functions (overloaded operators, assignment):
    ChunkVoxel& operator=(ChunkVoxel const& chunk_voxel_) = default;
    ChunkVoxel& operator=(ChunkVoxel&& chunk_voxel_) = default;
 
private:
    /// Member data:
    bool _m_bVisible;
    union{ // This union allows both one-dimensional and three-dimensional access to voxel data.
        Voxel _m_oVoxels[16][16][16];
        Voxel _m_oVoxelsUnified[4096]; // Amount of elements: 16^3 = 4096.
    };
};
 

All these classes are work in progress, but to me, they look like quite a good-looking basis. happy.png

 

My ultimate challenging is the rendering: how can one render all these nice voxels in chunks (whenever it is required). What about the editor then? I would like to create editor like these:

 

 

 

These editors look handy and extremely useful, I would like to create editors like these myself!  I'm aware of the fact that C4 engine comes with the source code, even in the standard edition, but come on, 750 dollars!? blink.png It's great engine alright, awesome to be honest, but price like that is totally out of my reach. sleep.png

 

Anyway, few more questions: would it be wise to have an editor, which can export voxel-based geometry into 3D models (like .3ds or .obj or some custom file formats) so that, in game, voxels no longer need to be converted into triangles? huh.png Better performance, you know? smile.png

 

So, what do you think of all this? ph34r.png


What should be taken into consideration when making 3D models into a game?

22 March 2013 - 05:12 PM

Hi, folks! smile.png

 

As I've tried to create my own game, I have slowly got into 3D modeling. I have created my 3D model, which looks pretty good. But if it looks good, it doesn't mean it's well compatible with the game itself.

 

The subject of this topic is both artistic and technical, although main focus is on the technical side. What should a 3D model artist take into consideration, when he's making 3D models to a game? huh.png I know this is somewhat game specific, since each game functions differently. I'd like to know what you think about this, though.

 

Some suggestions what to cover here: happy.png

- file formats

- physics integration

- polygon count

- skeletal animation

- textures

- tools

- vertex painting

 

It would also be nice to know how can one implement some of these features in both the editors and in game engine itself.


Separating game logic from the game engine itself - data representation and connection

11 March 2013 - 02:33 PM

Hi, folks! Welcome to the topic! smile.png

 

Since many hobbyists and professionals alike use scripting for their game logic and game engine to handle all that, I decided, if they can do it, maybe I can do it too! happy.png

 

So I got into it. By the help of the Lord, I managed to put up a nice little system to write and read simple game data. I used my very own file decryption and encryption methods, of which I'm not that sure how many people know about. huh.png  Anyway, tongue.png  I kept on going. cool.png Eventually, I was able to store simple data, like game name, window properties, amount of entities, images, 3D models and such. No worries this far! smile.png

 

To be honest, I don't use scripting (at least not yet). I basically want to separate game engine from the actual game logic. I want to create a game engine, which is flexible enough to support pretty much any type of 3D game, user simply defines the what kind of game my game engine is supposed to handle. Game logic/tools to game engine. That's what I want to do. But how exactly? Simple data can be easily stored, but how about the following data:

 

- AI (movable areas, path finding)

- actions (user defined functionality for character entities, for instance)

- levels (geometry, entity placements)

- menus (linking to other menus, etc.)

 

and so on. I hope I made myself clear. wink.png

 

What do you think? rolleyes.gif


Game programming - Using vectors called forward, left/right and up

13 February 2013 - 09:38 AM

Hi, there! smile.png

 

When programming games, it is mandatory to know something about vectors. They are neat, and well represent... Wait, what do they represent?

 

Yeah, my problem is that I have come across vectors called forward, left/right and up. As far as I know, these 3 vectors were put to use in at least one commercially successful video game franchise, Ratchet And Clank:

 

 

In the video, two game developers, who worked on Ratchet And Clank: Up Your Arsenal, talk about problems they were having with vectors on spherical worlds. Very interesting, but difficult for me to internalize.

 

What do these 3 vectors represents and how could one put them to use? unsure.png


An entity class in a game - contents

06 February 2013 - 03:40 PM

Hi!

 

While desperately trying to create a game engine to fuel up a game idea of mine, I have encountered several problems in design of the game engine. What kind of class hierarchy might there be? I'm sure I'm not alone with this problem, no matter the object-oriented language.

 

I'm not thinking about covering the whole class hierarchy here. I'm talking about an Entity-class. Pretty self-explanatory. The question is, what kind of data (member variables) should this class contain? Direction and position vector? 3D model object? Entity name? Although this is game dependent, what should be the general structure for the Entity-class? unsure.png


PARTNERS