Tackling a project

It's time to take a new path from now. 2 Exams left and I'm close to a free gamedesign project. I have a dozen of cool project ideas (including very unsual, experimental concepts), but I want do create something stable. Something that uses typical structures, simple alghorythms and such standard things. Ok, looking at my notebook I assume the "physics-based realtime 3D roguelike" mostly fits there. It's not really 3D, more a threedimensional map, 2D-viewed. Several months ago I wrote a little prototype and it was cool to look at. I haven't had the time for finishing, therefore I overworked it for simplicity. Not a real roguelike, it's similar to Ubisoft's Dark Messiah Game, only in ASCII and totally random. I'm trying to make an interesting system of rules and then manipulating it by random generation, mutation factors and so on... Let's look if it's worthwhile!



wikiHow is awesome. Are you still waiting? Go and learn!


Centered Boxes

Kick all kinds "sub-bounding" boxes - I found a better way for collision detection. At the moment I don't need intersection points, therefore I focused on pure collision detection - pure boolean output. I found out that a line's/rect's center point is one of the most important positions ever in pure positional anlysation. Take two lines, create their center points, check for right proportions/positions and you have a collision detection. So far it worked with almost every line I checked - It needs two divisions to calculate the center points, the rest is logic. Yeah! That's what I wanted to have. A simple, mostly logical representation of intersection detection with lines.

Why is it so easy atm? I'm sure I've forgot to include a very special condition or somewhat... Everytime the same shit. You've got an idea, tested it several times... fine. And then you found the ultimate big fat error ruining your discovery.

I'm on lastFM!!!

I haven't even noticed it! Also, I don't know who was it. But thats fine - I uploaded some tracks of mine. Just take a look at lastfm.com and search for "Exocore".


Bound of boxes

I love bounding boxes. All you have to do is to check the bounding boxes of two objects... If we extend that system to bigger constellations and geometric forms, we can create entirely complex patterns of collisions and geometric constructions... I tend to avoid the use of pixel-perfect math for collision checks in game programming. They're slow and it's not really necessary to have a perfect collision. If it's a first person game, I totally agree. But if it's a kind of action adventure... I disagree. I don't need uber-perfect collision routines for normal games. Most collision stuff here can be done in an approximating way, therefore bounding boxes. An alghorythm I wrote is to seperate bounding boxes into groups of smaller boxes inside the bounding box. This way is (for example) useful to check a broad collision/intersection between 2D lines or even polygons. You just check the outer boxes, going further with inner boxes n times... the more depth, the more accuracy, the less speed. But atleast more speed than using normal math stuff. I'm looking forward to extend that method for 3D use, circles and some other forms. Circles are pretty complicated to check... You need to analyse possible inner box combinations with logic operators, preset box patterns... Very analysation-heavy and non-school-mathy.

And it's also pretty non-standard. I wonder how far bounding boxes can go without loss of speed.


Music, music, music

Today is a good day! Mostly, because I managed to upload a lot of last music stuff. I remastered all of them +/- some details to ft the overall experience. Enjoy!

"Things I Had To Do In The Past" (album)

Soulshaper (single track)

Also, don't forget to check the other shit floating around in my head at mp3.de.


Today is a shit day

That's true. First april is pretty much a day whose inventer may be a personal enemy of mine. Except the overall sillyness of today, I had a horrible discussion with a classmate about math and programming (yeah, it's such a topic).

He argued every programmer needs to love math and I totally disagree. Math is might, we all no that. But math isn't the key to be a good programmer. Math is the base and should never be a programmer's love. Why? That's simple: If I would solve my programming problems mathematically - less logically - my PC would need much more time with an accuracy the solution would never need. Warp back to the days of early programming where big math wasn't possible. You needed to know how a computer can think, not how we could teach him to think. If you try to tell your dog a story about how important it is to cross the road only when the traffic light is green, he would wonder what the fucking guy infront is talking about. And he may get it after a while of explanation (say hundrets of years if you expect an answer!). I say this is the "math" way - exact derivation. The other way to tell your dog what is important is by teaching him organicly: trial and error. Give him a dog biscuit if he's right and will learn a lot faster and direct. If you tell your dog a story, he'll need to learn your language, your world view and your experience. Exporting the dog lessons to a programmer's problem... we wouldn't use the most accurate methods with an army of float divisions, but the way that is more common to the computer's way of execution: Logic, bit shifting, bit masks and other neat things. I don't refuse the use of math, but most problems can be solved very efficiently with alghorythms instead of math. OK, scientific stuff is another base, but I talk about everyday programming needs, not about specialized stuff. But even specialization can get avoided! Think about geometry. I wrote several routines for collision detection, area calculation and stuff mostly on a logical base. A few geometrical analysations and you can say goodbye to school maths.

Seriously, math is not the ultimate thing a programmer should love. He should know about it, how to use it and how he get advantages of math, but loving it is the entirely bad way. You will use things you love and a programmer loving math can make the whole thing overcomplicated and less effective. Surely, there ARE exceptions out in our world, but I can't see a lot of them.

Love programming, not maths!