• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Helixirr

Members
  • Content count

    20
  • Joined

  • Last visited

Community Reputation

141 Neutral

About Helixirr

  • Rank
    Member
  1. I think this is necessary if you want to get sufficient performance, but I don't know your requirements. Notice that using a block with half the width will increase the density of blocks with a factor of 8. There are some steps of varying complexity (from easy to hard): Sort surfaces on type. Remove hidden surfaces (sides of adjacent cubes). Merge adjacent surfaces (triangles) into bigger triangles. Detect what chunks are outside of the view frustum, and ignore them for drawing. Detect what chunks are hidden behind other chunks. Sounds easy, but not trivial. Implement LOD (Level Of Detail). This is complex for voxel based drawing, especially in the transition from one resolution to another that can lead to artefacts. Use impostors for far distant chunks. For smoothing, there are a couple of possible technologies. The marching cubes is frequently mentioned, but I think it is difficult if you are going to support more than one type of block. Another solution is to use a kind of a filter that transforms the corners of the cubes. You can see an example of it in my implementation. It will get you smooth terrain, but still with sharp boundaries between block types. There is also the concept of "Elastic surface nets". I haven't looked much at it, it may be similar to what I am using.   For the world editor, I switch between a smooth world display and a blocky display when I enter edit mode.   Wow, this is more like it! Thanks a lot, Lars, I'll take a look at this!
  2.   Nice suggestions, larpensjo! Optimization seems to be the keyword here.     This approach is basic, but that's where I have to start from. Terrain smoothing adding details requires more knowledge of voxel-based terrains.     I don't think these are that necessary to me, especially 2D and 3D simplex functions, since I don't need procedurally generated terrains. All I want is voxel-based, simple to use voxel-based terrain editor. On the other hand, I might actually be very useful, since it adds surprises to a game. One thing where I might use procedural terrain generation is to add varying backgrounds, landscapes to my in-game levels. The gameplay areas of levels stay the same, but backgrounds change to create refreshing atmosphere and variety. It would be kinda cool.   One question is still unanswered: is it good idea to convert voxel-based terrain to 3D model (all terrain details and smoothings applied), so that in-game, instead of dealing with voxels and then geometry, there could be only geometry (quads, triangles) to render?
  3. Hi!   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.   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.   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:   http://www.youtube.com/watch?v=9gf3sFBNOMk   http://www.youtube.com/watch?v=zWQl_Fpr9Gk   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!? It's great engine alright, awesome to be honest, but price like that is totally out of my reach.   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? Better performance, you know?   So, what do you think of all this?
  4. Hi, folks!   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? 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: - 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.
  5. Hi, folks! Welcome to the topic!   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!   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.   Anyway,   I kept on going. 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!   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.   What do you think?
  6.   Oh, interesting. Thank you for pointing that out.   No wonder they used these vectors in Ratchet and Clank 3, then.
  7.   You're welcome.  I edited the original post to add more detail.  (I may have veered a bit off track though.  )   Feel free to add more or PM me if you have any further questions.   Thanks for the PM offer, but I prefer discussing subjects on the forums, so that everyone can see them. Helpful resources should belong to everyone.
  8. Just a little note - the game above was originally released on PS2 (on which the developers probably play the game), but eventually got it's release on PS3 in HD as well.
  9.   This is the kind of reply I was looking for!   Thank you, Polaris! I finally understand this, maybe not everything, but this post surely made my day! Useful reference.   PS: No advertising or anything, but I also recommend you all to check out all the other episodes from the developer commentary as well. That way it is easier to get a better picture of game development process.
  10.   Of course.  The interesting part and the part relevant to the topic starts after 06:25. I wouldn't call the approach "non-standard", though. It's just, you know, different.   I'm trying to explain my problem the best I can, but it's difficult.   I hope you get the gist of what am I looking after.
  11.     Both of these replies tell us what vectors consist of, a direction and a magnitude. I know this already, but of course it is helpful for newcomers. I'm also aware cross and dot products etc.   The problem I'm having is that I can't distinguish the difference between two different approaches, the use vectors direction, position and velocity or the use of vectors forward, left/right and up. Here are two examples of two diffent approaches:   http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-1/   and   the video I already posted.   What are the benefits of whichever approach?
  12. Hi, there!   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:   http://www.youtube.com/watch?v=vWLrjqF4eX0   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?
  13. My initial thought on looking at the code is, unfortunately, ''no'', the way  you've structured it I would make the copy  constructor and assignment operators private otherwise anything derived from it have to override them (and they are not virtual, so anything using them via the base class would break). This may have been a typo but, I would say, you would never need to copy an object like this anyway.   If you can think of many ways where you would like to do this, then my preference would be for a ''virtual Entity* Clone()'' function to be exposed (but only if you'd deem it a necessity) rather than copy ctor and assignment operators.   I'm also unsure why you have a virtual 'show' function as well as set_visible functions. They seem, at first glance, to be the same thing. However, I would do somethinng more like:   void isVisible() const { return m_isVisible; } void show() { m_isVisible = true; } void hide() { m_isVisible = false; }   I would also expect there to be an update() function somewhere. One suggestion I would give, is that I see a lot of games where the update function takes a time delta alone. eg:   virtual void update( float timeDelta );   I would recommend that you pass in,rather, a structure instead: similar to:   struct UpdateArgs {     float timeDelta; }; ... virtual void update( const UpdateArgs &updateArgs );   Which allows you to extend the arguments passed to an object without having to revisit every class. For example, you could add a ISystem* or other things that are globally necessary to it.   And whilst virtual functions are awesome, think carefully before you make a function virtual. They can be a large performance loss on some machines, and even can be on the PC if much of your architecture relies on them. This is not an anti-virtual post though, I'm not advocating to avoid them completely just that you put thought into what you make virtual   I would also expect a serialization method in the entity class (whether it's a base class, or the owner of a component system).   Hopefully thats of some use, n!   Sorry for double posting, but I also had to cover this one separately.   I admit using "show" along with "set_visible" member functions. "show" should be replaced by "update". That way it would be more clear.   Time delta solution looks very handy, have to put that into consideration.
  14. Again, if you are using SOLID development principles, you will program to interfaces. Dependency inversion -- or programming to interfaces -- is an extremely beneficial part of well-written code.    A Vector or Point is actually a 4-entry array: X, Y, Z, W. For a Point, W=1. For a Vector, W=0. Otherwise the two are interchangeable. Position is a point in space. Velocity is a vector. But you suggest that "direction" is a velocity? It does not work mathematically. You can represent 3D orientation with a matrix, or with a quaternion, or with two vectors. Quaternion is the most compact, requiring four values. Two vectors is the next most compact; I prefer it because you can easily perform other operations on it; dot products for forward-facing tests are the most obvious. If you need the third component you can use a cross product of the forward and up.     I may have implicitly suggested direction to be the same as velocity, but I didn't mean that, I simply forgot to mention about velocity separately.     This part of your post was very helpful for me, because it hasn't been clear to me if I should use quaternions or vectors to represent 3D orientation. I guess quarternions would be alright. Have to think about this, though.       This post is so long I can barely do justice for it, but the effort you put into this is excellent. I like the question-like approach to the problem: "Can it do this?" "Does it contain this?" etc.
  15. I haven't tried to implement this since I'm using XInput myself, but from I see, I like it.   Never thought of using GLFW like this!