Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Online Last Active Today, 05:04 AM

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

Posted by on 14 August 2015 - 01:09 PM

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.

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

Posted by on 05 August 2015 - 06:07 PM

Uh... well... first question:

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


I'll assume you're going to build an engine. I'm also going to assume that it's not going to be of professional quality since it sounds like you're doing this to learn.

Is there a particular reason you've decided to use C++ instead of something else, such as C#? You can build an engine faster in C# without any of the super low level BS which C++ and the low level API's throws at you.


If you're going to be building a vehicle game from scratch, forget about vehicle physics right now. You need to start by building terrain. And to draw terrain, you start by drawing a single triangle in 3D space. Expect this to take up to a month to accomplish, depending on your skill levels.


You may be able to get to a vehicle in 2-3 months, and it'll be rough.

#5244567 Octrees with multiple-sized objects

Posted by on 04 August 2015 - 04:54 PM

:) It's gratifying to see people finding use from my article on Octrees


So, a few quick thoughts I had:
-Octrees are a decent solution for getting away from a O(N^2) collision search and go towards a log base 8 search. You'll still run into some unusual use cases where you have to run a lot of search queries if you don't tailor the system to fit your needs.

-Let your performance metrics tell you if you've actually got a performance issue before trying to find an optimization. Does your planet collision check actually cause a slow down?

-If you use the octree, the planet would certainly be a lot higher up in the tree and have to run a lot of checks against leaf nodes. If you've found that this leads to a performance problem, you can try to reduce the number of collision checks by putting objects into various categories (static objects, movable objects, objects which don't have collision, etc). 

-There's no reason you can't use more than one octree. One tree might turn into your "scene graph" which contains a list of every object the camera view frustum can see and should render. Another tree can contain just the objects which need to be tested for collision. Would this take up more memory and CPU time? Yes probably... I've never tried this approach, so it may not be a good idea. You could probably get the same effect by just categorizing your objects. Here's probably the approach I'd take:

-It might be interesting to maintain a meta data list of object types in each octree and feed it up the tree to its parent, so if you have an object of type B and it can only collide with other objects of type B, and you know that a child tree only contains objects of type A, you don't need to go down that tree to test for collisions. If you want to go crazy and worry about memory footprints, you can contain these object types in a single integer value and use bit fields. This would probably be a pretty elegant solution and lead to a very quick check for type containment.

#5240178 Efficient 2D collision detection with many dynamic OBB

Posted by on 13 July 2015 - 09:02 PM

It looks like your shapes are all four sided polygons, so there's another technique you can use... Convert each 4 sided polygon into 2 triangles. You can then treat your bullets as points and look to see if any triangle has a point within it.


Here is my code to test for a point within a triangle:

/// <summary>
/// Determine whether a point P is inside the triangle ABC. Note, this function
/// assumes that P is coplanar with the triangle.
/// </summary>
/// <returns>True if the point is inside, false if it is not.</returns>
public static bool PointInTriangle(ref Vector3 A, ref Vector3 B, ref Vector3 C, ref Vector3 P)
	// Prepare our barycentric variables
	Vector3 u = B - A;
	Vector3 v = C - A;
	Vector3 w = P - A;
	Vector3 vCrossW = Vector3.Cross(v, w);
	Vector3 vCrossU = Vector3.Cross(v, u);

	// Test sign of r
	if (Vector3.Dot(vCrossW, vCrossU) < 0)
		return false;

	Vector3 uCrossW = Vector3.Cross(u, w);
	Vector3 uCrossV = Vector3.Cross(u, v);

	// Test sign of t
	if (Vector3.Dot(uCrossW, uCrossV) < 0)
		return false;

	// At this piont, we know that r and t and both > 0
	float denom = uCrossV.Length();
	float r = vCrossW.Length() / denom;
	float t = uCrossW.Length() / denom;

	return (r <= 1 && t <= 1 && r + t <= 1);

You'll have to look at your maximum worst case scenario as well: How many bullets can be on the screen at the same time? How many triangles will you have to test for intersections? If you're going for a O(N*N) solution, you'll start noticing some performance issues with lots of bullets. Measure the total collision routine run time (in microseconds) and see how much of a performance impact you get as you increase bullet counts. If you don't notice any issues, don't optimize :)

If you do notice issues, you can either reduce the number of intersection triangles, reduce the number of bullets, or choose an algorithm which runs better than O(N*N) [Quad Trees, BSP, etc].

#5239821 DigiPen: Computer Science and Game Design vs. Computer Science

Posted by on 11 July 2015 - 04:58 PM

I try to steer people away from DigiPen. Why?


1) The degree is centered around game development and that's too niche. The average game developer spends about 10 years in the game development industry. If you have a 30 year career, you'll eventually change jobs and get out of the industry. You'll want to have a broader degree and experience base you can fall back on when and if you want to get out of the industry.


2) Game development is fun, but so is non-game development. It's all interesting as fuck, so why deprive yourself of those other amazing, enriching development experiences out there?! I've built enterprise applications which managed billions of dollars in goods and reconstruction projects. It was very awesome and fulfilling and I loved it. I've built distributed computing systems. I've done science with computers. It's amazing.


3) It's more expensive.

4) The market place value is actually lower for a game programming degree than a general CS degree (see #1).

5) Just because you get a degree in game programming doesn't guarantee a job in game programming. If you get a game programming degree, you're already limiting your opportunities for employment.

So: Get a CS degree. Go to community college for the first two years, get those core requirements out of the way, then transfer to a four year university and get that CS degree. Your wallet and career will thank you.

#5239817 What kind of games can I create with my 3 member team that someone may actual...

Posted by on 11 July 2015 - 04:44 PM

Alright, here are the core things you really need to worry about:

1) How talented and experienced is your team? At a minimum, you should have at least one artist and one programmer and they should have quite a bit of experience.

2) Morale: How much are you paying your team members? If nothing, then you're going to have to find some extremely compelling reasons for people to stay on the project after months pass and the going gets tough. Don't promise equity or sales proceeds; 50% of $0 is zero, so when your team members think that the prospects for their efforts are zero, then you've got a huge problem coming down the project pipeline -- team members are going to abandon ship.


3) Scope: You've got a three man team, a finite amount of time, and a finite amount of resources. Be very realistic about what your team can achieve based on these resources and the teams talent. It's infinitely better to build a small, simple polished game which ships than a large, complicated and unpolished game which is impossible to complete.


4) Team Dynamics and leadership: People are people. They're not always going to get along perfectly and agree 100% on everything. That's good and usually healthy to have a diversity of opinions and insights on a team, but whoever is leading the team has to make sure that the interactions are constructive and not destructive and toxic. You'll want to build a sense of camaraderie among your team mates -- bring beer into the office, hold pizza parties, give recognition where its due, etc.

5) Market Research: You *must* look at what people are buying and where. This is very much like fishing: Where are the fish biting? What are they biting on? What kinds of fish are they? Don't go fishing where there are no fish, don't put lures out there which they have no interest in, and don't attract the kind of fish you don't want to catch. Do you want to build a web game? Do you want to build a mobile game? a PC game? These are all your fishing spots. Different fish lurk in different fishing spots, so be sure to use the right tackle to catch the right fish. The general customer expectation for mobile and web games is "free to play", and you want to make money, so "freemium" is the only viable business model. I suspect that the market is getting tired of these business models and it's getting kind of saturated, so maybe it's worth considering a different fishing spot or a different lure type.


Anyways, enough talk. It's 100% possible to create and ship a game today. It's the age of the indie developer right now. I'm on a 2 person team working on a commercial release for the PC platform. Be realistic about what you have to work with, make a sane business plan to achieve your objectives, and figure out what your strengths, weaknesses, opportunities and threats are (SWOT) and plan accordingly. This is all very much like a chess game -- you only make moves when you have a well thought out plan and each move should play a part in achieving that plan. Don't move with a plan. Strengthen your position to increase your chances of victory. Good luck, and have fun!

#5224031 Is it possible to finish a game on nights and weekends, while working a full-...

Posted by on 17 April 2015 - 12:35 PM


I just made a game over the weekend.

What about the big project now? I probably need to catch up on your journal...


I'm still working on it :) The weekend game was just a tech demo / MVP to get some quick lessons learned and a feasibility assessment for implementing a virtual reality game with hand gestures -- ie, fail faster. I'll use these notes as design considerations for the main game we're working on. 

#5223802 Is it possible to finish a game on nights and weekends, while working a full-...

Posted by on 16 April 2015 - 04:22 PM

Yes, it's possible. In fact, I just made a game over the weekend.


How do you do it? You have to be very careful about what you work on and how you do it.


1. Scope is your ENEMY! If you have a weekend to put out a game, your game needs to be super simple. Almost a tech demo / prototype.

2. You're going to have to spend money. I spent $110 to make my weekend game by purchasing assets from a market. It took the creators weeks to make these assets, so if you want to create them yourself... you're not going to finish in a weekend.

3. Build the CORE game play first, then add on to it. Don't invent the core game play in your head and add on to it in your head. Add, test, iterate.

4. You should use Unity or Unreal Engine. It's going to take you several months to get proficient enough to bust out a game in a weekend. DO NOT build your own game engine.


I'm going to spend a day or two more to polish my game, then release it into the wild and see how people like it.

#5222787 Looking for a online college to get my Computer Science degree

Posted by on 12 April 2015 - 01:07 PM

Call me old school, but I say, don't do online "schooling" if you can avoid it. Why?


-In person lectures are awesome.

-University isn't just about the classroom, it's VERY much about meeting similar people and making new friends. Later, those can turn into job opportunities. This is what makes some MBA schools much better than others, even though they all teach roughly the same material.

-If you have a question during a lecture, you can raise your hand and ask it right away and get immediate clarification and follow along the rest of the lecture without confusion / uncertainty.

-It's great to get out of the house / apartment / basement


I did all of my schooling in person. Not a single online class was taken.


My brother did 100% of his university education online at a school which was 300 miles away. Not a single in-person class was taken.


His university experience was pretty much sitting in a basement for 3-4 years, reading books, taking online multiple choice tests, and going through the bullshit which online teachers put him through ("you have to write a three paragraph response to the reading, then respond to your class mates response! Participation is mandatory.") to give a semblance of "instruction". It was pretty much a guided reading book club for four years.


If you go WAY back and look at how skilled tradesmen were educated, they went through an apprenticeship program. An apprentice blacksmith would learn under a master blacksmith. The master blacksmith would have one on one training with his apprentice, and be able to guide him, spot his mistakes, and correct them quickly. You don't get better training than that. Today, the best equivalent you can get is a mentor. Going to a university in person can provide you with the opportunity to get that oh so valuable one on one mentorship, but it's not guaranteed by simply attending. Teachers / professors are supposed to be these mentors for their students, but much more often than not, they are there to just go through the motions, lecture for a few days a week, and call it a day. They're victims of the university classroom format. But, if you get to know a particular professor, do their office hours, and really try to take advantage of their expertise, they will be excellent mentors. In an online "classroom" setting, this is all but impossible. My thought is that just because something is online and "high tech" doesn't necessarily make it good or better. Usually, you have to (unknowingly) make some pretty big sacrifices for that convenience.


So yeah, don't do online classes if you can avoid it.

#5220591 Starting A Company From Scratch - With no Money, Friends, or Education...

Posted by on 31 March 2015 - 07:27 PM

Yeah, I agree with everyone else here. You are by no means ready to start making games. There are thousands of people who want to make games but very few who will get the skills necessary to actually make them. It takes LOTS of hard work and dedication to get good at making games. Do you have that? Or is this a passing interest?


If you do have a strong interest in building games, you're going to have to educate yourself to improve your existing skill set. In 2015, there really is no excuse for not being educated anymore. You have access to the internet. You can go watch youtube videos at Khan Academy to teach yourself the basics in mathematics which you've missed out on. Then, you can download and install a free compiler (Visual Studio 2013 Community Edition) and start building an XNA game. There are tutorials for that too. There are thousands of tutorials for beginners. Whatever happens, you HAVE to be someone who contributes meaningful work and adds progress to the game project. If you can't do that, then get there. If you can't ever get there, then forget about it.


You're only 23. You aren't doomed. You have lots of time, but you're going to have to work your ass off like you've never worked before. Making games is a slog and it is nothing like playing games. It's all about building software which happens to be entertaining.

#5219715 Indie Job Titles

Posted by on 27 March 2015 - 03:40 PM

Titles don't really matter to an indie, do they?


If you have to put yourself in the credits, just say "Developed by: yourname"


If you have to talk about your role in a company, just call yourself a "founder".

#5217239 Review of class rendering code using marmalade c++

Posted by on 17 March 2015 - 07:19 PM

I agree with Frob.


The code you have posted above is at least missing a curly bracket after the if statement. And you're also mixing rendering with your game model, which is a big architectural mistake. You should never change your model state within your rendering code.


If you're struggling with bounding rects, you need to back up a bunch and just get a simple bounding rect working in isolation. Forget about your game and pong, that's too much complexity for you right now. Before you even write your first line of code, you need to have a conceptual understanding of what you're trying to do. Draw a picture if it helps (I do this all the time with a hand held white board). If you can't get a conceptual understanding of what you're trying to do, then it's futile to write code. 


So, let's start super simple:


What is a boundary?


It's a line, right?


Let us define a simple flat line like Y = 0


What points are above it? Which ones are below it? How can you tell? Can we write code which can return a boolean value for this? If not, then you've got some basics in code and mathematics which need to be reviewed. Let's assume that you can.


Well, let's complicate the problem a bit now. Let's draw two horizontal lines.


Line 1: Y = 0

Line 2: Y = 2


Can we figure out which points lie between lines 1 and 2? It should be pretty straight forward. 


Now, let's complicate the problem slightly more. Can we draw two vertical lines as well?


Line 3: X = 0

Line 4: X = 2


Can we figure out if a point lies between those two lines? Can we figure out if a point lies between all four lines?


If you can, now you've got a bounding box!


Typically with most bounding box implementations, you specify a rectangle by setting the top left coordinate, then specifying a width and height. Then the bounding rectangle may have a method which returns a boolean value on whether or not the rectangle contains a point. The math for this is super simple.


Now, if you want to get crazy, you can also rotate this bounding box. The question is, what do you rotate around? Do you use the top left corner or the center? How do you know if a point is within a rotated bounding box?


Simple: You figure out the rotation of the bounding box, the pivot point of that box, and then you unrotate the bounding box around the pivot point, and you also unrotate the position you're testing against.


Can you do all of this? Where do you get stuck? 


If it helps, forget about rendering anything to the screen and stick to pure mathematical representation until you get it right. Use a C++ console application to test your bounding box code. If you still struggle with this, you're going to have to do some self-teaching. The answers are already out there, you have to find them.


The essence of all programming is breaking a problem down into its smallest parts, solving those, then putting the parts back together to solve a bigger problem.

#5217143 Using octrees for spatial representation

Posted by on 17 March 2015 - 02:10 PM

I wrote an article on Octrees a while back. It should give you 90% of what you're looking for if you want to learn about octrees.


My recommendation is to avoid the overly complicated "updates in place" I wrote about and instead just wipe the whole tree each frame and rebuild it. It's still faster than O(N^2) search time and way more simple to find and fix problems ;) The important thing is to get it to work first, then optimize later if you still have performance issues which you've determined through measurements. In some cases, the added complexity you think will increase performance will actually decrease it :o


Anyways, let me know if you have any questions.

#5215102 Employee appraisal

Posted by on 07 March 2015 - 02:38 AM

Based purely off of what I've been reading, I probably wouldn't want to have you work for me either. If after a year you aren't 95% self-sufficient and independent, and working to refine your processes and output quality product, and instead you're asking the rest of the team for help, you're really not a good employee. If I'm paying each employee $60 per hour (just to keep the math simple) and after a year, you still routinely take 15 minutes to get help from someone else, I'm paying for your time and their time, so I'm losing $30 for those 15 minutes. At first, I could justify this as a cost which could be seen as a long term investment in the development of an employee and their skill set. I would expect to see lots of positive growth with a tendency towards self sufficiency and a progression of the technical difficulty of the questions being asked, and a greater independence. If that doesn't happen, and instead I see an employee using fellow coworkers as a crutch in order to avoid the necessary pain it takes to grow, I won't be happy.


I would have no problems IF you said, "Hey, I can't figure out how to do X. I've done all this research and progressed to this point, but Y is really hard to wrap my head around. Have you ever dealt with this before? Do you have an suggestions on where I should aim my efforts?" There are a few important things to realize in this approach. First, you have identified the problem. Second, you have given a really honest attempt at solving the problem yourself, and you have made some progress. Third, you can admit that a portion of it is confusing to you. Fourth, you're not asking someone to tell you what to do, you're asking for guidance.


In my humble opinion, your boss has been really generous to let you stay on the team for a year. Wow. Seriously. That's a lot of money you've costed him in wages. He must really be all about that employee development and giving you a good solid chance to prove yourself. It's a bit shitty that he's only bringing up this issue now rather than nine months ago. You can bet that there have been conversations about you and your performance behind your back with your team mates, and they haven't been favorable. If you want to stay on the job, you need to start pushing yourself towards becoming self-sufficient as a problem solver. When you accomplish great things and contribute to the teams success, don't keep it a secret. Tell people what you did. Talk to people. See how you can help them be better. 


If in fact you ARE a great employee and I'm completely misreading the situation here, and you're doing great work, then you have a big communication and perception problem with your boss and coworkers. This is an area we can all improve in, and it may also cost you your job if you don't make some rapid changes. Again, talk to people. Figure out what's expected of you. Communicate your progress, ask for assessments, try to get better, help your team mates, don't weigh them down with questions which can be googled in 5 minutes. Figure out what the big picture is, what the project vision is, where you fit in, and how you can push it forward and bring success to the team.

#5208267 Terrain sculpting

Posted by on 02 February 2015 - 02:59 PM

When I built my terrain system, I also used a texture heightmap to determine vertex heights. However, I considered the heightmap values to be an initial starting position for the terrain height values, not the definitive values. After the terrain was loaded, I was free to discard the heightmap textures. If I needed to modify the vertex positions, I would do that within the terrain's internal data values. If I need to save the terrain height, I could easily generate a new height map texture and export it to disk. You could consider this approach if you aren't doing it already.


Also: I think you should try to measure the performance of your code. It would help you a lot if you could isolate exactly where your performance slows down so that you aren't making guesses at your optimization needs. It can be something as simple as starting and stopping a stop watch to count ticks between a code block. Until you do this, we can only guess at what's causing slowdowns.