Messages

I would be *very* surprised if that's the case with any modern AGS version. In fact, I would have hit that limit in countless projects so I'm fairly (read: 99%) sure that's not the case.

Make sure to use while-loops as much as possible!

To the best of my knowledge, it needs to be at the end of the file if you are modifying it in the file. If not, you should be good.

You put the struct definition ("Hint { boold one; String desc; };") into a header file (global header file for example, although I like to create a new pair of .asc source and .ash header files per struct. Then you put the array declaration ("Hint Hints[50]") into the beginning of the source file (main/global source file if you put the definition into the global header file). At the end of the source file you put the export line and back in the header file, underneath the struct definition you import ("import Hint Hints[50];").

That should do the trick, hope this helps!

Ah, interesting. I might do the same one day if my current plan doesn't work out! Good luck!

I'm interested, what are you making a portfolio for?

It's also not available in Germany and that trick you linked doesn't work (anymore?) - would've been interesting to see otherwise!

I think it is absolutely fine to go for that style, it really doesn't sound that much like MIDI so I wouldn't worry about it defeating the purpose of not using midi.

I need to check out that LSD plugin from the looks of it, haven't heard of it so far!

The easiest and fastest way to do this is to avoid trigonometry altogether and use simple vector math instead.

Code: ags

// this code will give us a line that is 100 units long and points from line_origin to the mouse location

#define LINE_LENGTH 100


// create a vector from the line origin to the mouse cursor (vector_a_to_b = b - a)

float vector_x = mouse.x - line_origin_x;
float vector_y = mouse.y - line_origin_y;


// calculate the length of that vector and normalize it using the length

float vector_length = Maths.sqrt ( ( vector_x * vector_x ) + ( vector_y * vector_y ) );
vector_x = vector_x / vector_length;
vector_y = vector_y / vector_length;


// now that vector has a length of one unit, let's make it bigger again

vector_x = vector_x * LINE_LENGTH;
vector_y = vector_y * LINE_LENGTH;

Yes, I also tested this release and it's really freaking awesome! I LOVE the music especially, incredible job there, SMS!

Still find it kinda awkward that some of the jumps are further away, so you have to take a running jump.  I would prefer if you could jump the same distance from a standing point.  Also found that with a running jump, you sometimes jumped to far, and fell off the next platform.  But that's just me.   

Nope, I beta-tested it as well and gave the same feedback!

It is without question one of the best AGS platformer - congratulations, Radiant, despite the fact that I personally would have done a couple of things like the jumping a little differently.

It's readable but not comfortable to read at all so I would not suggest to use it, unfortunately!

Oh yeah, getting the physics to feel just right is incredibly hard.

About the level design: I noticed the change in this regard when setting the game to easy difficulty, but that doesn't make a big difference, it's not about the difficulty (you can just move slowly on higher difficulty and you'll be fine anyways), it's just the way these spots make the player feel. Just feels wrong and out of place to me.

It's coming along very nicely. I have problems with movement still though. (1) Indiana Rodent still feels sluggish, I would greatly increase the acceleration and deceleration, make him react more quickly that way. You know how there's lots of platformers with icey ground where you slip and slide sort of? The game currently still feels like your on such a surface throughout. (2) You jump higher when you're moving left or right? That feels very counter-intuitive. I think you should be able to jump just as high while standing still and just hitting the UP key. (3) The level design can be a little unintuitive. These sorts of spots where you can't see where to go next should really be avoided like the plague, I feel:



It's great fun to play, still, and I'm very much looking forword to a full release. You did a clean and excellent job for an AGS platformer!

Really looking forward to this, I've played and finished the tech demo for what feels like the hundredth time now!

While we're at it, we should have a 'borderless' (I and most commercial games that implement this refer to it as 'fullscreen (windowed)' mode rather) mode in addition to windowed, fullscreen and this windowed with black border stuff! It looks exactly like fullscreen but in reality it's just a fullscreen window without borders (and the contents are scaled of course, just like in fullscreen mode). It's a relatively new thing (Starcraft II has this mode for example), but I already wrote Direct 3D applications that allowed this mode - it's extremely easy to implement. With it, you can alt-tab super quickly and it also takes much less time to initialize when your game starts!

That's the color depth, it determines how many different colors your image can have. I don't think, with digital painting, there's much of a reason to go with 32-bit as opposed to 16-bit as you will probably still use a palette when drawing. Photos you take do benefit much more from a higher color depth as they can easily have TONS of totally different colors.

http://www.videocopilot.net/tutorials/all/

I'm still not sure what the problem is, but I'm pretty tired and it's getting late...

My MoveX/Y function does collision detection by checking if the end position along the x or y axis is in an obstacle and if it is, it will move the entity right next to that obstacle. So if you move down and right and hit a vertical wall, at some point the MoveX function will report that both right control corners would be in the wall, so the distance to that wall is calculated and, instead of moving the entity into the wall it actually moves right up to it, hugging it. If the down and right keys are still held down, the MoveY function will keep on reporting that both lower control points are not in obstacles and the entity will keep on moving down, hugging the vertical wall.

You mention resolution and that's of course a valid problem. If you work with tiles for obstacles and your entity is smaller or equal in size to a tile then corner control points work fine. If it's larger you need to simply add control points. 1 tile or less in size means 2 points, 2 tiles or less means 3 points and so on.

I'm not 100% sure I understand the problem you mention there, Khris, but if you add control points to all 4 corners of your entity and then, when moving down you check the left and right lower corner, if you move left you check the upper and lower left corner and so on. If either of the two control points you're checking reports a collision, you don't move (but jump to the reported collision wall). That logic works 100% without problems, I have made use of it for several projects before!

It's generally a good idea to separate the axises of movement in these cases.

I tend to give what I call my entities (ie. all things in the game that can move, the player, maybe other players in hotseat-mode, ai-controlled allies, enemies, maybe projectiles) a MoveX and MoveY function. The code in these functions is very similar. They are called with a parameter 'float distance' and simply try to move the entity that distance - horizontally for MoveX, vertically for MoveY. But before they move the entity they check for a collision - but only in their 'dimension' (ie. along their axis/direction, MoveX is never concerned with anything height/y-related). Then if the up-key is pressed you move the player by calling MoveY(-1.4), down=MoveY(1.4), left=MoveX(-1.4), right=MoveX(1.5).

Don't have more time to explain right now, sorry for not giving actual code but follow this logic and you'll have it set up working nicely in no time! Ask if something remained unclear or doesn't work in your implementation!

And cheers with your projects, been watching all your dev diaries with much enjoyment!