Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Offline Last Active Today, 03:00 PM

#5292834 Hololens Development

Posted by slayemin on 22 May 2016 - 01:54 AM

I've had the rare privilege of being invited by Microsoft to participate in the worlds very first holographic hackathon this weekend. I thought I'd share a few quick notes and thoughts so far:

Mind blowing stuff:

-The hololens is able to recognize voice commands. You can say, "Cortana, record this." and it will start taking video feed recordings!

-It has NO wires. The thing is a mobile computer which is strapped to your head. Take a minute to think about that and let it sink in.

-You can use three hand gestures to create user input commands

-You can place holograms on top of tables and on walls. How freakin' cool is that?! This is done by 'spatializing surfaces'.

-The devices uses cameras and infrared lasers to visualize your environment geometry and generates meshes. The advances in computer vision alone are mind blowing.

-The glasses are rendering at 240 frames per second!!! If you thought the 90 FPS for VR was high... lol


The unexpected stuff:

-Developing for augmented reality is about three times harder than for virtual reality (especially when it comes to design considerations).

-Augmented reality development is NOT the same as virtual reality development. VR is more focused on immersion and presence, while AR is more about layering extra information over the existing world. I can't stress how important this fundamental difference is between the platform types.

-The field of view was disappointingly small (think of looking at the world through a 15 inch monitor)

-The glasses use additive light to create holograms, so you can't draw dark colors such as black! That's just... invisible!

-The magic of AR is being able to keep a hologram stationary even though the observer is not

-It's designed for indoor use

-It can't handle non-stationary objects very well. Definitely don't take it out to sea.

-Dark surfaces and reflective surfaces will not give good results

-People are finding use cases for AR which not even science fiction writers could have envisioned (such as someone remotely using a tablet to draw in your view port as they see what you see, called 'telepresence')

-It's not going to work as well in cluttered and messy environments because all that junk is going to get turned into triangle meshes.

-A lot of the hardware design decisions were made to preserve the battery life of the device (laser pulse frequency, camera resolutions, screen size, refresh rates, cpu, etc).


The disappointing stuff:

-It only works with Windows 10, not Windows 7. (clarification edit: Your developer machine has to be running Win10, though I haven't tested this to be 100% sure.)

-At this point, only Unity3D supports it. No UE4 support yet :(

-Debugging is really hard, if not next to impossible because you deploy out to the device. This slows down dev iteration cycles.

-I need to get a lot more practice with AR if I'm going to be any good at it in the future



Final thought: The hololens is VERY impressive from the technical standpoint. However, it is also the first generation of hardware for this type of technology. It is the worlds first high quality mass consumer market ready device which is capable of rendering holograms on top of surfaces. I expect that the technological advances will increase rapidly in this area within the next 5 - 10 years. I think there are a lot of very interesting problems which Hololens could solve, but the solutions for it can't just be solutions taken from VR and ported over to AR (see: fundamental difference in objectives).

#5292143 Game Prices on Steam: should there be regulation/guidelines?

Posted by slayemin on 17 May 2016 - 02:19 PM

One thing I've learned from selling stuff: The price of an item is not the value of that item.


A hair clip costs $0.30 to make in China. We can then sell it for $10-15 in America. Profit margins may appear to be high, but so are overhead costs (booth fee, transportation, food and lodging, time and energy, etc). Yet, people buy hair clips; It's something they like and want, solves a problem, and makes them feel pretty and good about themselves.


Almost a decade ago, I sold Cutco Knives to people. A full set went for about $750-800. "How will I ever convince people to pay that much for knives?!" I wondered. "Isn't that too expensive?" I found out the price doesn't matter.

With every sale, you're playing a juggling act. You've got the PRICE which you're asking for the item, and then the potential customer has the PERCEIVED VALUE of that item. If Price > Perceived value, then no sale. If Price < Perceived Value, then sale! A sale is ALL about the pitch. The art of sales is to increase the perceived value above the asking price.


When I did computer services for people, I hated it and wanted to stop providing my service. My strategy was to double my rate to $60/hour so that people say, "That's too expensive, no thanks!". Instead, it backfired. I got more business! Why? Because by charging higher rates, people thought that I was worth what I was charging. The high number increased my perceived value! Whoops! But, it also works in reverse! If you sell an item way below the perceived value, then the perceived value is also lowered!


So, what do idiot people do when they suck at sales and want to sell something? They drop their price instead of trying to increase the perceived value of their commodity! But, does it matter to others? I would argue "No! Not at all!". It doesn't have to be a race to the bottom as you guys might fear, it just means you have to create a compelling pitch about the value of your game and why it's worth the money you're asking for. We could build a compelling pitch for most decent games selling for $2 and get people to pay $10. Oh no! Sales volume drops! Okay, suppose the volume of your sales drops by 50%. Instead of making 1,000 sales for $2, you make 500 sales for $10. The 1,000 sales gives you $2,000 but the 500 sales gives you $5,000. Now, do you want sales volume or sales value?? Even if your sales volume dropped to 20%, or 200 sales, you'd still break even. You increase your sales volume through marketing and compelling sales pitches, NOT by dropping your price. That's generally an amateur move. Don't think your game is worth $10? Well, your opinion on the value of your game doesn't really matter. If it helps you sleep better at night, maintain high production values throughout the development of your game! At the same time, stop undervaluing yourself!!!

#5290899 Getting objects within a range (In order, fast)

Posted by slayemin on 09 May 2016 - 05:45 PM

As others have said, a dictionary is the wrong container. The huge glaring issue you will run into is the edge case when two objects are exactly the same distance apart. Then you have a key collision.


I'd at least use an array. If all you care about is having objects sorted by distance from the position, the objects can be inserted into the array in sorted order. To save on CPU time, you should also not use the distance itself (which has a square root in the calculation) and instead use distance squared.

As others have said, octrees may be the right call for you here. I wrote an article on octrees a while back which may be helpful.

However, to be truly helpful, you could elaborate more on what problem you're trying to solve. Your current solution might not be the best solution of the available solutions at your disposal :)

#5286518 linestrip flickering

Posted by slayemin on 12 April 2016 - 01:48 PM

If you add in a static mesh and render it, does that also flicker?

#5285894 Community College or Game Development?

Posted by slayemin on 08 April 2016 - 02:17 PM

First off, an introduction!


Hello everyone! I've stumbled onto this site recently and decided to join so I'm completely new to this community. :)


Just out of curiosity, I wanted to get an idea of what you guys think think of the current situation I find myself in. First off, I want to make games. I've always wanted to make games ever since i was a child. I'm currently 19 and am going to Community College, working a part time job, and developing a game I plan to release on IOS and Android this summer. I've been developing this game whenever I can find the time for the past 2 months and I believe it has a lot of potential. As much as want to keep developing and spending more time on this project, I feel like my education is holding me back. So that leaves me to my big question...


Should I leave College after this semester to work on my project full time?


I know education is important but wouldn't it be easier to get into this industry with a 100% completed project rather than any kind of degree? This semester in itself has been tough just because I try to make time for my game rather then studying and my grades show that. I've been thinking about this for awhile now and I would definitely appreciate some advice from people currently in the industry.  :P


Education doesn't hold you back, a lack of education does. 


Use your passion for game development to fuel your studies. Got a boring math class? Figure out how you can use the math material being taught in game development. Got an english class with lots of writing? Figure out how that can help you write better stories and narratives for your games. Got a team project? Use this as training to learn how to work with and communicate with other people -- that is also a skill which gets used every day in game dev. I guarantee when you start taking this approach to education, trying to relate the material you're learning to the material you're passionate about, you'll get passionate about the material you're learning.


Also, don't be an idiot. Your priority should be school and studies first, game development second. Study hard and master the material you're being taught. Don't just try to pass a final test and do a brain dump afterwards, try to add the learning to your list of skills. Think of it like leveling up skills in an RPG -- max out those XP gains! Would you rather be a level 10 game developer or a level 2 game developer? Stay in school. Work hard. Stay focused. Work hard. stay motivated. work hard. Keep at it. You'll get there.

#5285892 Is it good practice for game development to learn multiple languages?

Posted by slayemin on 08 April 2016 - 02:02 PM

I think programming itself is language independent. Programming is fundamentally the ability to create a series of logical instructions, often utilizing mathematics.


A programming language, much like a spoken language, is a form of expression of the intended thought. Learning a new language can give you new insights into how to express your thoughts, but they don't necessarily make your thoughts better. That only happens through practice with the intent to improve.


I am pretty good at the language independent programming stuff. I can pick up another programming language in a few days and become reasonably proficient (excluding joke languages like Malbolge and brainfuck). The thinking process is "I want to do this action ten times, how do I create a for loop or a while loop, or repeat this series of instructions 10 times in this language?" After that, it's just a quick lookup of language syntax and I'm on my way.

#5261242 How hard it is to live from games as indie developer?

Posted by slayemin on 09 November 2015 - 04:58 PM

You're not ready to be a game developer. Especially not an indie game developer. You can try, but I think that at this point, you will fail and that would only discourage you.

You should start by focusing on getting the skills it would take to become employed at a local game company. Then, go work for one for several years. Figure out the work flow for each job. Figure out how the software development life cycle works and where you fit into it. By working in a bigger studio, you can get really good at a specific part of game development (AI programming? Environment art? animation? etc). When you can do a lot of it well, you may be ready to become an indie developer.

One thing that you absolutely MUST be able to do is work well with other people!!! I cannot stress this enough. No wildly successful game is ever made in a vacuum by one person slaving away in a basement for years. You'll have co workers. You'll have business partnerships. You'll have to talk to customers, and marketing people, and everyone under the sun. At your current job, I would take it as an opportunity to develop yourself and focus on getting better at working with other people. Figure it out. How do you communicate most effectively with your coworkers? How can you lead an effort? How do you get people to see your point of view and follow you? How does your existing employer make money? Why does the business work?

If you want to be a game developer, it's going to take a huge life commitment from you. It's going to take years and years of dedicated training and work, and it won't pay a lot. But it'll be fun, and I guess that's why most people want to get into it.

#5247270 Terrain LOD

Posted by slayemin on 17 August 2015 - 04:30 PM

Yeah... some of these ideas are not very good. You only load the terrain once, and that's at level initialization time. If you're pulling the height information from a height map, there's no reason why you can't just set the exact world coordinates for each terrain vertex. If you do this for every frame inside of the vertex shader, your GPU is going to be doing a lot of unnecessary processing work which could just be avoided by placing the XYZ coordinates at load time. Multiply that by every vertex in your terrain, and its going to add up.


The same applies to vertex normals. There's no reason why you can't just get this info at load time and store it in a custom vertex object for each terrain vertex. In fact, if you're going to be creating a height map texture for your terrain, you can also create a normal map texture for your terrain.


You're making 3D terrain. You don't use quad trees for 3D environments, you use octrees.


To avoid the T-junctions, you want to use skirts. The LOD level of a terrain chunk should NOT be influenced by the LOD level of an adjacent terrain chunk. In my terrain system, I had four LOD levels, and I had to be able to skirt lower LOD's to higher LOD's. Check out this wireframe to see what I mean:

Attached File  TerrainLOD.png   1.28MB   7 downloads

#5246540 AOM

Posted by slayemin on 14 August 2015 - 01:13 PM

I mean like programming language and graphics like opengl or what...

Doesn't really matter what programming language or graphics API was used. Whether they used C++, ASM, Java, C#, etc, doesn't matter. They could have made the game in any language. Likewise for the graphics API -- whether they used DirectX or OpenGL, doesn't matter. They figure out how to make the right api calls to do what they need their game to do. I like to think that game development is somewhat implementation agnostic.

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

Posted by slayemin 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 slayemin 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 slayemin 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 slayemin 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 slayemin 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 slayemin 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!