(the topic was "How do we tell a complex story while allowing the player to exercise meaningful choices?")

my thought on this subject is i don't really like when games try to make choices "meaningful". every time it's been tried it's resulted in ridiculous games, usually with a moral way to play the game and an immoral way (fallout series, baldur's gate, advent rising, ogre battle, etc.). perhaps the game that seems to have done it best (though i haven't finished the game yet) is fable 2. but even there, all the choices result in is some points on some meta karma reputation system. how is that meaningful, to move a number up and down a karma slider? who cares? the choice of what class you play as in baldur's gate 2 is more "meaningful" than all the moral choices in the entire game.

so my advice would be to just give up the conceit that players want meaningful choices or that meaningful choices will make games better or more artistic. they won't, they've been tried to death and trying them some more won't work.

instead, i think it's better to focus on meaningful experiences, not meaningful choices.

(reposted from something i wrote in the tigsource forums)

- made new area
- made new area
- made new area

fyrewulf and evajolli also made new areas, but i don't know how many.

- added some text about not running into enemies, after the first catob encounter
- moved the text about using tab or m to display the map to the mercedes recovery script, rather than the venus rejoins script; this and the above were both eva's suggestions
- spent a long perfectionist amount of time working with colors on the map screen until i have this new map colors system (pictured) -- now only rooms explored are textured

still no new areas! will do nothing but areas tomorrow D:

my new year's resolution this year may be a bit strange, but it's to play every game i own, and read every book i own (or get rid of the books that i do not intend to read). and to review indie games for timw's blog, tigsource, and playthisthing more often. i also want to go visit newedition, probably in spring/summer.

there are a lot of things i want to do "career" wise as well, but i've the feeling that i will do those automatically, without too much special effort. i find working on games kind of easy and natural now, it's enjoying personal experiences that i've been neglecting. perhaps that's because i enjoy working on sd so much that i don't really need other forms of entertainment, aside from a few starcraft videos on youtube now and then.

but playing games and keeping up to date with what games are doing (both mainstream and indie) is still quite useful as research, so i shouldn't neglect it. also, reviewing games of other indie devs for the main indie game blogs so that people take notice of them is very important work, perhaps more important work than my own game. even though i'm not paid for it, i think reviewing indie games, providing feedback to developers, and that sort of thing is a much more valuable thing to do on the historic timescale than making id was or making sd is.

in general reality is strange like that. something you can care very little about or put very little thought into can be the most important thing you'll ever do, whereas something else which might take you years of planning and concentrated effort could be relatively insignificant. it's a strange thing. so i never really know when some chance word i write or chance feedback i leave or chance conversation i have could affect things (both global/historically and/or locally/personally) drastically.

there's a thought experiment i thought up a few years ago to illustrate this. let's say you're choosing a fork to eat with. a simple decision, but the forks are not identical. one might have a few things the other doesn't, perhaps a single atom of lead, which, through unobservable, causes you to get cancer with the one fork or to not get it with the other. but you never really will know that it was that one decision which had that effect. and can't know. that's how reality works.

of course, just because this is the case, just because there's no way to determine what leads to what drastic difference, doesn't mean we shouldn't take care in decision-making. just that we shouldn't presume we are in control of things. the brain has a useful role in making many decisions, but due to very strong limitations (both in perception of reality and the process of prediction), when things turn out well or when things turn out badly it was usually not the brain's doing at all, it was just reality working itself out in its multitude of ways. this is another way in which the first virtue is acceptance.

anyway, i find that variety is better than monotony, which is why i want to play every game i own and read every book i own; too much of it is just sitting there, waiting to be experienced by me.

- talked with fyrewulff and evajolli more about making levels and using the editor
- fixed the speed bug with the chain/line
- made it so every 50 creatures you friend a cutscene appears. however, it is coded in a fairly sloppy way; for instance if you have 49 creatures friended and then friend 2 more in a single room, the scene won't ever show up, cause you have to go to a new room with exactly 50 friended. also, if you have exactly 50 friended, get the scene, exit the game, and come back, you get the scene again.
- edited wynand's text for the first of those into separate files, and added the Mercedes: tag in front of each line (otherwise it didn't work)
- fixed the sloppy coding mentioned above; now it saves to file which scripts have been shown and checks ranges so they'll always be shown once and only once
- fixed a bug where you could use the fade function on invisible walls
- designed the 'charge' abilities of all the functions (designing those was on the to-do list, since i want to have them but hadn't designed how they'd work yet)

no areas today, but more tomorrow! also, new version of the game soon for playtesters (probably within a few days) since that chain bug really needs to be fixed for them.

also, the wish list for saturated dreamers is about 580 items long now. i told eva-jolli to pick some random number between 1 and 580 and i'd do the wishlist item it corresponds to. she did, and i did -- twice (the first one was the cutscene % thing, the second one was the designing charge abilities thing). it was kind of fun to just work on random items on the wish list.

- made another change which may stop the flickering (initialized depth on map object creation rather than only updating it once each step); but this didn't seem to fix it. :(
- did a few more optimizations to the step sequences (i don't use step events anymore so i'll just call them step sequences) for map objects, mainly that i now check if x and/or y have changed using xprevious and yprevious before re-calculating cx, cy, and depth. because most map objects and stationary and never move, this will likely increase speed a bit in areas with a lot of objects.
- made area
- made another area
- talked with fyrewulff and eva jolli about them creating levels possibly for the game (to help speed up the process); helped show them around the game

another review of ID: http://www.wurb.com/stack/archives/671

there are probably a few more i missed

- made new area
- made fog/clouds have correct blend mode and not get stuck on objects
- made new area
- wrote text scene for entrance to blossom mesas (subsection of map), put it in first area of blossom mesas
- made new area

i now have the entire 'line' filled in for blossom mesas -- the way i'm constructing the map is center, then outward into 9 lines, like cutting up a pizza pie, then after those extensions into each map subsection i'll work inwards and fill in the missing areas

best 10 snes games (the best official list)

1. secret of evermore
2. soul blazer
3. ys3
4. genghis khan 2: clan of the grey wolf
5. evo
6. illusion of gaia
7. ff4
8. the 7th saga
9. dw5 ogre battle
10. populous

another list

honorable mention: paladin's quest

best indie gams evar, by gam engine/language:

zzt: rhygar
game maker: seiklus
ohrrpgce: sword of jade
rpgmaker2k: exit fate
blitz: the you testament
c++: aquaria
xna: geometry wars
flash: vvvvvv
unity: fatale
mmf2: within a deep forest
z-code: photopia

these lists are getting popular, so

- made new area
- made another new area
- made another new area

this new lj avatar is from a pic taken today

- talked about SD with podunkian, he had an idea for the map to decrease music volume the same way standing still does
- finished the new area started yesterday with nephew (pictured)
- made another new area

just two today, but that's my fault for getting too distracted by #tigirc -- tomorrow no chat programs open till 3 are done first ^^

- made about a fourth of one area, with my 3 year old nephew's help (there was a family gathering at my sister's house which involved 2-hour long car rides, so...)

- noticed a bug that unicorns no longer display their colorful trail, will need to fix that
- made new area
- made new area
- finished earlier area
- added a subtle (perhaps too subtle?) effect to indicate passability near edges of the room (pictured; it's at the top)

gonna try to increase this to 3 areas a day, 2 is too few

- made new area (pictured)
- made another new area

- made new area
- recolored some lilypads pink for the blossom mesas area
- put those into game
- made 'nother area (pictured)

- made one new room (pictured)
- made pink grass (thanks to evajolli for recoloring the grass for me)
- made pink grass surfaces
- fixed a bug that kept pollinated effect from showing up

- made new area
- made another new area

focusing on mushroom areas near venus's dream area (which will be a real area)

- another small optimization regarding drawing invisible walls
- made a change to the level editor's shuffle function which made it skip invisible walls when shuffling room elements
- fixed a position rounding problem when using shuffle
- fixed a bug where the level editor didn't correctly change the colors of objects anymore
- made it so if a nurikabe is hiding other creatures, their life bars / friend bars don't show up (which would give away their position)
- made a new area
- added to the game a few new sprites orchard had drawn recently (new trees and a new mushroom)
- made a new area (pictured)
- added the rest of the sprites orchard had drawn recently to the game (clouds)
- did change to image loading for deco sprites (was mistakenly loading the same sprite into memory when i didn't need to)
- made the text in the beginning of the game have a delay for punctuation etc.
- made theo's portrait appear in the save menu if for some reason you save and quit in that very early part
- resampled the portraits for the smaller size rather than scaling them down, which makes them look nicer and less pixelated

my new target (not a binding vow, but a promise) will be to finish two new areas per day, before i work on coding or bugfixing or new features. exceptions are coding that i need to work on those particular rooms. cause unless i start doing at least 2 new areas a day the game won't even be finished in 2010 D:

( save screen with theo in it )

- made a fix on a depth problem which should help strange cases where the player seems to jump ahead of an object instead of stay behind it
- fixed a bug in map coordinates display (my string_int() function didn't know how to handle negative numbers)
- i think i've figured out what's causing the flickering, but because it's so inconsistent it'd be hard to make sure that's what causes it -- in any case i made changes which may or may not fix the flickering
- fixed a bug were the title screen would 'jump' up if the game lost focus and then regained focus later
- did a few tests on various aspects of the recently released game maker 8; seems coding execution speed significantly increased, but porting the game to gm8 will take a while

- fixed an instance activation problem more efficiently (by setting a variable whenever all objects are activated, which happens for various purposes)
- optimized the 'draw double' thing for transparencies in various ways, and tweaked its various variables until it looked at least a little acceptable; came across a bug related to depth and fixed it; i think it now almost works as well as it did before i did the draw event code optimization
- uploaded v0.51 for playtesters

*now* i really must focus on content, not code

- made escape cancel the map (as well as enter escaping mode)
- made creature call/sound frequency relate to delta time rather than frame rate
- changed the title screen border slightly
- optimized the title screen draw routine so that it only draws the part displayed on screen rather than the whole thing, which speeds up the title screen from previously 45 fps to 70 fps for me
- made the title screen scroll according to delta time rather than frame rate, for those who still get slow rates on the title screen
- fixed a bug in the instance activation script for certain cases (plan a better optimization later)
- partially did a workaround for object transparencies (when appearing behind objects) but still need to work on it a bit

likely v0.51 tomorrow

- discovered that the trying to use non-existing surface bug still happens, at least if you leave the game on the title screen and let the screen saver happen. changed some of the code in hopes it will fix it, but didn't test
- adjusted direction += and direction -= statements to delta time (that way needbeeds won't spin faster when the game is running faster and slower when it's running slower)
- re-implemented subpixel movement for floats and decofloats by storing the fractional part of their x,y position before flooring them, then re-adding it to them next step; now at faster lilypads still get pushed by the player and flowers don't come to a stop as quickly (due to the previous 'friction' of rounding the x,y position each step)

too much game-playing today -- first umbrella adventure (still want to review that), then league of legends with mr. podunkian, then starcraft with evajolli. less tomorrow.

- fixed a bug in draw color (forgot to set image_blend to draw_color rather than c_white)
- there are still numerous bugs with blend mode (related to object depth) and i worked through and fixed these as i came across them. now only room 0,0 seems to have blend mode flickering problems occasionally/randomly, although i'm not sure what's causing them. will need to figure it out.
- found a bug where pollinated flowers don't have their pollination status shown anymore, will fix later
- fixed some of the friction problems related to frame rate (at higher frame rates, things had more friction, now they have similar friction -- although not identical because there is still a rounding issue related to drawing mucking things up. i have an idea that will fix that in the future though

- fixed a bug where the tab/m map keys wouldn't work correctly, and some other keys not working correctly (bad game logic). will need to do a speedy update to fix the issue in the playtesting version, perhaps at the end of today or tomorrow.
- did an optimization teegee (of getmagi.com) suggested (moving step events of map objects to with() statements) which improved speed a bit
- began doing optimizations related to draw events, which seems promising (speed increases significantly in areas with a lot of objects) -- the idea is i'd just let gm itself do the drawing and have no code in the draw or step events at all. this has some sacrifices, for instance, i can't vary the blend mode of objects individually as the player approaches them anymore. but the speed advantages outweigh that loss -- in some areas the fps more than doubled. (see picture -- previously i would have gotten about 50fps in there instead of 120-130)
- created an invisible object just to handle blend modes at a specific draw depth (necessary for the previous optimization)
- optimization where the x and y values of a map object are rounded whenever an object is moved rather than every step or when drawn (necessary for the aforementioned optimization)
- some optimizations of edit mode, although at the cost of exchanging round rectangles for rectangles -- now edit mode (on this computer) doesn't drop the fps from 100 to like 40, instead only dropping it from 100 to like 60). it's not really necessary to optimize edit mode, but i figured people on slow computers should be able to edit areas too if they want. one curious thing is that edit mode runs much faster when the mouse is over the edit bar than when it's over the map (difference of 80fps to 60fps for me), even though there's no difference in how it's drawn; probably has to do with collision checks and such.
- found some bugs related to the blend modes (why isn't there an image_blend_mode variable!?), and fixed it -- i hate how roundabout i have to approach it though (i have to make sure i set the blend mode before particular *drawing depths*), but that's game maker
- noticed a bug: how far you push flowers when you bump into them depends on the frame rate (i think it has to do with friction)

today's optimizations have actually been quite dramatic. i'm glad i took teegee's suggestion and also glad i tried the optimizing the draw event. i've a few more optimization ideas (in fact, still more than 20 -- as i've been doing them i've been coming up with new ways to optimize the game and writing them down on the wish list), but even just as is, i believe today's changes improved the game speed more than the last week of optimization combined did.

- went through searching for all time-sensitive instances of width/2 and height/2 and replaced them with the precalculated halfwidth and halfheight variables, likewise with x+width/2 and y+height/2 with the precalculated cx and cy. this won't make too much difference, but might make a tiny difference, particularly for map objects when there are hundreds of them on screen at once and each is doing those extra calculations that they don't need to.
- made the unicorn's (seena's) trail vary based on delta time rather than absolute frame rate
- optimized the phoenix draw routines a bit
- optimization in the triangle intersection formula (used for determining if you can break bushes and crystals and rocks with the weapon)
- noticed a bug that, when you press escape after previously pressing and cancelling escape, for a single frame it shows the full text, before scrolling the text in again
- tried and failed to use surfaces for drawing textboxes -- the mechanics don't quite work out, there's no simple way to accurately add one letter at a time to a surface and have them all placed correctly without recoding a bunch of stuff; i may do this later but right now it's a bad idea
- similarly tried and failed to use surfaces to display round rectangles (one of the slower drawing primitives), it doesn't quite work scaling-wise out because the roundness of the corner varies so much depending on the height and width of the round rectangle. it could work if i have a unique surface for every different size of the round rectangle, but
- made textboxes grow larger rather than appear instance, it's nice to have things morph in or transition in rather than suddenly appear, it makes things feel more polished. i want to do a lot more of that kind of thing eventually.
- changed a few instances of 'fps' in the code to the timer dll's more accurate measure of fps (updated every step rather than every second)
- went through all particle creations and adjusted it to the fps (so that at slower frame rates fewer particles are created to ease the slowdown a bit). eventually i also want to change their speed and lifetime/duration based on delta time.

- fixed a bug in the 'nomusic' variable (which measured how long to delay the return of the music for after a special music sound effect like the friending effect or the upgrading effect
- fixed a bug where sometimes it'd ask you to upgrade before you have any functions at all (if you friend enough creatures through debug keys), causing you to get stuck in the upgrade screen forever; now it'll only ask you to upgrade if you have either venus or neotheo on the party (right now either will do, but later neotheo will be required)
- found a bug in the radar (the color of creatures on it isn't consistent), will need to fix later
- fixed a bug where it'd ask you to upgrade during the venusjoins script if you had accumulated enough friends by then; now it'll never ask you to upgrade when a textbox is running
- fixed a bug in the checking for upgrades (it seemed to only run after you loaded your game or friended a creature, now it checks more often)
- fixed a bug in the sight function's radar (it would only update when the player was moving)
- did a further optimization of the object activation/deactivation script; it only updates when the view is moving
- found a bug where the rakari getting stuck on the player no longer slowed the player down; fixed it
- for some reason the 'light' wasn't drawing and i noticed i had commented out the light-drawing script for some unknown reason; i returned it to normal
- fixed a bug in the distance at which you can acquire a creature sound (the distance was too small by about half and it was using the creature's top left corner instead of its center)
- began testing the game at 20fps (capped).
- at 20fps noticed that the zig engine gets larger (size should depend on relative speed, not absolute speed), and fixed it
- at 20fps noticed that the player didn't accelerate as fast, even though the max speed was fine, and fixed that
- at 20fps noticed that the distance that the player's engine part drags behind the player depends on absolute speed, not relative speed, and tried to fix it but my fix didn't really fix it much (not sure why)
- same thing with ghosting effect for the player's equipped function
- noticed pegai shakes weirdly at low fps, not sure why that'd happen...
- noticed scylla's tail length changes with absolute rather than relative speed, and i know why it happens but this may be very difficult to fix (would involve a complete re-write and a new method) so i'll leave it as it is for now

in any case i think it's time i updated the playtesting version, and i want to see if the optimizations i made so far matter for slower playtester computers, so we'll call this v0.5. will now zip and upload and email out newer version.

- figured out how to adapt the sinusoidal time rotation functions to delta time and did so (creation of a new global which is incremented by time rather than by number of steps)
- optimization where i precalculate whether movement should be paused (based on its various conditions, so that all those conditions aren't checked by each object each step, just the global condition which is checked once per step against all those conditions -- whether a textbox is showing, or the escape menu, or the upgrade menu, or the map, and so on)
- made the game pause during map display (it previously did not)
- made the timing variables pause during some of the pause conditions, but not other ones that rely on it
- adjusted creature healing rate to delta time
- changed the saved games timing variable (which measures total time of play) to be depending on actual time rather than game steps. unfortunately this makes old saved games incompatible with respect to time, and after one load, they'll revert the counter and start from 0 hours 0 minutes 0 seconds again
- changed another timing variable (steps since the room began) to take delta_time into account; this variable is used for a couple things (like fading in of the last room's image, and how you can't hurt enemies in the first second of a half after entering a room); this caused a bug in fading the last room's image, because i didn't take into account load times, but fixed it
- made an optimization in how object speeds are adjusted to delta_time
- made the delay between the ship's functions vary by delta time
- changed a bunch of miscellaneous things vary by delta_time (by doing a global search for += 1 and -= 1 and seeing if it makes sense to multiply that by the length of the frame factor, and doing that when it did)
- made text speed scrolling vary by delta time; had a bug at first but managed to fix it; i think it had to do with (not variablename) resolving to false if it's negative rather than exactly 0, switching it to variablename <= 0 fixed it
- a few optimizations in the title screen background wave script
- optimized a few more loops with the var keyword
- realized i could actually preserve time in saved games (without wiping out old games' save time) and did that
- adjusted friending gain/loss rates to delta time by searching for friending += and friending -= in all scripts

now that i changed the game to change speed of gameplay according to delta time i need to go through the game to see what feels wrong / doesn't work and see what i missed etc. etc.

- worked some more on the grass surfaces (made 16 variations, combinations of 4 variations by size and 4 variations by density). spent a lot of time perfecting the variables so that they focus near the center and so that the different densities are visibly different. probably too much perfectionism for that one feature. wish there were more decorative elements to make more of these with, but will need to wait for orchard.
- made the 'undo' feature of the level editor optional; because i've been editing the game off a usb stick recently (so i can work on it on both laptop and desktop) the access time is less than a hard drive, and since it's less, the undo feature makes working in the level editor slower than usual, so i turned it off temporarily.
- found a weird 'division by zero' bug, which troubled me for a while, but after an hour or two of debugging realized that it was related to the grass surfaces feature and fixed it.
- because the script variables (using the keyword var) cause loops to run about 25% faster (no idea why, but it's a well known thing about game maker) i went through all the for() loops that are run every step and made them use var for their counter when they didn't already use it. this will probably not matter very much but it's a simple optimization.
- another small optimization: precalculated a few values used in the draw event of map objects
- added constants for every key character and numeral and used those to replace those ord('M') things with KEY_M. this will be slightly (very slightly) faster, and most of the time not really matter. but it was an easy optimization to do.
- started working on adjusting the speed of the game according to delta time, so that when the game is going very slow (or very fast, if the frames are unlimited) everything still goes at the same speed. so far, did the player's speed, but not the creatures, map objects, or other variables. however, due to the vast and extraordinary amount of time-dependent variables, i suspect fully adapting the game to delta time will take a long time.
- set a minimum frame rate (10fps) below which the game really will slow down, just because if i don't set a minimum the player will appear to 'jump' over things if the game has a hiccup or if the window focus is lost and then returned to the game, but pretty much any computer should be able to run the game faster than 10fps (and those that can't wouldn't enjoy the game at that rate anyway, even without gameplay slowdown).
- adjusted the speed of all objects to delta time. this may still be buggy, haven't thoroughly tested it at all, but preliminarily it works. there are still a few bugs like running past lilypads no longer pushing them in your direction if the frame rate is too high, those can be fixed on a case by case basis as i come across them.
- changed the game to automatically set the 'target' frames per second to the refresh rate (frame rate in the case of lcd's) of the monitor (typically 75 or 60, more rarely 85, 100, and others).
- fixed a cosmetic bug with the depth of the function ghostings/motion blur objects
- fixed a bug with diving through tunnels (it detected it from too far away)
- adjusted some but not all of the 'rotation' globals to delta time. the ones i could not change have to do with the way they are coded (taking the sine, cosine, etc. of the total number of frames since the game started divided by a certain number), and i can't think of an easy way to adapt that to time. it might be possible, but i'll skip it for now since it isn't a crucial thing.

at least these things still need to be adapted to the frame rate, and are currently dependent on the number of frames rather than real time: the delay between firings of the player's functions, the global 'timing' variables which are used for a lot of things, the delay between the actions of the creatures, the room effect fade-in, projectile speeds, path speeds (for argus projectiles or for larba movement, etc.), scrolling text speed, certain creature animations (such as how fast wings are flapped), the change in volumes of the atmospheric effects and music due to standing still, lilypad pushes, particles for water sparkles, particles for player wake, other particles in general, and probably dozens of other things.

- optimized some uses of the string() function each step, such as in the debug message to show the fps, by adapting ID's old string_int() function to SD (it was a function which does the same thing game maker's string() does, but only for integers, and faster, sometimes). went from 500-600 microseconds to 290-380 microseconds for the debug fps display. most of the time string() is only used in debug mode or in edit mode, but there are still a few places it's used in the game itself, like map coordinates display, save slot info display, upgrade function display, and so on. whenever those didn't require decimal precision (and that was usually), i replaced string() with my string_int() function, which should be slightly faster. if anyone wants the function too, see lj-cut.
- started a test game maker file to establish the problems with variables. it seems individual objects can have 10k-30k variables before they crash the game (with no warning about amount, and it varies randomly). it seems gm does in fact slow down the more variables you use, and what matters is individual variable names, arrays count as one 'variable' in that regard (although all array elements and all individual variables take up 1kb of ram each -- 1kb!). i didn't learn as much as i had hoped with this test file, but that's likely cause i had no clear goals with it. the most important thing i came away with is that the problem is not as bad as i had thought, but there are still many things i didn't test, such as whether when you delete an object the memory it used up with its variables/arrays is returned, and how whether strings being stored instead of doubles work any different...
- searched through my game to look at variable/array usage, and realized i use several huge arrays 40x40 (1600 elements) for map data storage: testcircle, worldmap1, worldmap2, worldmap3, worldmap4, cached, and cached-num -- which together add up to about 10000 array elements, which probably adds about 10mb of ram usage. it'd be fully possible to join at least some of these together somehow, since most of them are used in a boolean way (usually just storing things like whether a room has been visited, how many friended creatures are in it, whether all of the creatures in it are friended, whether a room exists, and so on and so forth), which would save 10mb of ram and possibly some speed. but seeing as it may not make much of a difference relative to other optimizations i'll put it on the wishlist for now.
- started working on grass surfaces -- because grass objects were very small and just for decoration (no interaction) drawing them on a surface and then using that surface as one object is an optimization trick. see picture. previously that would have to be made with a ton of individual blade of grass objects, which would slow the game terribly. now that's just three different surface objects, which is a lot faster. in the future i still want to work on varying their sizes and densities and such to make them more interesting than completely random distribution within a square.

( string_int )

today i was asked by two different people to help them with game maker problems, and both times i learned something that would help me. and both were related to views. funny how coincidences work.

first: someone who found me through the gmc's 'mentoring' program (i offer to mentor people in gml and game creation) was asking about how to change the viewport in a room without weird rescaling problems. there's actually no way to do that in GM because you can't change certain aspects of a view that's in use without it scaling horribly wrong. i had a similar problem when changing resolution in SD, so i told him to try separate rooms, one for each viewport. we also had the idea to try changing the current room, and just re-entering it, as a simpler alternative. and that simpler method worked (provided the room was set as persistent). so i now know that i don't actually need 20 different rooms for 20 resolution possibilities in SD, but could reduce that to a single room that changed its own parameters and then re-entered itself. i may make that change later just to save the nearly-negligible load time the 20 extra rooms is using up.

second: someone else (evajolli) was asking about a strange phenomenon where when you change the view, the gui doesn't catch up with the view fast enough, and lags one step behind. this doesn't occur when the view follows an object, only when you are manually controlling the movement of a view in relation to an object. i suggested that we determine if it's a frame off, and try saving the x and y position of the view in the last frame, and then drawing to that position rather than the current position. she suggested using xprevious and yprevious instead of storing them (which i didn't think of) and she confirmed that it works. although i don't use GUI's in SD, i use a GUI for the level editor, and that always lagged a frame behind when the camera moved, so now i know how to fix that.

- tiny optimization to map objects which i'm sure won't matter at all (pre-calculated two values which were calculated every step by a division by 2).
- another optimization to float collisions
- found an interesting gm example which tests the speed of every function in the game and builds a chart of their speeds. ran it and read through the chart. didn't tell me too much i didn't know, except for a few interesting tidbits of info (under the lj-cut)
- discovered a bug: you can now push the pretty purple flowers! but only slightly, so it takes ages to move them anywhere. still, something i need to fix.
- fixed that bug

slept a lot today, so not much work on the game. it was also another very cold day. optimizations are going well though, here is an example of an empty room before and after my optimizations of the mouse cursor and player step and other factors:

(12:44:11 AM) RinkuHero: before: http://pics.livejournal.com/rinku/pic/0011w0gt
(12:44:15 AM) RinkuHero: after: http://pics.livejournal.com/rinku/pic/0011tdsd

note though that such optimizations are still almost negligible in large rooms full of objects, which are still fairly slow. even with the optimizations i sometimes get below 60fps, i'll try to achieve a steady 60fps+ in all rooms on both this computer and my desktop, then implement delta time speed changes.

( interesting game maker optimization trivia )

- continued testing things for the chart (included under the lj-cut)
- optimized player step in a number of ways. some ways: first checks if there is a joystick plugged in before testing for joystick input, and checks for the joystick's existence at game startup rather than every step, and checks if any key on the keyboard was pressed before checking for each individual key (for keyboard movement). music volume changes due to movement now happen only ever 12 steps rather than every step, same with checking for upgrades and first-encounters with creatures. i also unwound a few loops. and i simplified the collisions in a few ways, which makes them much faster (still relatively slow, but faster).
- optimized the object activations code by relating it to player speed (if the player/camera isn't moving, there is no need to check for objects to activate or deactivate due to being outside of the view, and if the player is moving slowly, the game checks for activations/deactivations more slowly than usual)
- optimized the timer scripts a little by removing unused time variables. there is still room for minor optimizations in it though.
- changed all draw_circle_color to draw_circle_color2 (surface optimization for circles and spheres)
- minor optimization to the main object's keyboard input checks (check for anykey first, then check for specific keys) which saved only about 20 microseconds. compared to the average of 16000-32000 (60fps-30fps) microseconds the game takes per frame, that's not much, but i'll take it -- it's like, if you're trying to save up $32000, even $20 matters.
- slight improvement to another function in the main step event which got another 10 microseconds: moved a keyboard check into the keyboard check area (which checks for any key first)
- optimized the engine effect some more with loop unwinding (for the drawing a star function). it's nice that even in this day and age interpreted languages like gml make an ancient optimization trick useful.
- slightly improved mouse drawing speed in arrow mode with a loop unwind
- improved the speed of the 'ghostlines' effect (used in the venusjoins room (0,0)) by making the curves simpler and fewer
- made the effect surfaces not draw unless effects are in effect
- small optimization to blend mode setting routine (first checks if any effects are in effect before checking for each individual effect that affects the blend mode)
- some pre-calculation and other minor optimizations to reflections, but since reflections are by nature hard to measure (varies by exact position so much) i couldn't really test how much those changes improved them
- adjusted reflection heights a bit
- got annoyed that 'ghostlines' were still too slow for that room, and removed them (at least temporarily)

optimizations taking longer than i expected, but shouldn't take too much longer

( chart (more complete) )

http://pc-mmo.nowgamer.com/reviews/pc-mmo/2475/immortal-defence

another review of ID (only got 6.2/10, but a review is a review)

it's actually an old review (written in 07) but this is the first time i saw it, so it's new to me

- optimizations to water particles (the ones which trail the player, and the latent onces which produce shines on the water -- now they vary by current fps, and have a slightly shorter lifetime)
- small optimization to drawing the engine (pre-calculation of a value inside a loop)
- made functions to easily check the average execution time in microsecondsd of any given part of the code over a period of 60 steps
- started making a chart of the most time-intensive parts of the code, in microseconds. the chart, so far, is after the lj-cut / in the extended part of the entry
- installed the power supply (and a new videocard to replace my terrible 8500gt) in my desktop, tested it to make sure it's working, no grinding sound anymore, yay!
- tested SD on the desktop: interestingly i get a max 600 fps with most everything turned off both on my desktop and my this laptop, but in normal rooms (such as 0,0) my desktop gets a higher max frame rate than my laptop (90fps vs 50fps).
- created yet more toggles, such as for text
- tested more things for the chart

( optimization chart so far (incomplete) )

- finished toggles for graphical elements.
- did a few minor optimizations (such as not dividing 1/60 every step to increment the seconds count, but instead pre-calculating that and adding that value every step).
- added the ability to calculate and show the average fps from over the last 900 frames (15 seconds at normal frame rate), reseted every 10 seconds (rather than just the current fps).
- discovered a pointless bottleneck related to holding down ctrl (it caused the game to check for the existence of save files every step, part of the ctrl+number to save/load to slot system) and did a simple fix which reduced the slowdown from holding ctrl down (not that players would do that often)
- discovered something very interesting: disabling the player's cursor (by pressing right click to make it disappear, or by moving around with the arrows or wasd keys to make it disappear) increased the fps rate significantly, from a max of 150 to 300 fps; same thing with the player's sparkly engine (the two pentagrams thing, but nowhere near as bad as the mouse cursor is), so those seem to be bottlenecks. another large bottleneck is the screen-wide effect surfaces. currently in the process of detecting speed bottlenecks, then will order them by impact and address one by one. definitely the mouse cursor first, though.
- made a few scripts aimed at replacing the primitive circle-drawing scripts with alternatives that use surfaces
- simplified mouse cursor, and now it only reduces the fps from 293 to 277 instead of from about 300 to about 150. doesn't look as pretty, but better than slow.
- tested the toggles and made new toggles, i think i'm getting a good idea about what parts of drawing slow the game the most now, and have some ideas for optimizations. preliminarily, sd could stand to gain the most speed by optimizing or removing:

1. mouse cursor (now optimized/simplified)
2. player/creature trails (now turned off by default since they weren't that neat-looking anyway, although i'll keep them for the seena/unicorn)
3. player wake effects (there are two of these, i'll need to test each separately and see what i can do)
4. player engine effect (shapes/glow) (optimized it today a bit, although they can still be optimized some more with some loop unwinding)
5. screen surfaces for effects
6. activations/deactivations
7. collisions (in general, need to separate by type)

there are other things which slow the game down significantly but can't really be optimized, such as drawing map objects, and the existence of objects at all (just having them slows the game down due to the way game maker works). so i don't expect incredible gains from these optimizations -- even turning all 7 of the things mentioned above off totally only raises fps from 50 to 60 in an area that's full of objects. but it's still worth trying.

- changed time measurement from average fps to average milliseconds since last step, using a timer dll. this is more important info actually, because the "distance" between 400 and 500 fps is different than the distance between 50 and 150 fps (it looks like just 100fps, but the difference is 25% longer vs 300% longer), whereas if you measure in milliseconds you just get the time since last step

i'm finding optimizations fun. it's actually been one of my favorite parts of game dev since alphasix -- just trying to rearrange code to get a number to improve has a strange draw to it. looking forward to the next day of work on it. will try to get a new version to playtesters by the end of tomorrow in order to have them test the new speed optimizations.

in other news, today i got the new power supply today, but going to wait until tomorrow (light out) to replace the old one with it.