Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Feb 2001
Offline Last Active Yesterday, 01:59 PM

#5217143 Using octrees for spatial representation

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

#5208265 2.5D Dynamic LOD Voxel Renderer

Posted by slayemin on 02 February 2015 - 02:45 PM

I've seen the euclidean thing, And as far as i can tell, It doesnt really support dynamic lighting.

I dont neccessarily need the engine to run in real-time, but closer to something like a beefed up blender "cycles"

As well, a huge part of this is expected to be working on the hardware side, as well as the soft side.

Based on what I can gather from your stated requirements, you'd get the most bang for your buck by just writing HLSL shaders and taking advantage of instancing.

You don't *need* an external USB device and you don't want one either! Problems:
-How fast is the communication link between a USB 3.0 device and the CPU? Very slow (relatively speaking).
-If you use specialized hardware, you put that hardware requirement on your end users. That's going to add a big barrier for entry for people who want to play your game. This brings up a question you need to answer for yourself: is this a hobby project or do you want to release this commercially? If its a hobby project to "learn", then what's the value in learning something you won't be able to use in the industry? If its a hobby project to just have fun and play around, you can do whatever you want.

-A GPU IS a super computer which does things in parallel very well. All you have to do is send it the data you want it to do operations on, send the instructions, and let 'er rip. Rendering millions of voxels with dynamic lighting would be childs play for most modern GPU's. Who needs an external USB device?! Harness the power of that GPU, it's begging you to take advantage of all of its raw processing power.

#5207519 Programming

Posted by slayemin on 29 January 2015 - 02:29 PM

Perhaps I wasn't very clear, seeing L. Spiro 's comment, I'm not the programmer for this game, I simply planned the entire game and have basically everything written down for it, like research towards stuff that will be inside the game, information, what will be in the game, game mechanics that should be implemented, realistic things like pollution and such, how people calculate certain things in real life, resources, biomes, basically everything that a Writer for a game is suppose to do. I just felt, that learning how to program would be cool. I only suggested that I learn programing because I really don't have anyone at the moment to program. I could surely find someone if I really threw myself out there, but I really only have talked to people I've known for a long time because I trust them, I'd rather not rely on someone I don't trust. I just figured if I learned how to program I could help. That is all, that's for your guys responses.


I don't really plan on posting this game for money or for fame, me and my friends really just wanted a game for ourselves to play, seeing how there isn't really a game that grants us everything we desire, so we figured, why not have fun making something of our own to enjoy and for ourselves instead of playing pointless games on the internet that don't offer us everything we want.

Let's put it another way...

You have come up with an ambitious design to build a sky scraper. You've gotten a few people to help you decorate the interior and paint the exterior, but now you need construction workers and steel workers to actually assemble the sky scraper. You say, "Well, I can't find any right now but I think construction sounds cool. Maybe I'll start building this sky scraper myself! Oh by the way, I've never even built a dog house."

Then you say, "Me and my friends aren't really planning to rent the sky scraper out to tenants to make money, we're just doing this for fun." That doesn't negate the fact that its going to take a shit load of work to build the thing in the first place.

L.Spiro's advice is 100% solid. Start super small. Build the dog house before you attempt anything larger. The dog house sized projects may seem trivial, but they're essentially like the game programmers version of "hello world". It shows you have the necessary project management skills, workflow, and dedication to see a super small project through to the end. The risk of failure is minimal and shows you the areas you need to work on before taking on bigger projects. Once you've got a solid grasp of what it takes, you can move on from the dog house to human houses, then from human houses to small office buildings, and eventually to sky scrapers. Building huge projects are not solo projects, they require a team, and teams are all institutions which require a working team infrastructure which gets developed over time and with experience.


Yes, you should shelf your current project. It's not possible with your current resources. Shelving it doesn't mean you throw it away, you can always pick it up later when you DO have the necessary resources to make it happen.


There are also some project management issues which will come up but you may not know about them yet: Cost overruns and schedules being missed (which are hard to foresee). If you can only support a project and its expenses for two years but in practice it takes three years to complete, your project will fail. Even if you aren't paying your staff, the real "cost" I'm talking about is the cost of motivation and morale (money helps increase this, but isn't the only solution to incentivize people to stay motivated for the duration of a project).

#5207508 2.5D Dynamic LOD Voxel Renderer

Posted by slayemin on 29 January 2015 - 02:02 PM

Well, I suppose that if Euclidean can figure out how to do a ridiculous amount of rendering on the computer using trillions of voxels, you shouldn't have too much to worry about. Check out their latest video of their tech.


Conclusion: The performance you will have depends mostly on the algorithms you choose.

#5206327 Question about local axes conventions

Posted by slayemin on 23 January 2015 - 09:04 PM

When I was writing my own engine, I considered (1,0,0) to be the forward facing vector because it makes the most sense from a trigonometric standpoint. 

#5205613 Site for Code Discussion

Posted by slayemin on 20 January 2015 - 01:47 PM

This may be completely ridiculous to point out for this exercise, but you are also not checking the "number of times" variable to make sure that its actually a number. What if someone types in "asdf" instead? Then the Int.Parse() method would crash your program. So, you'd want to put that in a Try/Catch type block. I know you know to put in numbers, but if you ever build software to be used by other people, then you can't trust them to put in the correct types of input. Maybe its silly for this exercise, but its good to start getting into the habit of thinking about how people could intentionally mess up your code / program.

#5205376 Site for Code Discussion

Posted by slayemin on 19 January 2015 - 02:12 PM

Looks pretty good to me.

Changing the if/elseif to a switch statement in this case is unnessary. It would totally be a case of premature optimization and only make the code slightly less readable.


The only thing I'd say... for the sake of learning code, avoid using the Array.Reverse() method and try to do it manually. 

Also: what happens if someone wants to print their names -1 times?

#5204622 How to actually learn game development?

Posted by slayemin on 15 January 2015 - 08:25 PM

I'll have to disagree that programming is hard. A program can be complex, but not necessarily hard.

I'd say start with a game engine that doesn't require as much work on the textual side at first, so that you can get a good idea of what goes into making games in general (sound, graphics etc). Something like Scratch or GameMaker.

You will see results, and you will also see if it's really the programming that is holding you back (and not laziness, or the lack of focus.)

Without focus, no matter how simple the tool makes it, you still have to understand your own idea well enoug to create it using the "tool" that is programming.

It's not the programming that's hard. It's finishing the big project you're working on.

To put it another way: Running itself isn't really that hard. But running a marathon is.


Your advice is good -- start by trying to run a mile and get good at that, and slowly increase how far you can run. Eventually, you can run marathons if you stick with it and push yourself.

#5204533 How to actually learn game development?

Posted by slayemin on 15 January 2015 - 01:25 PM


I'd do this for a week, and then stop and pause and look at what I'm doing with my life and conclude that it's being wasted. I'm wasting time. And then I'd get disappointed in myself and want to do something better with my life. That's a fleeting feeling though, and soon I'd dive right back into the games and videos. It's all I did. Anybody would eventually get depressed if they just did that and only that (money is irrelevant here).


Off of the OP's topic for one second.  How do you make money to survive by playing games and watching youtube?  That doesn't sound bad to me.  Sounds like heaven.


You don't. You save as much money as you can while you're "officially" employed and when your job ends, you have to live off of those savings until you make more money. You can stretch the savings account by investing the money, but that's always a huge risk, where you may lose the money as well. It never feels good to lose money you can't afford to lose, but it's a relief when you get money to buy you more time. It sounds nice, but it gets old.

#5204338 How to actually learn game development?

Posted by slayemin on 14 January 2015 - 05:25 PM

I can understand the depression bit. I think I've been there a bit myself. I can't speak for you, but here's what was happening with me:

I'd spend every single day in front of the computer, playing video games or watching youtube videos, and alternating between videos and games when one gets more boring than the other. I do this until I am completely and utterly exhausted, usually some time at around 4am or 5am. If it was summer, the birds would start to chirp before the sun comes up and that would be my cue to go to sleep. I'd do this for a week, and then stop and pause and look at what I'm doing with my life and conclude that it's being wasted. I'm wasting time. And then I'd get disappointed in myself and want to do something better with my life. That's a fleeting feeling though, and soon I'd dive right back into the games and videos. It's all I did. Anybody would eventually get depressed if they just did that and only that (money is irrelevant here). I mean, there's more to life than video games and youtube. You don't want to realize a decade later that your last ten years were a blur, right?! That'd make you feel even more depressed and hopeless. But here's the thing: video games, youtube videos, netflix, etc are just a default habit, it's something you do when you don't want to try to think of something else to do. I mean, you *could* spend 30 minutes figuring out a good project to work on and get into, or you could just fart around on the computer. We human beings tend to take the path of least resistance, we're lazy. If we always take the easy road, we get fat, stupid and complacent in life. If you really want something, you have to work for it. There is no shortcut. Want to get stronger and in shape? Gotta lift weights and eat well! Want to be better at mathematics? Time to crack open a few math books and start doing some practice problems. Want to get great at painting? Break out the paints and start painting. Want to get good at game development? Start making games at your skill level. Want to get good at wood carving? Break out some wood and get carving. You'll suck at first. Everyone does. But don't be a critic on your talents in comparison to others, instead, focus on how awesome this thing *YOU* did is. YOU figured out how to do it all on your own, and you did it! All on your own. Its rewarding. A big part of the reward in all of this is your own personal discovery. Even today, I'm discovering new things for myself which are probably well known to everyone else but me (example of something I learned today: If you take two line segments of any triangle and draw their perpendicular lines at the midpoints of each segment, the intersection point is the same point as the third segment you didn't draw!). Who cares if other people already knew this or that, or mastered something I'm a novice at. It's new and hard for me! What's funky is this...believe it or not, it's actually more fun to NOT play video games, NOT watch youtube videos, NOT watch netflix or TV, NOT do the default goto behavior/habit, and much more fun to spend time working on your own projects (whatever they are). Yeah, it's hard work. Yeah, it takes effort and exertion. It's just as hard as hiking up a big mountain every day. I can tell you to do it, and tell you about the view from the top, but you have to climb the mountain for yourself if you want to see the view. Nobody can helicopter you to the top. That means putting one foot in front of the other even though your body and mind is telling you that you don't want to. A lot of people dream about seeing the top of the mountain (figuratively) but never take the first step to even try. A lot of people take a few steps, see its hard, and give up. Some people take a bunch of steps and die on the trail trying to get to the top. And some people overcome all of this and reach the summit. Clamp down, fight yourself, find that grit, and steam roll any obstacle that gets in your way with hard work and perseverance, every single day. That's the key difference between successful people and failures. 

One last thing about making games: Making games is not even close to the same as playing them. Being good at (and enjoying) playing games is pretty irrelevant to making games. This is a common misconception among young college students who pay bucket loads of money to go to a specialized university which will teach them how to make games. They get there, pay a lot of money ... and then it gets really hard, they have a rude awakening on the level of work required, and they don't know to work hard or want to work hard, and then they get disillusioned, give up and drop out. The school is more than happy to take their loan money and let them wash out. Making video games is a subset of software development, not playing games. Become a great, hard working software developer and you'll do fine in either the games industry or the software industry.

#5204034 Code appearance, is it really important?

Posted by slayemin on 13 January 2015 - 03:23 PM

1) Software programs are never completed. They may be complete for now, but requirements / needs will change over time. That means the program needs to change as well or it will become useless / irrelevant, and you're not going to find a business person who has invested hundreds of thousands to build software that can't adapt to their changing needs. What this means is that someone will need to read and understand the code, the quicker the better, and most often it is not the same person who wrote it. This person is the maintenance programmer. They are angry people. They want to murder people who write bad code. So don't give them a reason to hunt you down.


2) Elegance is simplicity. The principle of occams razor applies. If two competing techniques yield the same result, the better technique is the simplest technique. For coders, this means less chances for bugs, less code to maintain, and usually better performance.


How much effort should you put into writing elegant, simple code? As much as is reasonably possible given your skill level and constraints. It will never be the last time anyone looks at that code.

#5203210 Advice for first mobile game engine

Posted by slayemin on 09 January 2015 - 09:13 PM

The reason I recommend Unity is because it is a mature engine which has multi-platform support, including for mobile games. It also has a pretty big community behind it, so its easy for a beginner to find articles for the help they need. Yeah, it has a bit of a learning curve. You might spend a month or two, or three learning how to use the tool. But take it from me, a guy who wanted to avoid learning a third party engine as long as possible by creating his own engine, you will save SO much time trying to learn another engine / editor. I spent 12-18 months trying to build my own engine. It works, but its not very good. Certainly not good enough for a shippable game. If I wanted to add extra features and capabilities, I could look forward to spending a large amount of time implementing it, and it still wouldn't be nearly as good as the out-of-the-box implementation done by a team who spent many months sweating over the same problems. I'm not talking about adding a function or two, more like "I need to have multiplayer, which requires network code! shoot, that's going to cost me 2-3 months minimum to just get something up and running" vs. "oh, I need to add networking. Let's just look up how to use the built-in engine tools within the documentation and implement it", which would cost 2-3 days. These days, if you are a very small team and want to make a game -- and you're building your own engine -- you're doing it wrong. If you have a huge and experienced development studio which has a track record of shipping many games in the past, it isn't a bad idea to build your own engine (but you should have a really good business reason for that! Such as licensing, technical limitations, or pushing the tech forward).


Unity has multi-platform support, a mature community, and you can try it out before paying any money for it. You can also write C# code to script out any game behaviors you need, so that's pretty handy.

The most viable alternative to Unity is Unreal Engine 4 (which I'm using). You can pay $20/month to get full access to the whole engine, all of its source code, and be making games in no time (or how fast you can pick it up). You don't necessarily need to write code, you can implement game play logic using their "blueprint" system to visually script together game logic. If thats not powerful enough, you can always add in C++ code to supplement your BP code. UE4 also has multi-platform support, but is a bit newer on the market so the community hasn't had as much time to develop and create tutorial content (though some exists).


Picking either UE4 or Unity will give you more than you'll ever need, so choosing one or the other will never be a disappointment. 

#5203151 C# seems good, but....

Posted by slayemin on 09 January 2015 - 02:33 PM

I actively use both C++ and C#.


With C++, you can very easily shoot yourself in the foot if you mismanage pointers or forget to deallocate heap memory. It's one of the biggest sources of common bugs, especially with beginners.


C# and Java try to help you avoid these problems by taking care of most of that backend stuff for you. They both give you a garbage collector which will clean up your unused objects, but you lose control over when that happens. This can cause slight performance issues, but I have yet to see them myself and I wrote a rudimentary game engine using C# and XNA.


What really determines "speed"? I would argue that algorithm choice and implementation design are a hundred times more important than language selection. If you have 10,000 objects in a game world and you need to run collision detection on them, the technique you select is going to have a bigger impact on performance than any slight boost you'd get from using an unmanaged language. In other words, bad code / algorithm choice is much more responsible for bad performance than language choice. Aim for O(LogN) algorithms instead of O(N*N), and you'll generally be just fine. Even C++ will struggle with bad algorithms.


My recommendation: Use C# until you find a really compelling reason not to.