Jump to content
  • Advertisement

BenS1

Member
  • Content count

    158
  • Joined

  • Last visited

Community Reputation

352 Neutral

About BenS1

  • Rank
    Member

Personal Information

  • Interests
    Programming
  1. Thanks again @Scouting Ninja Yeah I was thinking about having a "Strategic Map" so that you can zoom out so far using the real terrain and then blend out to an overall map. The trick is trying to get this blend to work smoothly and seemlessly. Supreme Commanders strategic zoom looks great, whereas the strategic zoom in Ashes of the Singularity Escalation looks ok-ish but definitely not as good.
  2. Thanks i3di, that sounds very interesting. However I think my requirements are little different to most. Most games that require large terrains only show a relatively small amount of the terrain at once, so they can load in the current and neighbouring terrain chunks and that's all fine, but in my case I need the ability to zoom completely out so that I can see the entire terrain at once. Does your World Max assume that you will only be viewing a small piece of your terrain at once, or can it use LOD to show more of the terrain (At lower levels of detail) as you zoom out? Thanks Ben
  3. Thanks for info Swiftcoder It seems like there are a few engines around but they seem to be mostly hobbyist projects that eventually run out of stream, just like my original attempt. I was hoping that there would be a mature major commercial game engine (Including editors and tools etc) that supported massive terrains. I'll see how far I can get with the Unreal Engine. Thanks again Ben
  4. Indeed, it's meant to be kind of small planet size. In my engine the terrain is generated in realtime on the GPU so in theory the terrain could be any size and it doesn't have any impact on performance. In fact it'd probably be quite easy to make it infinite in size. The only complications would be around float precision issues, but these can be overcome. I've looked at Outerra a few years ago. It looks very impressive, but I'm not sure how actively it's being worked on. The website looks exactly the same as when I last looked a few years ago and it still says everything is in Alpha. As far as I can see there's no option to download or buy the engine for your own use. Do you know of any other specialised planetary engines? Thanks Ben
  5. Thanks both for your replies, So it looks like I'll continue to explore the limits of Unreal Engine and see if it can deliver what I need or whether I need to revert back to plan A of creating my own engine. Thanks Ben
  6. Hi all, I've been in the process of creating a RTS game in the style of Supreme Commander (But with much bigger levels) for a while now, and whilst I've made good progress writing my own engine from scratch it has become clear that the scale of the project is way too big for one person to do in their spare time (Especially as I work fairly long hours in my day job and I like to spend as much time with my family as possible.). So, my plan B is to look at possibly using one of the existing Game Engines out there such as the Unreal Engine, Unity etc. I've done a couple of Udemy tutorials for Unreal, which have been quite useful, however I see that there appears to be a lot more tutorials and information out there for Unity, so I was wondering if I've backed the wrong horse. The key feature that I need from the engine is the ability to show massive terrains, and by massive I'm not talking 5km x 5km, I'm talking more like 1000+km x 1000+km square! And unlike an FPS type game that can load in terrain segments in tiles based on your current location I need the ability to zoom the camera right out so that I can see the entire 1000km x 1000km map all at once (Although the level of detail can obviously be much lower as you zoom out). If you've played Supreme Commander then you'll be familiar with this style of "strategic zoom". I already have this working in my own game engine by generating the terrain in realtime on the GPU using multiple octaves of Perlin noise, which has the added bonus of allowing me to smoothly tessellate the level of detail as I zoom in and out (In my engine the terrain is 4000km x 4000km). So the question is, what sort of terrain capabilities do the big game engines support? I'm guessing none will support realtime generated terrains? If not then whats the maximum size pre-generated terrains that they can support? And what LOD capabilities do they have for when you zoom in/out? Thanks in advance Ben P.S. I've tried doing some of my own research but all I seem to find is old forum threads that say things like "there are expected to be big improvements coming to the terrain capabilities in Unreal 4.8", which is now old and I've not seen any confirmation or details about if big improvements did indeed happen.
  7. Great article!   I can relate to everything you've said there (Also being a 38 year old developer, who has been writing games (Although only as a hobby) for about 24 years).    I wish you all the luck in the world. I also wish I had the balls to do what you've done.   Ben
  8. Thanks again all, I think I'm starting to get it now.    I think the heart of my problem is that I'm not encapsulating the details of the renderer, so for example my Terrain class doesn't have a simple Material and Geometry but instead has much lower level information, such as: // The Vertex and Index Buffers describing a tile ID3D11Buffer* m_TerrainVB; ID3D11Buffer* m_TerrainIB; ID3D11Buffer* m_SeaVB; ID3D11Buffer* m_SeaIB; ID3D11Buffer* m_BoxVB; ID3D11Buffer* m_BoxIB; ID3D11VertexShader* m_TerrainVS; ID3D11PixelShader* m_TerrainPS; ID3D11VertexShader* m_SeaVS; ID3D11PixelShader* m_SeaPS; ID3D11VertexShader* m_BoxVS; ID3D11PixelShader* m_BoxPS; // The input layout for terrain vertices ID3D11InputLayout* m_TerrainInputLayout; ID3D11InputLayout* m_SeaInputLayout; // Constant Buffers ID3D11Buffer* m_PerFrameCB; // Per frame constant buffer ID3D11Buffer* m_TerrainObjectCB; // Per object constant buffer I guess I need to better encapsulate these, so that I just have higher level Material and Geometry classes, and then I can use the above advice to just send the Material and Geometry to the renderer.   It's all starting to make sense, and should help to simplify and tidy up the code too (I hate messy code, so I've not been happy with this for a while now).   Thanks Ben
  9. I've just read the 2 articles on Component Entity Systems, and they're pretty interesting and I can see how the memory layout is efficient from a cache point of view, but I'm not sure how well it would work in my case.   Lets imagine a an RTS game, with potentially thousands of units in play at any one time. You might use a Quad tree to partition the space and only update the units in view with every frame, and objects just outside of view are updated every other frame (Some on the odd frames and some on the even frames to balance the load) and units even further away are updated even less frequently. I'm not sure how this fits in with the CES idea.   Also, imagine if a have a world that can potentially support a theoretical 100,000 entities (Maybe 2000 units + loads of bullets, rockets, missiles and other objects). In reality most of the time you'd only have an average of 1,000 entities, but in the heat of a massive battle this could increase significantly. Having your systems walk all 100,000 entities every time when most of them will be empty seems inefficient.    One final comment, for worlds with a large number of potential entities it may be better for createEntity and destroyEntity to maintain a list of the index to free entities so that creating a new entity can be done in constant time, rather then potentially having to walk up to 100,000 items in the array.   Interesting concept though and definitely looks like a good idea for many applications, but potentially doesn't work for everything, but then nothing ever does.   Thanks again Ben
  10. Thanks both for your replies,   GK, I'm actually reading Game Engine Architecture 2nd Edition right now, but I haven't got to that part of the book yet.    Previously I'd read the otherwise excellent Game Coding Complete book but this was the one area that I found confusing in that book.   Thanks Ben
  11. I've been writing games as a hobby for about 25 years now, and in my day job I'm a LEad C++ developer writing realtime performance critical highly multithreaded code, however there is one thing I've always struggled with and that is how to separate the Rendering Code from the rest of the game code. It seems that lots of games books suggest that you should do it but they don't really explain how to do it.   For example, lets imagine you have a Command & Conquer style RTS game, internally you might have classes representing the terrain, objects on the terrain, units (Player, remote and/or AI) and bullets/rockets/lasers etc.   These classes contain all the information relating to the object, for example for a player unit you might have the units position, speed, health, waypoint list etc. You may also have rendering data too such as models\meshes, textures etc.   In this simple model (Which has worked fine for me for many years) you can have standard methods on the objects such as Update() and Draw(). It all works great.   The problem is, what if I want to port my DirectX game onto another platform that uses say OpenGL? My rendering code is so embedded into the game code that it'll be a major job to port it.   The books seem to suggest that you should have separate classes for your game objects and your rendering objects. So for example you might have a Unit class that supports an Update method, and a separate UnitRenderer class that supports the Draw class. Whilst this makes sense and would indeed make porting much easier, the problem is that the UnitRenderer would need to know so much about the internals of the Unit class that the Unit class would be forced to expose methods, attributes and data that we otherwise wouldn't want to expose from the Unit class. i.e. we might have a nice clean interface exposed from the Unit class that encapsulates the internal implementation and is sufficient for the rest of the game, but the need to expose internal information to the UnitRenderer means that your nice clean Unit class becomes a mess and exposes its internal implementation details to anything that can access the Unit class.   Plus of course there are performance implications of doing this.   How do people typically separate their games code from their Rendering code?   Thanks in advance Ben
  12. Just for future reference if anyone else has the same question.... I downloaded CMake and followed the instructions here: http://assimp.sourceforge.net/lib_html/cmake_build.html   And to my surprise it actually worked. By worked I mean that it generates Solution\Project files for the versions of Visual Studio you select (As well as different target platforms, such as x86 or x64) and they build just fine.   The solution\project files it generates are a good starting point, and it builds, but they're a bit of a mess as they use absolute full paths instead of solution relative directories etc, but it's only a minute of 2's work to tidy that up.   Thanks Ben
  13. Thanks LennyLen   Yes I initially downloaded the binary install but it only includes the release lib files and not the debug versions. I'm not sure if this is an issue though.   I eventually found the build instructions (Not in the most obvious place I have to say), and so I'll try using CMake later (HAving never used it before).   Thanks for your help Ben
  14. Hi,   Looking at the Assimp website it suggests that Assimp builds for several versions of Visual Studio upto and including VS2012 (VS11), however when I download the full install I don't see any solution files or instructions on how to build it.   Has anyone built it from the Visual Studio IDE, and if so please can you share your instructions on how you did it?   Thanks in advance Ben  
  15. BenS1

    Something Special Today...

    Hey, how come theirs has been updated for DirectX 11, the spine on my version says "DirectX 1" :)   (Yeah, i got one of the first batch that had the printing error)   Great book though.   Any plans on keeping it up to date with DirectX 11.1/11.2 and updating it to use the version of the DirectX SDK now included in the Platform SDK and not the old Standalone June 2010 DirectX SDK?   Thanks Ben
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!