Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Offline Last Active Today, 11:23 AM

#4976006 Keeping parts of the engine separate

Posted by slayemin on 03 September 2012 - 04:31 AM

There's a subtle trap you may be at risk of falling into: Soft coding everything. It's at the opposite end of the spectrum of hard coding everything, but can be just as annoying.

Focus on creating your game to its specific requirements. You're going to have to get specific somewhere, eventually. If that means you have to create a fantasy character generator to make your game work, then that's what you'll have to do. If, in the distant future you find yourself building a futuristic version of your game, you can reuse most of your code and existing software architecture. It'll probably add unnecessary complexity if you want to generalize your character generator for any genre. Remember that software is software, which means it can change with changing requirements. It takes less effort to recompile and deploy a patch :)

#4975718 When am I qualified?

Posted by slayemin on 02 September 2012 - 07:12 AM

Employers have three main questions they're trying to answer about you:

1. Can you do the work required of you?
2. Would you be a good fit for the company and organizational culture?
3. Will you cause problems for the company?

Pretty much all relevant interview questions are trying to answer these three over-arching questions.

At the same time, remember that interviews are a two way street! you're also interviewing the company to see if its a place worth spending your time at. Here are the overarching questions I try to get answered as an interviewee:

1. What are working conditions like (environment, org culture, equipment, bosses, etc)?
2. Is the company stable? Does it have its shit together? (You want to get paid in full, on time and you don't want to get jerked around)
3. If I agree to work here, what are my costs going to be? (Time, money, energy, mental sanity, expertise, costs to quality of life, IP rights, freedoms etc.)
4. If I agree to work here, what can I expect to gain? (money, experience, perks, etc) Do the costs outweight the gains?
5. Why should I work here?

Note that you are an economic resource and the principle of supply and demand applies to you. The more rare and exceptional you are, the more leverage you have in negotiating to get what you want. I suspect that the biggest mistake entry level people make is undervaluing themselves.

#4975107 Updating the Player in a Quad Tree

Posted by slayemin on 31 August 2012 - 05:02 AM

I'd recommend putting a layer of abstraction between the input devices (mouse and keyboard in this case) and the game object. That way, the input devices are more interchangable and you don't have to worry about how the device is being used.

For example, suppose I have a space ship object. I want to give the play the ability to move the space ship object forward in the direction its facing, and to turn the direction of the space ship object.
W - Makes the space ship go forward
A - Turns the space ship to the left
D - Turns the space ship to the right
S - Slows the space ship down

If you bind the keys like this:
   position += GetDirection() * speed;
   Direction -= 1;
   Direction += 1;

Instead, do this:

By calling the methods for the objects to manipulate the objects instead of manipulating the objects directly, lets other entities control the object -- like an AI controller. So, both the player and an AI call Spaceship.Thrust(), and can be interchanged with very little code rewriting.

When you're using the quad tree to handle collision detection and any update code (AI), you shouldn't care about what is controlling the entity. All you care about is where the object is located spatially and how you want to update the object with respect to nearby objects.

#4972624 Digging

Posted by slayemin on 23 August 2012 - 10:09 AM

I can't point you towards any specific articles, but I can give you some guidance on how I'd approach this conceptually...

Rule #1: Try to understand the simplest form of the solution. We can always make things more complicated later.

Abiding by this rule, let's try to subtract a volume from a 2D rectangle using another 2D rectangle. If you have a rect with the lower left oriented at 0,0 with a height & width of 2, and then subtract a 1x1 rectangle from it, can we figure out how to do it on paper? What result should we try to get? Do we want a polygon, or do we want to create a bunch of rects? What's the easiest to work with? What if we subtract the 1x1 rect from an arbitrary location somewhere on or around the 2x2 rect?

I think ideally, we'd want to recreate the geometry by rebuilding it with new verticies. The new rect would certainly contain the verticies which are contained within its bounding area. We'd also be interested in the lines of the verticies which are within the bounding area since the new region will have to place its adjusted verts on that line.
Original rect verticies: {(0,0),(0,2),(2,2),(2,0)}
Subtraction rect verts: {(1,1),(1,3),(3,3),(3,1)}

Result should contain five verts:
Note: (1,1) was the bounding vert but it was connected to (1,3) and (3,1). So, how do we get the resulting verts (1,2) and (2,1)? We do a line intersection test! Since we know that there is a vert contained within another vert, we MUST have intersecting lines. Although this is a math & physics forum, I'm going to leave the line intersection test mathematics out -- it's pretty simple; start with the "y = mx + b" equations and don't forget to account for floating point precision errors!!!!!!! Set a minimum epsilon and use testing to adjust its accuracy. Test this thoroughly since you don't want floating point precision errors to randomly creep up on you. (A more scientific approach would be to know exactly how large your epsilon tolerance needs to be for different parts of the float scale)

Anyways, once you've got this solved for integers in two dimensional space, you can add additional complexity by adding in additional verticies at arbitrary positions, the z-coordinate, and eventually rebuilding complex meshes (such as rebuilding a section of terrain to simulate a crater after an artillery shell impacted it).

If you get stuck on something, back up a step to its more simple form and make sure that its working as expected.

On a slightly more abstract/philosophical note, you may be able to avoid doing any of this all together if you can find a clever way to eliminate this requirement from your game play or simulate its effect (some games will use precalculated shattered meshes to simulate something like wood splintering). If this is vital to your game play (such as with mining out a tunnel), you may be able to get away with carving out blocks (like minecraft or terraria) instead of recreating meshes. Anyway, its something to keep in mind. If you spend an hour trying to think of a clever solution, it may be more cost effective than spending ten hours or more implementing a less clever solution.

#4971772 Composition heavy OOP vs pure entity component systems?

Posted by slayemin on 21 August 2012 - 04:42 AM

One other advantage to the Entity-component system is that it lends itself very well towards parallelism. When you've got processors with multiple cores, multiple processors, or multiple networked computers each with their own processors, it only makes sense to distribute the processor work load to make use of the available resources (if it provides a performance boost). I've successfully implemented an entity-component system which distributes the components across multiple cores, but haven't spent a lot of time and effort to see if it works over networked computers. It's mostly been a proof of concept and I've been meaning to flesh it out and do a thorough write up with code samples.

One downside of the entity-component system is that it incurrs a significant overhead cost in terms of programmer time (at least it does in mine since I'm using a message passing system). Every get/set accessor function has to be a message which can be passed between entities and components. This can start to cost 70% of your time every time you create new component classes, and adding this extra code can become rather tedious after you've done it a lot.

The big win with the entity-component systems though is that NO game objects are defined in your code. I define every entity within an XML file. When the game loads, it parses the XML file for entities, reads in the templated components which compose the entity, and then instantiates the entity based off of a "blue print" (or whatever term you want to use). The dynamicism for game objects depends entirely on how flexible the components are and how capable they are of supporting whatever you want to build. Creating new objects in a game is thus, much like combining lego bricks together in new and interesting ways.

#4954555 Where to start learn x86 assembly

Posted by slayemin on 01 July 2012 - 09:50 AM

The Art of Assembly Language:

The Author (Randal Hyde) has been nice enough to make his book freely available online. It's probably the best way to learn x86 ASM.

I learned ASM by using the Easy68k emulator for the 6800 processor. It's a bit easier for beginners to pick up than the x86 processor.

#4954542 College advice?

Posted by slayemin on 01 July 2012 - 09:15 AM

Now why would I write this? Well for instance this website has plenty of people who took the save road(a CS degree) and they did NOT ended up doing games. In fact many of them are too tired after a 40-60 hours week to even touch game development(you guessed it they do not work in the game industry). And the little spare time they have left goes for their kids and wife / husbands.

The chance that some other industry drag you into their fold is very high and you will end up with a fine salary and perhaps even a life with quality. BUT... BUT if you only wish to develop games you might start finding that some of the stuff some CS programs offer you is rather dull or perhaps not but still a waste of time(However some classes are really useful, but I have still not used my Turing machine knowledge ). And even your life become rather borrowing after some time in this very safe job position after graduation.

I'm one of those people who went into computer science to become a game developer but ended up doing a completely different job (military computer scientist). "Game Dev" is like the gateway drug into other development jobs. But, game dev certainly isn't the most interesting dev job of all the available jobs (from an engineering perspective). There's just SO many fascinating jobs out there!!! You've got cryptography, virtual machines, distributed computing, artificial intelligence, database systems, low level assembly code for hardware platforms, operating systems, fractals, scientific simulations and modeling, network coding, robotics, mobile devices, etc. Development is like having a big pile of legos in front of you, waiting to be built into all sorts of interesting contraptions. The field of game dev is certainly interesting, but it's like spending all of your time building space ships out of legos (which is cool!) but there are lots of other very interesting things to build too!!! You might like legos and you might like space ships, but if you go to a school which shows you only how to build lego space ships, you're doing yourself a disservice by missing out on all of the other cool things you could build. A good CS program can introduce you to all of the other possibilities available and arm you with the basics to get started (95% of your post-CS education is learned on the job).

#4953292 Realistic strategy game?

Posted by slayemin on 27 June 2012 - 05:23 AM

I used to be in an artillery unit. We had a battery if six howitzers in our company and about 150 marines. Our unit was composed of the following:
-Supply: Takes care of guns, beans and bullets.
-Gun Line: The crew running each howitzer
-Fire Direction Control (FDC): The section which calculates the needed powder, rounds, fuzes, tube elevation angles, and tube lateral angles to put a round on target.
-Forward Observers (FO): These guys are the target spotters who communicate to the FDC about what they see on the battlefield
-Comm: These guys run wires between all of the sections and maintain radios and antennas so that everyone can talk
-Local Security: People patrolling the perimeter to make sure nobody is trying to sneak in
-Command: The officers who decide when the unit moves and where the unit moves

Not in our unit, but available assets:
-Counter-battery radar: Spots the trajectory of a round in flight and calculates its point of impact and point of origin to a precise grid coordinate
-Signals Intelligence: Listens to the airwaves and triangulates the position of a broadcasting station

So, you could make a more realistic "artillery" game by adding all of these elements. If you shoot the FO's, then the artillery unit no longer has eyes. If you shoot the FDC, the artillery loses its brain. If you shoot the comm, the artillery loses its mouth and ears. If you shoot the gun line, the artillery can't shoot anymore. A functioning artillery unit works like an oiled engine, and if you take out any of its gears, it seizes up. So, imagine you've got a forward observer attached to a company of infantry in a vast battlefield. An enemy sniper spots the dude with a radio strapped to his back and shoots him first (they have one of the shortest life expectancies in a fight). The FO is dead. Artillery support is out of the picture. If you wanted to play a game of artillery vs. artillery, it's now broken because the system is so fragile.

Suppose that you and your opponent have counter-battery radar. You don't know where the enemy artillery is positioned and they don't know where you are. The first person to shoot their guns reveals their position, so you want to make sure that you're shooting to disable the enemy artillery before they can shoot you. A round can have a flight time of up to two or three minutes, depending on angle and distance. This is more than enough time for a good artillery unit to shoot back. So, two emplaced artillery batteries facing off against each other will be a contest of training, response times, and who can move out of position the fastest.

This realism doesn't make for much "fun" in a game. Most artillery games are much more simple where you've got artillery cannons facing off against each other and you have to make a guess at the needed power and elevation. The game has abstracted away the complexity, added some simplicity, broke some reality (vision), and made the skill element of the game the "FDC" (which in reality is a precision science with little guessing involved). So: "Reality/realism" is not necessarily "fun" and "fun" is not necessarily "reality/realism".

#4951780 Dedicating my whole life to creating my dream game. Going to college

Posted by slayemin on 22 June 2012 - 11:08 AM

Are you really a jack of all trades, passionate for each facet of game development?

As someone who is beginning to identify with this, does that work for or against me? (consider I want to start my own company eventually, even if it's in handing out flyers)

I'd say that it always works in your favor to know how everyone else does their jobs. This helps you work better with your counter-parts and prepares you to become a good project manager. It's also good to have a good mastery of a particular skill since that helps you have a specialty and deep understanding of how it works.

#4951688 Dedicating my whole life to creating my dream game. Going to college

Posted by slayemin on 22 June 2012 - 04:31 AM

Also, make sure you have general Computer Science knowledge as well, because what happens if you don't get hired as a game developer straight out of college? You can work QA for god knows how long until someone notices you OR you can become a Software Developer at first and make good money plus earn development experience, and then go home and work on your game until you go to sleep at a reasonable hour (while eating 3 square meals a day plus some snacks).

I think this is worth emphasizing. I would recommend avoiding the "game development" curriculumn. Colleges and universities realize that it is a very popular track, so they advertise it strongly to gain new recruits. Instead, go for the more generalized CS track and use game development as a side project/hobby to keep yourself excited by what you're learning. Work on your games, use the things you learn from class in your game (data structures, algorithms, etc), use the challenges you face in your game dev to ask questions in class, and if you work hard and do things right, you'll graduate with a degree and a polished game in your portfolio.

The hard truth is that just about every university is pursuing the "game design" track because it's popular with students and brings in new recruits. Assuming that they graduate hundreds of students with a degree in game dev, and there are a hundred universities doing this, then you can safely assume that the market for game developers is either over-saturated or the degrees aren't worth much. It's statistically unlikely that most students will become game developers. Game dev is a niche skill, so if it ends up that you're not going to be doing game dev, then the degree isn't going to work very well for you in opening up other career paths. What's your backup plan if all you have is a game dev degree? Take the pragmatic approach: With a more generalized CS degree, you could land a well paying job in a much wider field and it will still be highly relevant to game dev if you choose to go that route.

There's another thing to consider: Game development (in the broad sense) is about more than just writing code. Every game needs art assets, sound, designers, marketing, business infrastructure, project management, etc. You can do any of these things and be a part of the game industry. If you're focused on the programming aspect, make sure that you both like programming and like mathematics. If you don't like programming or math, then when the initial appeal of game dev wears off, its going to be "just another programming job" where you happen to make games instead of desktop applications/widgets/services/drivers etc. At the end of the day, regardless of whether you're making games or other applications, your job is staring at code on a screen and making it do things.

#4948927 Game Crap

Posted by slayemin on 13 June 2012 - 02:30 PM

I think the best way to get replay value out of a game is to design it so that you can accomplish the objective by using multiple strategies.
"A game is a series of interesting choices" -Sid Meier
The more "weird" the strategy, the more interesting it is to me.

The problem with some RPG's and some FPS's is that the story line is linear and character progression is also linear. The linear nature of those games puts arbitrary restrictions on what strategies you can use and usually one particular strategy is whichever is strongest. Strongest strategy is not necessarily the most interesting strategy.

I like to think of "Magic: The Gathering" as a very well designed game. It's got tremendous replay value because of its versatility. There are TONS of interesting ways to defeat an opponent. My favorite strategy is to make my opponent draw dozens of cards at a time causing them run out of cards. If you run out of cards, you lose regardless of your health. It's just so weird and unexpected.
When I played Starcraft 2, my favorite strategy was to play zerg and mass queens, spine crawlers, and overseers. It's another weird and unexpected strategy.

So, I'd say that to really get the best replay value out of a game, you have to introduce lots of mechanics which can be combined in very interesting ways. Some games just don't lend themselves very well to that. An FPS can only introduce a few different types of guns, which mostly do the same thing: Shoot stuff in different ways. The "replay" value from an FPS comes from the twitchy skills it takes to shoot quickly and accurately and competing with those developed skills against other players. It's moderately interesting, but doesn't require a clever mind to thrive at it.

#4948126 Octree adjacency information

Posted by slayemin on 11 June 2012 - 05:54 AM

One other advantage of QuadTrees and OctTrees is that the search time is logarithmic rather than exponential.

Here are some ideas you could try:
-Array grid could contain the smallest allowable blocks, and larger irregular blocks are composed of lots of smallest blocks.
ie, smallest block would be 1x1. A 1x2 block would be two 1x1 blocks linked together. You'll have to create four "connectors" for each block object (left, right, top, bottom) which point to attached neighbors.

-OctTree Method: Find the adjacent blocks when you're construction the octtree and put that data into the node. Figure it out conceptually before writing the code.

#4937590 Distance to collision in AABB world

Posted by slayemin on 05 May 2012 - 06:36 AM

It'd probably be easier to help you correctly if you gave some context on why you need to find the nearest collision along a direction.

I'm going to assume that you're using this to create a coarse and granualar collision detection check. The coarse check would be to perform a distance calculation (somewhat cheap, even with a square root in there). The granular check would be more expensive because you may have many AABB's to check.

My idea is to use a bounding sphere. The center of the sphere is at the center of your cube volume and the sphere radius is the distance to a corner (so that you cover your farthest point). Now you have two or more bounding spheres and the orientation of your AABB doesn't matter. The calculating distance between the bounding spheres is pretty easy: Just measure the distance between the centers and add both their radiuses to the distance. Loop through every collidable object in your game and store the one with the shortest distance.

It'll be an ugly O(n*n) loop though, so if you start to get a lot of objects and slowdown, watch out.

foreach(CollidableObject obj1 in CollidableObjects)
	 float shortestDistance = infinity;
	 foreach(CollidableObject obj2 in CollidableObjects)
		  if(obj1 == obj2)	 //self reference check

		  float Dist = MeasureDistance(obj1, obj2);	 //<--your function to measure distance

		  if(Dist < shortestDistance)
			   shortestDistance = Dist;
			   obj1.NearestObject = obj2;

If you do start having a lot of collidable objects in your game and its causing performance problems, look into quad trees(2D) or oct trees(3D).

#4920148 GPGPU in a local network

Posted by slayemin on 07 March 2012 - 12:51 PM

When you're writing you algorithm, make sure that you're measuring the performance of your distributed work. I once wrote an algorithm which distributed work out to multiple CPU's and broke the work down into very small increments. It turned out that while the work was done quickly, the overhead of the network latency caused the overall time to complete the job to increase (~1 minute). If I made the jobs bigger, the computers could spend more time doing work on the CPU rather than sending and recieving network packets, thus decreasing working time to about 15 seconds. There's a probably a sweet spot for every algorithm where you maximize the work and minimize the time taken.

For what it's worth, the university I was at purchased and used an NVidia card which had a ton of processing power. I think it was the tesla? I don't know what the price tag looks like or how to use it, so I can't make any recommendations from experience.

#4918667 Game Save Data

Posted by slayemin on 02 March 2012 - 12:51 PM

I like the idea of encryption :)

You could use the Ceasar Cypher: When you're encrypting a bit, add a fixed value to it before writing it to file. If your addition value is +2, then A => C. It's super simple to implement and its also pretty simple to thwart. You could make it slightly more complicated by using a pseudo random number generator to generate your fixed values. The key is that the sequence of random numbers needs to be the same every time. So, if you generate a random value between 1->26, and then add that value to your byte, you'd get something like:
Unencrpted string: {AAAA}
Random Numbers: {13, 21, 4, 16}
Encrypted String: {A+13 => N, A+21 => U, A+4=>D, A+16=>Q}

So, if someone knows that their health is 16 and they open up your file to look for that value, they won't find it :) But, if they are really determined and reverse engineer your code to figure out what encryption algorithm you're using and the random number seed you're using as a key, then they can easily decrypt and encrypt your saved data file. I'd probably not concern myself with the 0.01% of the population who might do that.
If you want to use a nuke to hammer a fly, you could look into using AES 256 bit encryption. Nobody will crack that without extreme effort and hardware. It's military grade :)