Messages

a hacking minigame can easily disrupt the pacing and flow. For a point and klick adventure, immersion is essential, and immersion is too easily disrupted by bad pacing.

Treat your minigames as puzzle, and make sure the puzzle makes sense within all contexts. otherwise it may just break immersion too much.

You can learn a lot about modern point and klick adventures from "Daedalic" especially its founders earliest projects, proving that the point and klick adventure genre is not dead, it just shifted towards "hidden object games" with a different audience, and that you can still make highres 2d point and klick adventures in 201X.

Day9Tv also has a youtube series called "mostly walking" focussing on critticizing or praising point and klick adventures. Recently they laughed at Uru, praised Myst, ripped "broken age" to pieces, and they are currently enjoying Loom.

In the end the medium limits and inspires the artist, and computer games constantly change because their medium becomes 2x as efficient at everything every 14 months. This enables new things while obsoleting others. But in the end the artwork is an inspiring artefact of its time.

The point and klick adventure genre barely translated into 3d renderers, and too many people failed to realize that it never has to translate into 3d. Msany people bought Harry potter books, ink printed on paper, how old fashioned and outdated in technology.

Game engines can make things easier to use for creative people, causing them to waste less time with source code and more time with artwork.

Game engines can make large projects easier to share tasks among larger teams.

It can make sense to write a game engine for only one game. this easily happens if you looked at all existing engines and none was sufficient for your project.

okay looking nice, but dithering is neither good for compression, nor good for image quality, except for limited palettes.
increasing color depht is always better than dithering and a lot of image formats and any archive format produce smaller filesizes with less dithering, even with higher color depth.

a workaround coud be to store sprites as bitmaps and have a struct that on demand loads bitmaps into arrays of dynamicsprite*[], and that makes objects/characters use them instead of static sprites that are always in the engines memory. the same dynamicsprite managing struct of course must also handle a .Delete() like command to free the sprite, but only if it is no longer in use by anything (visible).
of course one bitmap could store multiple frames of an animation.

for example the development of the non ags game "heart of darnkess" used more sprites than many games of its time of development. pushing hardware with little memory to its limits, praising its smart sprite-preloader, only preloading all the possible animations that could be needed soon, constantly refreshing memory between animations.

3.4.0.5 alternative link
https://mega.nz/#!IxFxACIB!swM-2H1hqE5PaD1yzXG4CLRndGvRPo0fr-CorLw-PmE

import void example(int ihaveaproblemwiththisarbituaraylimit=32000);

the limit here is 32000, totally dumb limit, not even a power of 2.

if you store anything in struct instances. the struct instances are like variables with a "lifetime", they are global or local withind a function, with their data being exported or not_exported.
if that struct instance is not exported, the instance may have the same name in the source code in 2 different rooms or scripts, but it compiles to a different address, and that may store null-pointers, leading to an exception_error_crash.
how to have that not happen:

struct structname{
    int value;
}
import structname structinstance; //in the header of a struct; you may import an instance of a struct, so that every other script has access to that instance.

//end of header, start of body

structname structinstance; //at the start of the body of a script you may need to define that instance;

export structinstance; //at the end of the BODY of a script you may need to export that instance, otherwise its values will be seperate/different (addresses) for every script.

//that importing and exporting makes that instance of that struct global and unique from any script and room_script...

with approx 300 rooms you might be over the room limit of ags v3.1, that is ==300.

there are also a lot of other engine limits, told in
http://www.adventuregamestudio.co.uk/wiki/Engine_limits
and you can step over the limit temporatily without any error, like defining a 300001th dynamic sprite but never accessing it, while getting very strange errors in other cases.

nwer verswions of ags have some engine limits increased, lifted or offer workarounds.
mostly version 3.4.0.6 alpha to be found somewere, hidden behind a waterfall

A good starting point for any computational/mathematical problem, like basic famous games/simulations, maze generators, basic pathfinding, sorting algorythms up to any calculus/algebra problem are:
- youtube tutorials (all the below often have a video version somewhere, even if its just a runtiome example)
- searching for opensource examples, by searching for "... in c" "... in java" "... in actionscript" "... in html5"
- lectures, manuals and publications, by searching for " pdf"

Storing an offset vector for each frame of an animation, and then moving the character by the frames offset position, is possible, but it adds to used memory and it slows down runtime.

just having each sprite at least centered to the same x ynd y value before you import the sprite, saves you a lot of memory and processing time. you can still add an individual offset vector for each animation/character.

this doesnt solve how to offset a character or its sprite (and all the sife effects it causes)
but it shows how to store an array of offset coordinates in v3.3
make an int[3] or an int[2] to store a 2d or 3d integer vector in a struct.
make an array of that struct.

Code: ags

#define OFFSETS_NUM 100
struct offsets{
  int[3] offset3d;
}
import offsets OffsetArray[OFFSETS_NUM];

//end of header , start of body
offsets OffsetArray[OFFSETS_NUM];//should be on top of a body to use the same offsets- instance there
export offsets;//should be on bottom of a body to use the same offsets- instance there

//this is about ags 3.4.0.3 functionality; dynamic arrays and managed structs:

//i have been coding a lot in ags-script recently and feel the need to report some of the more usefull code i wrote:

//recently i have been writing on a module for static functions on n-dimensional arrays. the functions are all in a
autoptr managed struct NdF{// for "Ndimensional Float", and an instance of it only stores
int dimensions;
//...
}
for each static function there is also a non-static function that just calls its static-equivalent, but that non-static gives it (this.dimension) instead of requiring a specific (dimension) parameter.

the array functions usually take one or 2 float arrays
import (static) float[] ArrayFunction(float a[],float b[],...) as parameter and most of them return a a float[];

this all started when i wanted to compute an n-dimensional crossproduct of two n-dimensional with the same function, beecause why not compute a crossproduct in 1024 dimensions? i think my 1024 dimensional DOTproduct finds more use.

once the number of dimensions of input vectors is no longer an issue for the functions you use, you easily come up with more and more functions

I may give it an extension:
autoptr managed struct NdFa extends NdF{// for "Ndimensional Float", and an instance of it only stores
float a[];
//...
that has for each function that takes a float array, one equivalent function that instead takes (this.a) and a boolean (also overwite this.a wth the returned value)

i may wrap this managed struct in a struct, just so that i can access an instance of that within another function.


and i may also do the same for integer arrays as
managed struct NdI{//n dimensional integer array functions
}
but so far this project frew a bit out of proportions and i need to think about struturing it more.

of course there are many things you can do with one or more float arrays in n-dimensions ,
so far i wrote a lot of vector functions,  i define a circle by having the LAST value of the array set the circles radius.
I calculate circle intersections, calculate shortest distance of dot from line in 3d...
I move points around "wildly" using the same vector functions over and over within loops of loops.
I calculate means, averages

I also have functions for simplle physics simulations (gravity, acellerate, turn follow), ragdoll physics (verlet integration), Boids (swarm behavior) and what you need for more complex things like meshes of half-vectors, Delaunay-triangulation.

and they are all in the same struct.

needless to say, this grows on its own, and i am just glad i can not extend on the "float" type and my "Float" wrapper so far turned out to be pretty useless.


i think i need some help woth basic "extend"-inheritance. what struct should extend on what other struct, adding what functions while not including what other functions of another branch, and would that even be worth making different structs that i may need to write getters and setters to for non-statics just to get and set values from one struct type to another, even if its the very same inside of em?

well, ill release some of it after fiqing the worst errors of some basic testing.

but for testing my functions for errors really need a half decent "canvas" for ags. and so far just drawing on a drawsurface from the background image just didnt quite cut it.

i tried making a canvas of a sprite to a dynamicsprite, but working with dynamicsprite pointers is a bit messy in ags;
make a sprite for a "dot/sphere", and remember how often that dot is used, and only if its last use is removed, clear the dynamicsprite, that was my most recent plan. and its a bit flawed.

Code: ags

//this is mostly resolved, and only about a confusing compiler error message...
//...on returning an array of a managed struct from a (static) function:...
//"Can not convert 'DynamicSprite[]' to 'DynamicSprite[]'  " 
//...and like many compiler errors, this is not only confusingly fuzzy, ...
//...but this one is a straight out nonsensical logic response to throw at anyone.

//this requires AGS version 3.4.0.3 (alpha 3) or higher (due to dynamc arrays)

//as an example i have this function that produces the error...
//...this static function wants to merge 2 arrays of DynamicSprite[] (as part of a struct for such functions):

struct ArrDyn{};// a struct-set to group static array-functions for DynamicSprite*[] into.

///Returns DynamicSprite*[0..LengthLeft+LengthRight] of LeftSmall[0..LengthLeft] having RightLarge[0..LengthRight] merged to its right, changing all #indizies of RightLarge[#] to #+=LengthLeft.
import DynamicSprite*[] Merge2Dyn(static ArrDyn, DynamicSprite *LeftSmall[], DynamicSprite* RightLarge[], int LengthLeft=1,  int LengthRight=1);

//end of header // start of body//
//end of header // start of body//


DynamicSprite[] Merge2Dyn(static ArrDyn, DynamicSprite *LeftSmall[], DynamicSprite *RightLarge[], 
                                              int LengthLeft,             int LengthRight){
  DynamicSprite *r[];//set merged array for return value.
  r=new DynamicSprite[LengthLeft+LengthRight];
  while(LengthRight){//copy LeftSmall[] to r[]
    LengthRight--;
    r[LengthLeft+LengthRight]=LeftSmall[LengthRight];
  }
  while(LengthLeft){//copy RightLarge[] to r[]
    LengthLeft--;
    r[LengthLeft]=LeftSmall[LengthLeft];
  }
return r;}//on the return call the compiler cries: 
//Can not convert 'DynamicSprite[]' to 'DynamicSprite[]'  //--tehehe

//i reported this before. but my example was flawed, possibly by not using a MANAGED struct array in my previous example.
//i think it makes a difference if its a managed struct, like DynamicSprite, or a (non-managd) struct.
//the compiler is however fine with this correct example, only replacing:...
//DynamicSprite[] Merge2Dyn
//...with...
//DynamicSprite*[] Merge2Dyn
//...which is possibly unneccessarily confusing in your script syntax to even make an explicit  difference here.

DynamicSprite*[] Merge2Dyn(static ArrDyn, DynamicSprite *LeftSmall[], DynamicSprite *RightLarge[], 
                                              int LengthLeft,             int LengthRight){
  DynamicSprite *r[];//set merged array for return value.
  r=new DynamicSprite[LengthLeft+LengthRight];
  while(LengthRight){//copy LeftSmall[] to r[]
    LengthRight--;
    r[LengthLeft+LengthRight]=LeftSmall[LengthRight];
  }
  while(LengthLeft){//copy RightLarge[] to r[]
    LengthLeft--;
    r[LengthLeft]=LeftSmall[LengthLeft];
  }
return r;}

definitely use the tween module!

i finall found the solution, ony my own, and youre all right.

this usually hints at an (accidental) infinite recursion.
usually a typo causes a function to call itself instead of the function you wanted it to use. autcomplete can be annoying like that.

this recursive loop executes infinitely untill you run out or memory.

check all newly written functions to see if you made one to call itself (unter conditions that you thought to filter out as impossiible, but that are apparently the case).
thinks like this also happen within accidentall recursive loops. they are NOT caught by the newbie-friendly ags-function that is made to prevent loops looping too often.


----

i think i salso had strange runtime erros like this when i tested what would happen if i instance over 30000 dynamicsprites, daring the engines limits. it might even be a different engine limit than its sprite limit of 30000 thats causing your error.

basically, lovecraft novels can not work the same way in any more visual medium:

https://www.youtube.com/watch?v=7DyRxlvM9VM

the medium changes the story so much, it is no longer the same, it is abridged/satire at best, and that barely works with lovecraft.

just by SHOWING "unspeakable/undescribable horrors" they are no longer unspeakable/undescribable, and even worse, by making them interactive, it is near impossible to not transform them into something like https://www.youtube.com/watch?v=FOHJUrcVdJk

this problem keeps following me.
i make a struct that has some parameters;

struct IStoreStuff{
int x;
ins y;
String s;
}

IStoreStuff IstoreStufInstance;

and that struct has one or more instances in a scripts header, and silly me expects that, if i read or write any value of any instance (of the very same label) of that struct from anywhere, that it addresses the very same instance. but somehow this is not the case.

simple question. why is my struct not global?
the "export" syntax also seems to do nothing, and is poorly documented.
managed structs in alpha versions? dont get me started, coded so much, just to notice all the limits on managed structs on runtime make them nearly useless.

specifically:
I write a value in the global-scripts-"on_game_start"-function , and silly me expects that any ROOM-script can read from it, addressing the same instance (of the same struct) by the same name, assuming it would get the same prefiously stored parameters.
but no, it reads only zeroes, or even null pointer crashes in array instances of structs as if the array-pointer for the structs instance is a null pointer. otherwise it reads "null/void" values where it clearly should either tell me that this instance is not the same, and just give me the same values i stored from somehwere else in my source code, or that this instance no longer exists. but instead it happily addresses the "shaddow of an instance", and it is possible to write and read from that, and later read from the other instance, both happily sharing the very same instance name of the very same struct (in source code), only being called from different locations/wscripts/functions in source code.
like painting an infinite amount of individual shadows instead of painting the object itself.

its old , free and newbie friendly.
you can still do some quality stuff with it.

but its scripting language, with every new limitation to lists and structs i come closer to thinking that it is more an insult to c.

it lacks perspective. all these furnitures anf books are shown in perfect parallel front view, and they seem to stand very close to the wall behind them.
->they all must be carboard cutouts. poor guy got pranked by his co workers.