Sunday, September 2, 2012

*playing "Cataclysm" roguelike by Whales..  V. good. Why did i buy oblivion???? I finally donated 10$ to whales.. since this game came out i have 300+ hours into it.

note: now known as "Cataclysm dark days ahead" with a new maintainer

Wednesday, June 20, 2012

above ground

Project is sidelined for the moment.  Working on sanity and emotional wellbeing instead.

Wednesday, March 28, 2012

Project is on the back burner.  Working hard at womens studies and social psychology at college presently.

Tuesday, January 10, 2012

1-10-2012 Captain's Log

Ok so this is my captains log on starship ridiculous.

I'm living with my brother for awhile.  Like I said, family having some problems with my wife and step daughter.

But he's a great programmer so I'm learning all about the heap, the stack, the cache, etc.

Sounds like he wants to help me optomize some of my code.  And I guess I was using way too many object-access-lookups when I was iterating over the map to draw things. and I understand now that's not a processer but a memory problem. And also I used my line of sight function more than was necessary and that I needed some kind of ray-casting for LOS not just the bresenham line algorithm anymore.  And really I shouldn't be having to write this weird funky graphics bullshit that only updates the current and affected squares of things. that's going to give me hell down the road. what i need is just a simple elegant drawing method that uses ray casting.

So I'm going to overhaul the code somewhat and go back to my old function "drawsurroundingswave" which uses a wavefront, and somehow add consciousness of wavefront direction to the function.. Luke explained, i guess, each square somehow remembers the slope of the line that intersects it and the players square, and it checks the next squares out for being "within a deviation of that line"... Only my brother will help me turn it into a ray-casting sort of thing.  Someday?

Right now I'm starting school and I signed up for a Women's Studies course.  It's exactly what I need.  The textbook is entitled Women: A multicultural perspective.

Sunday, January 1, 2012

1-2-2012 Day after new years

Starting classes soon, dealing with family issues, programming on hold.

Monday, December 26, 2011

12.26.2011 Day after Christmas

summation: graphics problems fixed. New graphics problem found.  Sound and astar pathfinding probably need optimization. Some optomization acheived.

I separated the movement code from the drawing code.  Now any object that has "needs los to be seen" is on a list and gets drawn if it's on the screen.  Now, at least, an unmoving monster will not be invisible - it gets it's LOS checked and if it's true, it gets drawn, wheras before, only moving monsters got their graphics updated.  I could probably check for a "just moved" variable to optimize things, and only update the graphics of those who move, but then I'm back to having the same problem.

The game is getting slow.  I've worked on all different code over the last few weeks as it's slowed down - mostly with the addition of the sound code.  I'll have to expirament and see what's eating up the processor eventually. I usually work on all different code projects and then do a whole bunch of optimization all at once.  If it turns out to be the sound code that's slowing things down I think an "auditory memory" for denizens so sounds dont have to be generated so often.  That will probaly take making sounds more complex also, they'll probably each need an identifier like "ob.id.."_"..type_sound_name) so that walking sounds overwrite walking sounds... that's one idea instead of an auditory memory.  Then sound data would be self-updating.  I would just need a "cleaner" function to delete aged, un-updated sounds from the soundscape.

But at least ghouls who are unmoving are now seen.

Still working on the undrawn squares in the forests where the deer were "just" standing on player screen-transition, but it draws correctly when he steps out of the ditch....  All I can think is that the tree gets drawn, and it's upper level over the deer's location is not drawn...

---Later that day:

--Fixed-- Unmoving ghouls now seen.
--Fixed-- No more vision trails! (they had reappeared due to yet a different bug in new programming. ugh.)
--Fixed--Undrawn squares in forest where deer were standing on refreshscreen is fixed!  Not sure what I did but I was fixing graphics in general and must have corrected the problem.

my Wife is knitting.  Not sure why.

Todo: Either sound generation or a-star pathfinding is eating up my processor.  Will have to optimize one or the other or both.

Later on:

So I found another graphics problem that I cant seem to solve.  Whenever my creatures move off of the screen to the north, they leave a graphics trail.  If they move off of the same square to another square on the screen, I'm pretty sure they redraw their old square.  I occasionally check for things "off the edge of the screen" but I couldnt seem to find any errors in that.  When they move off the screen to the south, they dont leave a graphics trail.  ugh.

Sunday, December 25, 2011

12.25.2011 Christmas Day

Christmas was awesome, got plenty of charcoal now for drawing.

I chatted over STEAM to my brother Luke for a long time today about AI coding, emergent behavior, lua debugging, and got some great ideas.  I also came acros two articles that will affect my future AI coding.  I am going to implement "heading awareness" to the movement of my deer somehow, to better simulate herding, and rewrite the movement code.. AGAIN.. LOL!  Probably theres a clever way to do it.  And there's probably a simple way to get those wolves to encircle prey, according to the second article:

Here are the two articles:  One is on flocking artificial birds
http://www.red3d.com/cwr/boids/

The other is on the logical rules of wolf hunting that create emergent circling of the prey:
http://www.sciencedirect.com/science/article/pii/S0376635711001884
and
http://intrinsicalgorithm.com/IAonAI/2011/10/what-real-wolves-can-teach-us-about-our-ai/
and
http://www.newscientist.com/article/mg21228354.700-wolf-packs-dont-need-to-cooperate-to-make-a-kill.html