# Unity Questions before I start solo on a basic 3D RTS...

This topic is 1207 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm planning on trying to make a 3D RTS of some kind as my first actual 3D game project (having so far just studied some 3D tutorials and messed around with OpenGL), and I have some questions about practical ways to approach this as a lone developer...

I don't have an exact idea of what I what to achieve, I just want to experiment with some general ideas and see where it leads while learning some new things. I expect it will at least have to involve:
- A 3D landscape.
- Structures that can be placed/built on the landscape.
- Units that can be created and moved around the landscape.
- Resources of some sort in the map that can be collected by units or structures built on top of them (so perhaps like Dune II's spice or Warcraft II's oil/gold).
- Some degree of AI at least in terms of pathfinding, but also probably an AI enemy with some simple behaviour (possibly helped by "cheats" to provide more of a challenge and make up for poor AI if need be).

Having never made a 3D game before, I have a general idea about a lot of these things but I'm not too confident about fitting it all together in a way that makes sense, and I'd like to know as much as I can before going in the wrong direction.

My main concerns at this point are:

1. How do you actually make a vehicle move convincingly over 3D terrain?

Beyond using something like Unity, are there any libraries that are in common use to accomplish things like this or is it a reasonably straightforward thing to approximate once you know some basic 3D mathematics?

I've seen a tutorial about 3D terrain collision detection in OpenGL:

https:

He basically finds the height of the terrain at the player's position and uses that to check the player's height against.

For a vehicle, can you basically give it a bounding box (or use the wheel positions) and use that to accomplish the same thing, or would there be more complicated mathematics involved?
I had a thought about a truck/car driving over a cliff... you obviously couldn't just wait until both sets of wheels are fully over for the vehicle to fall, and you can't have it plummet after the front wheels barely clear the edge; so would the right thing be to keep track of the points of contact (in this case, the 2 sets of wheels) and also the midpoint between them and only have gravity e.g. affect the front wheels if they're off the ground AND the midpoint is also off the ground?

Dealing with a vehicle trying to climb a slope that's too steep comes to mind too, but I assume that would be fairly trivial to handle... I hope.

Does it seem practical for a lone developer beginning 3D to tackle something like that (partly as a learning experience even), or would there be a lot of complicated physics involved to make it look ok and it would just be better to use some library (and what library might that be in particular)?

2. Is there anything I should know about structuring a 3D game compared to a 2D game?

I'm going to try to keep things simple in terms of texturing, lighting, shaders etc. but does 3D inherently throw up any extra complication in terms of how the program might be structured/organized? Anything to keep in mind that would be considered best practice but doesn't necessarily crop up with 2D?

For instance, can I mostly treat 3D models and their animations like I would 2D sprites, or is a different approach needed?

3. Are there any popular libraries that would be of obvious help here? I want this to be a learning experience but I don't necessarily want to spend a lot of time reinventing too many wheels that aren't going to be as good as standard library solutions anyway.

EDIT: I'm intending to do this in C++, but I wouldn't necessarily be opposed to doing it in Java if there were good libraries etc.

##### Share on other sites

If you can find a copy of this book, it's a pretty decent (although slightly dated now), hands-on walkthrough on coding a classic-style RTS game.

##### Share on other sites

Are you trying to build a game or are you trying to build a game engine?

Game, primarily. Though there's going to be a lot of overlap either way in terms of what I want to achieve e.g. make a game but hopefully learn a lot of new stuff on the way too by not necessarily doing things the absolute easiest way all the time but mostly I'd just like to get a game project finished for the first time in a long time and feel more confident afterwards about game development and 3D in particular.

So either way is good, I guess.

Is there a particular reason you've decided to use C++ instead of something else, such as C#?

Mostly because it's what I'm most used to, what I've made some 2D games with, and what I've been using to (not as much or often as I should) study the workings of OpenGL.

You need to start by building terrain. And to draw terrain, you start by drawing a single triangle in 3D space.

Already gone over that in some tutorials and think I have that down fairly reasonably.

It's whether or not making a very basic vehicle drive around a 3D terrain in an acceptable way is straightforward enough without getting into time-consuming physics for someone to even bother doing it themselves rather than just go get a library that concerns me most...

i.e. It's nice to delve in and try to learn new things, but when it's something I really have no clue about beyond the purely speculative ideas I've come up with and some basic ideas about how vector mathematics works, I'm afraid I'd wind up spinning my wheels for weeks and lose my motivation. Meanwhile it seems a typical enough thing that there must be plenty of standard solutions around, but finding them is the hard part.

TBH, I'd probably just go with Unity if my current computer wasn't very unfortunately one of the few still running Vista, though in the long-run maybe I should just bite the bullet and get a new computer right now..

Still, the idea of doing things a little more manually and getting something basic up and running that way appeals to somewhat in and of itself. It's annoying when you keep wondering how certain things are done and you're not sure if perhaps it's easier than it looks, or actually even much harder than it looks...

In my opinion by gameplay RTS is the second hardest genre

Yes, that's a concern. The idea was to hopefully get by with as little AI, for example, as possible. Probably make it mostly about resource collection. There's a lot that can be done before combat is even introduced.

Something like notch's "Breaking the Tower" from Ludum Dare a few years ago even comes to mind; essentially a simplified version of The Settlers with a very definite and short-term goal.

Just an experiment to see where it leads and what I can come up with.

Even Mega Lo Mania is an example of an RTS that doesn't necessarily fit into the typical Dune II model, where combat is simplistic and it's really more about resource gathering and the choices that are made strategically. It's 2D, granted, but then 3D would just add the matter of collision detection between the landscape and units/buildings which wouldn't change much.

Indeed I've read that during development they originally got the entire gameplay working with just the interface visible alone because the graphics weren't actually important beyond illustrating the action.

Maybe Unity is really my best bet... but I just find myself feeling lost and as though beyond the very beginner stage, it's hard to find many particularly structured resources for advancing your practical knowledge of game development.

Granted, it needs to be expected for something like this to be a very hit-and-miss experimental hobby/career, but when you're new to a particular concept it's easy to feel overwhelmed if you have nothing to draw from.

It's like even if I could always put 12 hours a day in game development, I often have no idea how best to use my time to get a good grasp on the more practical aspects of more intermediate subjects. The likes of gpwiki.org don't seem to have anything on the terrain collision problem and I haven't yet found anywhere that seems to maintain a large collection of solutions/tutorials for a wide array of common problems beyond the very basic.

##### Share on other sites

Managed to find this...

http://www.toymaker.info/Games/html/terrain_follow.html

Seems relevant. Haven't read it properly yet but maybe it'll do the trick.

Another interesting observation I had when I was trying to think of RTS games that involved a height component in its terrain (I had trouble thinking of many... and most seemed not to really use the height for anything but visual detail), was that Battlezone almost exclusively used hovering vehicles; I wonder if beyond making the first person gameplay smoother, it was partly done to simplify calculations/behaviour for vehicles and be less hassle to implement...

If anybody else has any advice on how to implement some sort of quick approximation of vehicles following 3D terrain, that would still be great.

Edited by Sean_Seanston

##### Share on other sites
The "game or engine" thing generally goes down to the fact that, these days in particular, you can make a game significantly faster by using an engine(like Unity) but you won't learn nearly as much about coding or the gameplay by doing that.

You're generally learning about the engine's systems and the way the engine does things rather than the low level route. If your only goal is to make a game(for fun or profit) an engine will save you months adn give you a much better product.

However if your goal is to get a job professionally and be working on the really low level stuff, it helps a lot to work at that low level, it impresses employers to show you can make a relatively complicated game using from scratch D3D or opengl or whatever.

Not to say you couldn't get a job as well by making games with engines, some employers want that(if they use that engine a lot) but you're much more likely to be stuck in game logic if you do that, it entirely depends on what your goals are.

##### Share on other sites

Yeah, that's the kind of thing I had in mind: I mostly just want to make a game at this stage, at least to get back in the swing of making games for the time being and then maybe when I've gained some more confidence go back and look at things more closely, BUT... I also wouldn't mind going relatively low level now IF it's not going to take forever just to get something reasonable up and running.

Looks like that tutorial should hopefully be the answer to my problem...

Then I ought to be able to get a game up and running with a vehicle going around a landscape at least, and being a strategy game of some sort it shouldn't matter if it's quite simplistic.

The rest... sounds like the 3D shouldn't complicate it too far, beyond what would be expected in an ordinary 3D game anyway. I hope.

##### Share on other sites

Are you trying to build a game or are you trying to build a game engine?

Game, primarily. Though there's going to be a lot of overlap either way in terms of what I want to achieve e.g. make a game but hopefully learn a lot of new stuff on the way too by not necessarily doing things the absolute easiest way all the time but mostly I'd just like to get a game project finished for the first time in a long time and feel more confident afterwards about game development and 3D in particular.

So either way is good, I guess.

No.. either way is not good. Take it from me, I wrote my own game engine and it took over a year to do. I learned a lot about engines, but didn't make a game. I finally changed gears and decided I wanted to build a game and building an engine was a waste of my time because it was never going to be commercial grade quality. I'm just one engineer. Professional quality engines are built with large teams of engineers, so the quality and breadth of their engine is always going to be superior to whatever I build. If I wanted to add a new feature/functionality to my engine, I'd have to code it myself and I could expect to take many more months, and the QA just wasn't going to be there.

I don't know your game dev history or skill set, so I recommend starting really simple for starters and nail down the fundamentals. Make those atari games, then move up as your skill set increases. Use a game engine. Don't write your own.

Is there a particular reason you've decided to use C++ instead of something else, such as C#?

Mostly because it's what I'm most used to, what I've made some 2D games with, and what I've been using to (not as much or often as I should) study the workings of OpenGL.

Okay, you should definitely check out Unreal Engine 4. It's free and the backend is written in C++, and is still quite accessible to novices.

You need to start by building terrain. And to draw terrain, you start by drawing a single triangle in 3D space.

Already gone over that in some tutorials and think I have that down fairly reasonably.

It's whether or not making a very basic vehicle drive around a 3D terrain in an acceptable way is straightforward enough without getting into time-consuming physics for someone to even bother doing it themselves rather than just go get a library that concerns me most...
i.e. It's nice to delve in and try to learn new things, but when it's something I really have no clue about beyond the purely speculative ideas I've come up with and some basic ideas about how vector mathematics works, I'm afraid I'd wind up spinning my wheels for weeks and lose my motivation. Meanwhile it seems a typical enough thing that there must be plenty of standard solutions around, but finding them is the hard part.

TBH, I'd probably just go with Unity if my current computer wasn't very unfortunately one of the few still running Vista, though in the long-run maybe I should just bite the bullet and get a new computer right now..

Still, the idea of doing things a little more manually and getting something basic up and running that way appeals to somewhat in and of itself. It's annoying when you keep wondering how certain things are done and you're not sure if perhaps it's easier than it looks, or actually even much harder than it looks...

In my experience, everything *looks* easy, especially after you see how someone solved a problem. What you *don't* see are the hundreds of different attempts someone went through on their way towards finding that elegant solution. Getting terrain into a 'from scratch' game isn't easy. It's going to take a lot of engineering effort. You'll have to decide how you're going to draw the terrain. Then you have to figure out how to reduce triangle counts by using an adaptive LOD system. Then you have to figure out how you want to let people edit the terrain. Then you've got foliage placement. And you have to be able to find where a ray intersects with any point in the terrain. And how to apply textures. And how to make sure things don't fall through it. You'll probably want to break your terrain into "chunks" as well and figure out some way to stream in various chunks. Maybe you'll want to do occlusion testing as well. And lighting and shadows. Ugh. Eventually, you'll say, 'this isn't what I signed up for!' as you realize you aren't making games.

In my opinion by gameplay RTS is the second hardest genre

Yes, that's a concern. The idea was to hopefully get by with as little AI, for example, as possible. Probably make it mostly about resource collection. There's a lot that can be done before combat is even introduced.
Something like notch's "Breaking the Tower" from Ludum Dare a few years ago even comes to mind; essentially a simplified version of The Settlers with a very definite and short-term goal.

Just an experiment to see where it leads and what I can come up with.

Even Mega Lo Mania is an example of an RTS that doesn't necessarily fit into the typical Dune II model, where combat is simplistic and it's really more about resource gathering and the choices that are made strategically. It's 2D, granted, but then 3D would just add the matter of collision detection between the landscape and units/buildings which wouldn't change much.
Indeed I've read that during development they originally got the entire gameplay working with just the interface visible alone because the graphics weren't actually important beyond illustrating the action.

Maybe Unity is really my best bet... but I just find myself feeling lost and as though beyond the very beginner stage, it's hard to find many particularly structured resources for advancing your practical knowledge of game development.
Granted, it needs to be expected for something like this to be a very hit-and-miss experimental hobby/career, but when you're new to a particular concept it's easy to feel overwhelmed if you have nothing to draw from.

It's like even if I could always put 12 hours a day in game development, I often have no idea how best to use my time to get a good grasp on the more practical aspects of more intermediate subjects. The likes of gpwiki.org don't seem to have anything on the terrain collision problem and I haven't yet found anywhere that seems to maintain a large collection of solutions/tutorials for a wide array of common problems beyond the very basic.

Whatever you do, take careful stock of your available resources and scope your game accordingly. The objective is to built a game and actually complete it. If you're one person and can only work on it in the evenings after work and on weekends, then you don't want to build the next GTA or Need for Speed game. A simple, yet polished game is orders of magnitude superior to a complex but unfinished game.

##### Share on other sites

At this point in time, it's rather pointless for you to go through any "3D tutorials" that talk about 3d collisions, physics, terrain generation, water surface, etc.  You are interested in building a 3D game, not a 3D engine.  These mechanics are only useful to those who want to make their own engine.

Definitely use the free game engines Unity or Unreal Engine.  They have been made free only recently, and these are powerful tools that allow you to build 3D games.  Enabling 3D collisions may be as simple as a checkbox.  These guys have done it for you, professionally done, and they have made their sweat and labor available for free.  Take advantage of it.

Look up Unity/UE4 tutorials.  Little by little you'll get there.

1. 1
2. 2
3. 3
Rutin
20
4. 4
5. 5
khawk
14

• 9
• 11
• 11
• 23
• 12
• ### Forum Statistics

• Total Topics
633655
• Total Posts
3013179
×