Messages

Finally, a devlog with what everybody wants from me: Boring art theory 

I had this proposal about expanding animation parameters:
https://www.adventuregamestudio.co.uk/forums/engine-development/proposal-expand-animation-range-repeat-parameters/

The expanded parameters you list there would accomplish the same thing I suggested here, but in the function call rather than the view editor. Actually, it might be better because it's even more flexible and doesn't tie up additional loops if you want to use one set of frames for multiple styles.

This is in the editor! So for example, imagine I have an animation that I want to play in this order, looping repeatedly:

1 2 3 4 5 6 7 8 9 9 8 7 6 5 4 3 2 1

At this point it seems like I have to set this order either by adding the frames one by one to the loop, backwards, or play the animation forwards, check for when it's finished, and then play it backwards. In a normal animation editor, I will just duplicate the frames like this:

1 2 3 4 5 6 7 8 9 1 2 3 4 5 6 7 8 9

Then I will select the second set of frames and "mirror" or "reverse" them to get the desired order with one click.

A nice to have feature for animation work is the ability to select a series of frames and reverse the order that they play in. Terminology differs per program, here's Aseprite and Krita:





Makes it very quick to make an animation play forwards and backwards using a single loop of a viewframe without having to check in code if it's finished or not. That's very handy for background animations like a curtain blowing in the wind.

No, I always built those on the fly, sort of making things up as I went along! That was never much of an issue due to their small size, and I fully expect that a lot of this game will alter over the course of making it, too. But to have it all loosely written out from start to finish is a nice feeling!

EDIT: And updated with a new post!

EDIT 2: Updated again, this time with some screenshots to share with you!

We moved to full 32-bit ARGB colors. All colors in script must be made a 0xAARRGGBB number, or a Game.CreateColorFromRGB used.

Another potential issue is drawing with a transparent color. Since alpha component is now in play, the result is that with fully transparent color no pixels are changed. This may be worked around by setting DrawingSurface.BlendMode = eBlendCopy.

That fixed it, thank you! I just replaced

Code: ags

surface.DrawingColor = 14458110;

with

Code: ags

surface.DrawingColor = 0xFFEA99FB;

and everything works properly. Cheers!

Finally back to building an AGS project after getting it written and when I tried to update my project from Alpha 14 of AGS 4.0 to Alpha 22 I noticed that my functions that use the DrawLine() command no longer work. Has the way dynamic sprites work changed between these versions? It doesn't crash, it's just that nothing shows up. Restoring my backup up project and opening it in the Alpha 14 build had the lines showing up as expected.

I wouldn't say my way is particularly novel or well thought out. I just have it broken into sections - a summary of the setting, a summary of the characters, a summary of the core game mechanics broken down by section, how they work and the rules around them, and then just a large section with the whole game plot broken down into acts, with the characters, mechanics and such written out. In sections where the gameplay is non linear that is just mentioned in text, for more linear sections it is just written out in order!

Exciting update for this month, friends, as I've actually gone and written this game! Now onto production Got some thoughts about it in the usual spot.

This looks great!

I hope it helps!

Here's some more feedback, and a suggestion for where you might move the sun angle to. Basically, having the whole front of the building in shadow like this kind of makes it hard to make a lot of depth. Can be much nicer if you have it a little more directly overhead.



If this isn't "dramatic" enough and you want the sun really low again, then check out sunset photos and see how much difference there is in colour!

It looks like you're doing your light with a soft light/overlay/similar layer - and that's a great way to work. But it's also worth cleaning up a bit, because at the moment the glow flows too much into the parts that should be in shadow. But also I think it's good to start with a clearer understanding of "value"*.

In your house scene, you have the sun defined as a light source, which is yellow, and clouds surrounding it which are white. This means that the clouds are lighter in value than the sun, which is not realistic for most scenery. The light source should almost always be the brightest thing, with everything else in the scene the same brightness (if directly lit by the source) or darker. Clouds should take shadow from a light source by the sun.

The other issue is that the sun appears to be in front of the clouds. This will never occur, and so the sun should be considered something we see where the clouds aren't!

If you post a version without the glowy light layers I'd be happy to show you how I might light a scene like this for comparison.

*lightness/darkness

It reminds me of heroic-fantasy comics like The Quest for the Time-Bird, or some rough sketches by Benoit Sokal.

I have been really getting into the style of European comic artists of old in the last few years, so perhaps that's showing through!

After some quiet months while I was busy I have put up another devlog! Hope you haven't missed me too much. 

This is my first AGS contest submission and a sneak peek at my first AGS game... I'm still getting the hang of Dee Dee Murray's art style, but I appreciate her work even more after trying to emulate it!

This is awesome.

Throughout AGS Script API we use Transparency, which is the inverse.

This gave me trouble for years when learn AGS because drawing programs use 'Opacity' for this (and usually handle it as a percentage, as AGS does, rather than the 8 bit alpha value) and I always had to convert things backwards. I'm not proposing that this be changed, just mentioning that it always stood out as a quirk in AGS's nomenclature.

I do think it would be great to be able to access the full range of the A value for a colour, though I can't say I've ever run up against it as an issue. But I imagine now that I'm getting back into making effects inside AGS that I would quite rapidly find uses for being able to read and store RGBA colour values.

What don't you understand though? Here's how reviews work:

1. People play your game.
2. They form an opinion of that experience.
3. They compare that opinion to their opinion of every other similar experience in the database.
4. They try to assign that comparison to a very limited scale.

Where are you confused about this process?

I see this in your first post:

I'm not comparing them to another developer's games which might make it subjective.

Understand this: Reviews are subjective. They are an opinion.