To state the obvious, have you considered turning down the blur so it is a more subtle effect. That will make it less annoying, while still contributing to the overall feel,

Sounds like you are using 4 bytes per tile, not an unreasonably amount. But it can be improved. If all you need is if each tile is full/empty, then you only need one bit per tile, a saving factor of 32 (the edges from each tile are implicit, like Jakob says).

boris: That could work, but I don't want people to get tired of playing it once they get a fast score of S+ rank. After you do that I'm pretty much in the same dilemma I started with.

S+ is meant to be incredibly hard to achieve anyway. Some people will go for achievements, and some will go for speed. Only the mega experts will go for both. So it gives something for everybody. Obviously, if the game is easy enough that S+ doesn't add any challenge, then people will get tired of playing. But if S+ is only barely achievable, then there is going to be much more leeway in improving the times got.

You see lots of games that give a ranking at the end. So the challenge becomes not "how fast", but "how fast while getting an S+ rank". Forces people to concentrate on play style as well as simply dashing through every obstacle. Also, the multiple ranks mean players can choose how much they want the emphasis to be on speed, and on good play.

Why not make a text adventure or actual novel if the drawing isn't your strong suit.

Seriously, don't use Perl. It is true, it is better for text parsing than any altenative. But Python (or Ruby) isn't that much worse, and they do most other things much better.

Yes, proficiency in a scripting language comes up for a lot of these "trivial" tasks. Time spent on one would probably pay off overall. I wouldn't recommend Perl over python to anyone nowadays though.

For this task, shell-fu and editor-fu would have been an even easier choice. When I have that sort of editing to do, I copy-paste the output of dir/ls into an emacs buffer, and fix it up with regular expressions and keyboard macros (replayable recordings). Or sometimes shove it into Excel.

Lookup "heightmaps" too. The game likely stores a list of objects stacked on each tile, and uses that as a heightmap for for player and enemy movement. It's a little easier to code than "full 3d", but you cannot have bridges, arches, caves etc without hacks. And even slopes are quite hard.

It also makes coding the "falling" animations easy - you just look up everything above the destroyed block in the stack, and move it down by one unit.

You don't see this one, 6th from top?

You may find it easier to use the polar functions in gml: point_distance, point_direction, lengthdir_x,lengthdir_y

They cover some of the basic uses of sin/cos and tan, but are phrased in a way that it is more obvious what they do.

Are my posts invisible or something?

Lookup "heightmaps" too. The game likely stores a list of objects stacked on each tile, and uses that as a heightmap for for player and enemy movement. It's a little easier to code than "full 3d", but you cannot have bridges, arches, caves etc without hacks. And even slopes are quite hard.

It also makes coding the "falling" animations easy - you just look up everything above the destroyed block in the stack, and move it down by one unit.

So, just so we are clear, you are "getting used to component architecture" by throwing as much of it as possible out the window, and using a flat script instead, like you might have in any non component architecture.

People re-invent the wheel without having a specific goal of a better wheel, they just need a wheel and don't want to use the stock one. I think that is what the aphorism is dictating against.

You are in luck, this sort of thing is not uncommon in games, particularly 3d.

E.g, tf2 calls them Jiggle bones. The idea is you make a series of short bones, which bend under physics, and then you skin the mesh with them. Skinning is a long topic, but there are plenty of resources for.

As for the physical animation, it can be very crude and still look quite convincing. The easiest way is to consider each bone connection as part of a particle system. The particles move about, but there are spring forces that encourage them to stay in proper relation to the connected particles, and also to keep the base following the head. But it might be easier to hook up a proper physics engine, rather than tinker with it. Phsyics engines are particular important if you need "hard" constraints, rather than just forces that just roughly keep things together. For example, keeping the length exact (non-stretch), or ensuring the hair doesn't overlap the rest of the mesh.

I'd bet the rope animation you linked works by a near identical system.

I've always been fascinated by the "big moments" in games. Any well written game can give a decent emotional blast at the ending - that is all the investment paid in. But more interesting are the ones orchestrated from the stories or characters.

Here are some games that I will always remember by a single emotional tone *not* merely of joy/accomplishment. You probably know the feeling I mean for each game.

Aquaria:         The Veil                             
FFVII:           Aeris dies                           
FFVI:            Failing to save the world           
Portal:          Realizing you can escape Glados.     
System Shock II: Realizing you've been duped by Shodan
Super Meat Boy:  That "oh shit" feeling every time you see a tough new level, particularly the Kid levels.

I use charles() instead of getCharles() because I don't conceptually think of them as methods - they are getters. C++ just doesn't have nice syntax for them. (of course, I do use getCharles in places too. I tend to use the former when I've refactored a pod struct into a class).

As for using macros, that is not a good idea. I expect you'll find out why macros are to be avoided during your current project.

You should only need one charles.

In constructors, you need two - one argument, one member variable. But, I find little point spelling out the difference.


I also use m_charles, not for the intellisense, but so I can see it is private. I might often have:

Code:

public:
  Person charles() const;
  Person& charles();
private:
  Person m_charles;

The m_ avoids the name clash in a way that is obvious to all. It's a convenient shorthand.

The relationship x² + y² = r² is a very dull and obtuse way to describe the perfect and beautiful thing that happens when while (true) {x = x_origin + r*cos(var); y = y_origin + r*sin(var); var++;}

Yes, this makes it clear that you've missed the point of learning maths. I suspect you are not being taught very well, most maths is exercrably taught.

The formula is the beautiful one of the two. The procedure might let you draw a circle, but the formula (and trig identities), let you understand why it draws a circle. Without understanding the why, you'll never adapt the how to do anything other than what you've seen it do before, which is this rote memorization we all agree is bad bad bad.

Conversely, if one really gets the why of any mathematical subject, the real understanding, then the actual formulas become obvious and almost childlish, like enlightenment.

But you say you use maths inside of programming. This is good, closer to the true path than you'd really imagine. And it does help your academic grades, too, but indirectly, so it is much harder to justify than memorization. If you want to hone yourself this way, next time you have a programming issue, pull out pencil and paper, and try to be confident of the solution before you try to code it. How might I adapt the above procedure to draw an ellipse. What if I wanted to draw a lens shape from the intersection of two circles? Could you make a game based around Apollonian circles, etc.

I don't know about anti-aliasing, I suspect scanlines is the wrong technique if you want that.

But I did understand about filling - look at my example again, it is the correct pixels for filling the polygon. Pixel 2 (range 2.0 to 3.0) doesn't have any lines in it at all, but it is filled.

I *was* following an even-odd fill rule, where you just alternate filled and non-filled segments. Non-zero winding is doable with the same technique, except at each intersection you must track whether you entered or exited that given segment, and increment/decrement the winding appropriately. But it's fundamentally the same, and it didn't sound like Crimsontide was having difficulty with that part.

I don't quite get your exact situation you see going wrong. As long as you have reasonably consistent rules, you should get something that looks roughly correct.

But if you are concerned, remember you can and should compute things to accuracy greater than a pixel. E.g. if you intersection list for a given scan line is [0.3, 0.9, 1.9, 4.0] when measured in pixels, you could fill each pixel according to if it's center is inside, i.e. so you'd fill the pixel 0 (which has range from 0.0 to 1.0), pixel 2 and pixel 3. There's no confusion about having two internsection points inside pixel, and you don't always fill a pixel even if there is an intersection point inside of it.