dev-diary.txt

2/20/16

http://www.mattgreer.org/articles/a-game-made-with-reagent/ talks about using css animations; TODO

https://rafalcieslak.svbtle.com/9-tips-for-clojurescript-beginners has a few good links
mentions checkout dependencies

======

2/21/16

https://developer.mozilla.org/en-US/docs/Games/Techniques/Efficient_animation_for_web_games
****** this article appears to be super good
has tips on how to avoid drawing things multiple times per frame (which would be a waste)
mentions https://github.com/BernieSumption/animator.js which is super old
cf http://blog.berniesumption.com/software/animator/
" For a modern library that exposes CSS animations through a similar API, I recommend jQuery.Transit."
so maybe the mdn article above is real out of date?

https://developer.mozilla.org/en-US/docs/Web/API/Window/requestAnimationFrame

anyway tbh i think i should probably be using canvas instead of svg for a bullet-hell shooter/rpg
i think reagent+svg/divs/whatever makes tons of sense for turn-based games like cljstone
but for a boi clone, it really seems like square peg round hole

css/svg/etc animation links for later if i end up wanting them:
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Animations/Using_CSS_animations
https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Transitions/Using_CSS_transitions

anyway overall it looks like css transformations/animations are useful for situations where, like,
you've got a particular UI that you want to animate - but i don't think they're at all relevant for
a game in a web browser, it just doesn't make any sense

re: reagent and canvas (already expected these two wouldn't work together):
https://www.reddit.com/r/Clojure/comments/3cq5hg/can_reagent_components_work_with_html_canvas/
"No, and I've tried: https://github.com/gzmask/embodier-gcode-webgl"


canvas resources:
https://github.com/rm-hull/monet [seems abandoned; TODO read anyway, might have good ideas]

core.async and keyboard events: https://github.com/bdrillard/async-key-events

had trouble getting access to goog.events.KeyCodes, was given
http://clojurescriptmadeeasy.com/blog/when-do-i-use-require-vs-import.html in slack

TODO what the hell is an entity component system
https://github.com/markmandel/brute
https://github.com/muhuk/clecs
https://github.com/weavejester/ittyon

TODO what is http://wercker.com/

http://hueypetersen.com/posts/2016/02/13/om-next-from-a-relay-graphql-perspective/
incomprehensible om.next/relay/redux/graphql post

https://eklitzke.org/effectively-using-bash-profile evan notes on .bash_profile vs .bashrc

http://hueypetersen.com/posts/2013/08/02/the-state-machines-of-core-async/ core.async implementation
http://hueypetersen.com/posts/2013/07/10/code-read-of-core-async-timeouts/ also good post on timeout!

http://hueypetersen.com/posts/2013/06/17/angular_is_slow/ - unrelated, but good quote:
"Your model is not your view model. It can be for simple cases, but as soon as you start feeling
friction you want to let the view model evolve instead of changing your domain models to suit the view."
****** gold stuff

ok so what is https://github.com/pedestal/pedestal
i remember this being announced at clojure/west a while back but don't know anything about it
lol "Our primary focus for the near future is Pedestal documentation, sample applications and
improving general ease of use."
so i think i can be forgiven for closing this tab and checking back later
https://github.com/pedestal/pedestal/tree/master/guides/documentation for the record

edmund says to use https://github.com/edmund-huber/sssgen for my blog
i'm sure he's not biased

https://en.wikipedia.org/wiki/Entity_component_system - see "game example" section
really good info
one of the main touted advantages is "composability instead of inheritance" - so is ECS still relevant in cljs?
the description of components sounds a lot like clj/s protocols

https://stackoverflow.com/questions/1901251/component-based-game-engine-design
the guy in that answer says use FRP instead of ECS

https://web.archive.org/web/20140719094839/http://www.altdev.co/2011/10/08/a-handful-of-components/
********* good shit
"The health component is probably the component that I re-use the most. Not just a health value that goes up
and down it also keeps track of invulnerability, regeneration and poison. It also looks after the entities
damage modifies with the following types currently supported Fire, Ice, Melee, Projectile, Magic and Crushing"

notes before i forget

what does game state end up looking like? do we end up adopting some ecs concepts and going with like

state: {:entities [Entity]}
Entity: {:id s/Int
         :components [Component]}

having an id helps for generating ^keys
what do rooms look like? are they some sort of, like, container components?
or do we have an :entities list and a :rooms list? the player's only in one room at a time if that's relevant

=======

2/22/16

https://www.youtube.com/watch?v=9sc8Pyc51uU
******* great talk on graphql / relay

https://github.com/devknoll/graphql-resources graphql links

https://www.youtube.com/watch?v=UoZyyo2Bwr8 talk on hoplon/javelin
difficult to tell how to reason about it with regard to reagent
he trashtalks the virtual dom for a while but i don't think all his criticisms apply
not a super big fan of the tone of this talk in general, the tech looks useful but not much different from reagent

reading https://github.com/evancz/elm-architecture-tutorial/

TODO for boi what will movement look like? does a player have a :bounding-box {x y width height} and a
:movement-state [:down :right]? that could work.

at some point i want to read the react dom-diffing code but i have 600 other tabs to process first

ok time for http://elm-lang.org/guide/reactivity
"Note: It is usually best to use signals as little as possible. When it comes to writing nice modular code,
you should primarily use normal functions and values. If you find yourself stuck with a signal of signals,
ask yourself “how can I model this explicitly with functions and values?”"

https://www.reddit.com/r/elm/comments/3s6lhb/learning_elm_vs_haskell_as_an_intro_to_functional/ elm vs haskell

reading http://elm-lang.org/blog/blazing-fast-html
"Virtual DOM sounds pretty slow, right? Create a whole new scene on every frame? This technique is actually
widely used in the game industry and performs shockingly well for DOM updates when you use two relatively
simple techniques: diffing and laziness." *******

"game industry" phrase links to https://en.wikipedia.org/wiki/Scene_graph

https://pchiusano.github.io/2014-07-02/css-is-unnecessary.html advocates using a lang like elm instead of css
"A little reflection on the history of software reveals abstraction as the primary means by which humans
make increasingly complex software possible and comprehensible."

https://news.ycombinator.com/item?id=9797973 om rant thread


************
okokok here's what i want to build
bullet-hell, twin-stick, top-down, boi-style combat/gameplay (except tear height, fuck that)
boi-style items
diablo-style levels (randomly generated floors rather than rooms; hallways, forests, whatever)
simple RoR-style leveling (don't care about skill trees / talents, just want to avoid staying at base damage
  forever like you often do in BoI)

updated state sketch
state: {:entities [Entity]
        :mode (s/enum :menu :loading :normal :etc)}
Entity: {:id s/Int
         :type (s/enum :player :bullet :monster :wall :etc)
         :components [Component]}

************

elm architecture notes:
https://gist.github.com/evancz/2b2ba366cae1887fe621
talks about advantages of having a centralized home of application state - single source of truth


what does main game loop look like?
*****
`
update-movement-state ; let monsters decide to aggro, leash, change their direction, etc
update-movement-speeds ; update dx, dy
update-positions ; update x, y (should we combine this with update-movement-speeds? unclear)
update-status-effects ; poison, invincibility, etc
calculate-collisions
update-health (? or does calculate-collisions do this? what does calculate-collisions do? add to a queue of
  unresolved collisions? something else?)
perform-attacks (player and monsters can have an :attacking state, with an :attacks-per-second or something)
`
******
what else?
can these things be done in parallel? how?
i guess you could have each use pmap instead of map, that could work pretty well actually

what does poisoning look like? a PoisonComponent and a poison-system?
maybe StatusEffects and an apply-status-effects system
i kinda like that a lot actually

bullets can't collide with other bullets
so there's an Owned component maybe

interesting notes on virtual dom / diffing: https://gist.github.com/Raynos/8414846
http://calendar.perfplanet.com/2013/diff/
good notes on setState effects, dirtiness setting, etc

http://t-machine.org/index.php/2012/03/16/entity-systems-what-makes-good-components-good-entities/
lots of example entities, components, systems

"Ideally, you add a new component when you have a new “dimension” to the game objects. For instance,
if you’re adding a physics System, you may not need to add any new Components – it might be that all
you need is Location (containing x,y,x position and dx,dy,dz velocity) and RenderState (containing
screen-pixels x,y) – and that you already have those components."

***** note re xyz position, dxdydz velocity ******

note warnings re: "Many systems per component" being a warning sign
the two versions of badness listed:

You have – say – 8 variables in the struct where you should instead have two structs (components),
one with 5 variables, the other with 3.
You have – say – 4 variables in the struct, but different systems are using those variables to mean
different things. It works OK for now, but it’s very fragile – as soon as the different meanings
diverge even a little, your code is going to start breaking

goood shit in this article man

in the comments:
"In regard to components a good idea at times is to stuff as much data into a single component that
covers the complete purpose. This cuts down referencing multiple components over and over and there
is definitely a speed up in a tight loop. A good example of this is physics where in my efforts I
provide a default “KinematicsParams” component that has velocity, position, rotation, angular velocity,
angular rotation, etc. etc. all stuffed into one data component. The reason being is that instead of
referencing a single component for each parameter it’s much easier / quicker to reference one."

"Q: What are the thoughts about having components that dont have any data, but instead exists to label
a entity in a way. A: I’m all for it."

http://t-machine.org/wp-content/uploads/Aliqua-progress-2015-BUUG-v3.pdf describes entity systems

via http://entity-systems.wikidot.com/ -
Entity - A container into which components can be added,
  ****usually hierarchical (any Entity can have sub-Entities).****

"Whereas in an inheritance-based design, an enemy may have a complex inheritance chain such as
Damageable <- Actor <- GroundBasedActor <- Enemy <- ZombieEnemy, in a C/ES-based design you might
have a Health component, a GroundBasedMovement component and a ZombieAi component added to
an entity named ZombieEnemy."

"Rendering and updating may take place either by traversing the entire entity tree (slow), by
having entities register themselves to the respective services (service locator hell) or in a
hybrid approach where the renderer/clock system remember which components they found in the tree
while entities merely provide a change notification if components are added to them or removed
from them, allowing the renderer/clock system to re-check that part of the tree (complex).
This aspect of the design is however not part of the C/ES pattern."

http://t-machine.org/index.php/2007/11/11/entity-systems-are-the-future-of-mmog-development-part-2/
definition of entities/components
"For every discernible “thing” in your game-world, you have one Entity. Entities have no data and no methods."

all this stuff is very clojure-y - clear separation + composition of data and behavior
"Typical Systems in a game would be: Rendering System, Animation System, Input System, etc.
 The Rendering system wakes up every 16 milliseconds, renders every Entity that has the Renderable
 Component, and then goes back to sleep."

"But the vast majority of game development is orders of magnitude more complex than Chess.
If you try – for instance – to write a computer game of Chess, that has AI … you certainly
don’t have “a movement and position component”.
Instead, you have: movement, position, potential positions this turn, potential positions on
future turns, threat radius, threatened squares, tactical options, strategic options, available
“plays” (famous chess strategies), enemy-histories-per-piece (what does your opponent tend
to do with pawns?) … etc."

http://t-machine.org/index.php/2007/12/22/entity-systems-are-the-future-of-mmog-development-part-3/
"So, don’t be tempted into hierarchical encoding, and definitely don’t do ANY encoding in the entity names"
“a System essentially provides the method-implementation for Components”.

components - data
systems - behavior
entities - id'd collections of data

"Mathematically-speaking, an Entity is a database Key, just as you’d see in any RDBMS.
Likewise, from a purely abstracted point of view, the “set of component-instances that comprise
Entity #7742” is, literally, a database Query.
THIS is why I said at the start that, ideally, you do NOT want to store your component-instances
as a list inside a struct/class representation of each Entity. Fundamentally, that set is NOT
defined as a list (a list is a static thing, it’s members don’t change without you changing them),
it’s defined as a query (whose members are always changing, whether you want them to or not),
and using one where really you wanted the other tends to cause problems in the long term."

hm - does all that still apply in clojure-land?
yeah prob not he says this is mainly for giant server-side games, which makes sense but
won't be super relevant for my tiny little client-side game

http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
good article, not much different from the stuff above in t-machine
does have stories about introducing this design architecture into a preexisting system, neat

"Ideally, components should not know about each other. However, in a practical world, there
are always going to be dependencies between specific components. Performance issues also
dictate that components should be able to quickly access other components. Initially we had
all component references going through the component manager, however when this started using
up over 5% of our CPU time, we allowed the components to store pointers to one another, and
call member functions in other components directly."
hrm

http://scottbilas.com/files/2002/gdc_san_jose/game_objects_slides.pdf
"– Examples are trees, bushes, monsters, levers, waypoint markers, doors, heroes, inventory items
 – Many are “pure logic”, never see them (triggers, elevator movers, camera sequences)"

======

2/23/16

https://news.ycombinator.com/item?id=5116615 rant on ECS / clojure performance for games
fuck this guy tho

anyway i had a lot of ideas re: game this morning, jotting them down

current favorite name: voke (as in invoke, evoke, voco)

things i like about teleglitch:
punishing difficulty
setting/aesthetic (irrelevant, i'm not doing much art design here)
general terror about what's around the next corner
not so much into the crafting system, but was a fan of the health / armor system

bullets should be rectangular and thinnish rather than squares

if we end up making levels with hallways, i'm worried about the player cheesing the game by just
  funnelling all enemies through a hallway and shooting at them
i guess just don't have hallways?
what about doorways though?
i guess just have all doorways be way bigger than the player's/monsters' hitboxes, so monsters can always
  chase through really quickly

http://t-machine.org/index.php/2014/03/08/data-structures-for-entity-systems-contiguous-memory/
super good article
sort of unclear how to apply it to cljs tho

TODO - are deftypes/etc more performant than maps in cljs?

*****************
http://t-machine.org/index.php/2013/05/30/designing-bomberman-with-an-entity-system-which-components/
******* good shit
****** fuckin gold
"…if data should be in two components, but you can’t decide which: create a third component for it"
ok let's move all this stuff over to a new repo so i can start taking detailed game notes

ok per that post

behaviors:
move a player/monster/bullet in the direction is velocity indicates
player/monster runs into a wall, can't go farther in that direction
player/monster fires a bullet up/down/left/right
move a bullet along its vector
bullet collides with a player/monster, disappears, decrements health
monster/player collide, decrement player health
kill a player/monster
monster decides to aggro or leash
player/monster decides to change direction
player/monster decides to want to attack in a particular direction
player uses an active item
player picks up an item
camera moves to follow the player

data:
player/monster/bullet/wall collision-box
player/monster/bullet dx/dy velocity
player/monster/bullet top speed / acceleration
player intended move direction (8 options)
player intended fire direction (8 options)
monster intended move direction (360 degrees)
monster intended fire direction (360 degrees)
player/monster health
player armor
player xp
player/monster level
player inventory
player/monster bullet effects
bullets in flight
bullet owners
player/monster attack state [range, frequency, time since last shot]
item name and effect
camera
background


TODO how to take keyboard wasd/arrow input?

TODO look into public domain sprites for players/monsters/bullets/whatever

http://t-machine.org/index.php/2013/05/30/designing-bomberman-with-an-entity-system-which-components/comment-page-2/#comment-1274479
really great question
never gets an answer!

http://t-machine.org/index.php/2013/05/30/designing-bomberman-with-an-entity-system-which-components/comment-page-2/#comment-1274784
**********

http://t-machine.org/index.php/2012/04/19/concepts-of-object-identity-in-game-programming/
******* has notes on how systems can communicate with one another
eg kill enemy, enemy drops loot

*********
http://shaun.boyblack.co.za/blog/2012/08/04/games-and-entity-systems/ other guy's list of components/etc
******** GREAT post

http://www.richardlord.net/blog/what-is-an-entity-framework
ECS vs game loop
not much new info after i've read all the stuff linked above, but overall a great standalone post
"The collision system, which tests whether the player is colliding with other objects and
resolves those collisions."

"The systems are decoupled form each other. Each system knows only about itself and the data
it operates on. It knows and cares nothing at all about the other systems and how they may
have affected by or used the data before or after this system gets to work with it."
hm, discourages systems from communicating

but later...
"In most games, ***some*** of the systems are entirely independent of each other, including being
independent of the order in which they are applied. This makes it easy to run these systems in parallel."

anyway i mean i've been reading a bunch of this stuff and it's all cool and helpful but i'm not sure
how much of it applies in clojureland. in clojure you'd just be passing maps around to different functions
anyway, you'd have a clear separation of code and data, which is what ECS is all about.
so at the end of the day the main distinction is between, like, do i have game objects like this?

{:id 123
 :type :player
 :position a-position
 :velocity a-velocity
 :intended-movement-state an-intended-movement-state
 :firing-state a-firing-state
 etc
}

or do i have objects like this:

{:id 123
 :components [player-controlled, a-position, a-velocity, an-indended-firing-state]
}

ECS is all about the second option i think, although it's sort of six-one-half-dozen-other, maybe doens't matter.
might as well give it a shot

TODO - what does player-controlled look like? does it contain both intended movement direction
  and intended firing direction? what about active item usage, how does that work?

http://gameprogrammingpatterns.com/component.html
****** has a section on how components communicate with one another!!!!!!

"sending messages" - sounds familiar

so i guess the idea proposed here is that entities have a "send" function, and components have a
"receive" function
i mean that's all pretty OO
in clj, it'd probably look more like

(messaging/send an-entity-id a-message)

that seems reasonable

but what does it end up actually doing? like let's say we do
(messaging/send 1234 {:type :player-direction-input
                      :value :UP})

where does the code live that handles that message?
i guess you let components subscribe to specific types of messages and have some sort of "bus"
(what does that term even mean?) that coordinates all this; i know core.async has facilities along these lines

hm hm hm

"Some domains are distinct but still closely related. Think animation and rendering, user input
and AI, or physics and collision. If you have separate components for each half of those pairs,
you may find it easiest to just let them know directly about their other half.

Messaging is useful for “less important” communication. Its fire-and-forget nature is a good
fit for things like having an audio component play a sound when a physics component sends a
message that the object has collided with something."

hm i'm not sure about the messaging/send stuff from above

ok so what about if like for instance the physics component just adds a PendingAudio component
and the audio system looks for PendingAudio components on each tick, plays them, and removes them

and so the velocity component directly reads from the player-input component

and the player-input component is... directly sent messages via the UI?
hm how does it get its stuff

i guess the game's business logic is a module that has a clearly defined API
and only has a few specific public functions

(accept-player-input a-message)
(let-time-pass time-delta)

and so accept-player-input is a function that under the hood modifies components, and even then
just like the direction the player is intending to move and fire

and also i guess like (pause-game) etc

so what does the game's state currently look like?

{:entities [Entity]
 :mode Mode ; for pausing, menus, game over, whatever
 :active-level an-entity-id ;?
 ; maybe a channel but probably not, it can be local to the root reagent component
}

https://gamedev.stackexchange.com/questions/31473/what-is-the-role-of-systems-in-a-component-based-entity-architecture/31491#31491
not sure about the metaphor, but the main message is that systems can read from multiple components at once
*** for perf, it suggests having each entity have a bitfield indicating which components it has; that could work

https://github.com/ibdknox/ChromaShift/blob/master/cljs/game/levels/first.cljs
**** level built in clj with an ECS
"In ChromaShift's case the core structure and caches for the engine are actually written in
JavaScript for performance reasons, while all of the game CES is written in ClojureScript."

http://www.clojure-games.org/component-entity-system

https://github.com/muhuk/clecs-examples/blob/master/clecs-example-roguelike/src/clecs_example_roguelike/entities.clj
example entities/components

i like https://github.com/muhuk/clecs/blob/master/src/clecs/system.clj -
rather than having systems just be functions, he has them be maps
so in addition to a function that takes a world and returns a new one, he has other metadata too like
:name :rendering
:reads #{:Inventory :Renderable}
:writes #{:Inventory :Location}
interesting! overkill or helpful/necessary?

http://alexkehayias.tumblr.com/post/78711349238/entity-component-model-in-clojurescript
ecs with protocols/records

https://github.com/alexkehayias/chocolatier/ yet another system that talks a lot about:
"Think about it less as a bunch of objects with their own state and methods and more like
a database where you query for functionality, state, based on a certain aspect or entity."

i've seen this talk of databases+queries like 10 times now in reference to ECS, not sure
what i think about it

chocolatier has notes about cross-component communication
"A global pub-sub event queue is available for any component enabling cross component communication
without coupling the state of any of the components. For example, suppose the render component
needs to update the screen position of the player sprite. The render component needs information
from the input component, but we don't want to couple the state of either components together.
Instead of directly accessing the input component's state from the render component we subscribe
to messages about player movement and update based on that. We can broadcast that information without
any knowledge of who is listening to it and no one can change the component state from another component."

not sure i 100% agree with the components he's come up with, but anyway here's another bit of precedent
for messages / pubsub

"Any component can subscribe to events by creating a component with a :subscriptions key in the options
hashmap where each subscription is a vector of selectors:
 (mk-component state :player1 [component-f {:subscriptions [[:e1] [:e2]]}])
The subscribed component will receive the event in a hashmap in the :inbox key passed in as the
third argument to the component function. Messages that are sent are available immediately to
the subscriber which allows for events to be sent and received within the same frame and are
therefore order dependent."

interesting

"ClojureScript presents challenges for optimization including garbage collection, persistent
data structures, and functional paradigms that js engines may have difficulty optimizing."
eep

"Where appropriate, transient state should be used when operating on large collections and
hashmaps for better performance. See chocolatier.macros in the clj source directory for
helpers with transient state. "

re: performance
https://stackoverflow.com/questions/21721028/how-to-improve-clojurescript-performance
"Now, if performance is really critical to what you're doing and persistence provides
no benefit, you can just use arrays and objects from ClojureScript:"
"By using records and native field access, you can cut the runtime for your
original ClojureScript solution in half"

http://numergent.com/2015-12/ClojureScript-performance-revisited.html
******
"As we can see it’s doing this with a regular vector, which we can easily turn into a
transient one and persist it once we’re done."
bought him 1 fps, 12->13
lists other, more impactful techniques
mentions `keep` as a one-pass map+filter

http://davedellacosta.com/cljs-protocols notes on protocols

http://www.bestinclass.dk/blog/brians-brain-optimized-clojurescript-html5

https://swannodette.github.io/2013/06/10/porting-notchs-minecraft-demo-to-clojurescript/ nolen on perf

okok that's enough reading for now
tomorrow i should be able to start actually coding something
and constantly be terrified that i'm violating all the principles i've read about or some shit

TODO look into a good canvas js library that i can use via cljsjs

https://web.archive.org/web/20140509212857/http://resatori.com/clojure-entity-component-system

unrelated: http://yogthos.net/posts/2016-02-22-LuminusEmbracingHugSQL.html - yesql no longer developed?

http://elbenshira.com/blog/the-end-of-dynamic-languages/
http://yogthos.net/posts/2015-11-28-TheSkyIsNotFalling.html
dunno about this argument

http://retroaktive.me/blog/keechma-design-decisions/

https://github.com/tonsky/datascript - relevant for storing entities?

======

2/24/16

ibdknox uses a js stats library in https://github.com/ibdknox/ChromaShift/blob/master/js/lib/stats.js
see https://github.com/ibdknox/ChromaShift/blob/master/cljs/game/lib/dev.cljs

he uses ! and ? as aliases for aset and aget, not sure if i like it but here we go
https://github.com/ibdknox/ChromaShift/blob/master/cljs/game/lib/core.cljs

physics in https://github.com/ibdknox/ChromaShift/blob/master/cljs/game/lib/physics.cljs
note the Box2D library he seems to be using

ok you know what i think my entities are just going to look like

{:id 1234
 :type :player
 :position a-position-component
 :bounding-box a-bounding-box-component
 :etc etc}

rather than

{:id 1234
 :components [a-position-component a-bounding-box-component etc}

i think that the second style makes a lot of sense if you're outside of clojure and are used to OOP and
trying to force yourself out of it, but i don't think it's required here. i also think that the second
style is particularly good about discouraging components from communicating with one another, and also
that it probably makes a lot of sense in eg an MMO where you have a jillion entities and a jillion components
and you want to store their relationships in a RDBMS. but that's not us here. so i think i'll just use dicts.

http://box2d-js.sourceforge.net/ here's that box2d library
more relevant if you want gravity, etc; let's skip it imo

still having a lot of trouble figuring out what position components should look like
are they just an :x and a :y, or do they also have a :width and a :height?
i know that ideally :width and :height would be for bounding boxes, but like what *doesn't* have a shape like that?
i think in this game i'm going to have everything be rectangular, so nothing
so you have a :position with an :x and a :y and a :width and a :height
and you can also optionally have a CollisionBox with a :width and a :height
things that don't have collision boxes: scenery, basically nothing else
end of level has a collision box so you know when the player's walked into it
items/pickups have collision boxes for same reason
so i guess collision boxes have some sort of like :obstruction true/false field

seriously do look into that stats.js thing, it looks legit
https://github.com/mrdoob/stats.js/
note the bookmarklet!!!!

ok cool this bookmarklet works:
javascript:(function(){var script=document.createElement('script');script.onload=function(){var stats=new Stats();stats.domElement.style.cssText='position:fixed;left:0;top:0;z-index:10000';document.body.appendChild(stats.domElement);requestAnimationFrame(function loop(){stats.update();requestAnimationFrame(loop)}); document.getElementById("ms").style.display="block"; document.getElementById("mb").style.display="block";};script.src='http://rawgit.com/mrdoob/stats.js/master/build/stats.min.js';document.head.appendChild(script);})()

lots of notes from my walk, going to try to get them all down before i forget them
you have a few systems that run every tick
movesystem, firesystem
they read from intended-move-direction and intended-fire-direction
which for human-controlled entities is written to directly by the keyboard (via an interface)
and for AI entities is recalculated every tick [so there's another one that's run every tick]

but most of your systems just listen to events
collisionsystem listens for intended-move messages
damage system listens for contact messages
xp system listens for kill messages
etc

and so you have this like event graph / dependency graph between the systems
and so you have a few that are running every tick, and most of them always running and just listening
for events constantly
and the rendering system runs every tick too


unrelated
status effects:
poison
freeze
knockback
slow
stun (same as freeze?)

okok so we're almost ready to get started but first i want to make sure my ideas about events + ECS
aren't completely insane, so i have a bunch of google tabs open about that

https://github.com/MovingBlocks/Terasology/wiki/Entity-System-Architecture talks about events
cool-looking project btw, voxel world thingy

"ComponentSystems, or Systems for short, provide behavior to entities. They do this in two ways
Processing entities with a desired set of components in response to engine method calls like
initialise(), update(float delta) and render()
Responding to entity events sent to entities with a desired set of components"

yeah, that sounds kinda like what i have in mind, cool

"The health system would respond to an entity with a Health component receiving a Damage event,
in order to reduce an entity's health - and if the health reaches 0, send a Death event to the entity"

in this design of theirs, *entities* receive events rather than systems receiving events. not sure if
i agree with this, prob won't do that

https://github.com/MovingBlocks/Terasology/wiki/Entity-System-Architecture#events-and-event-handlers good shit

" Systems can then provide event handlers to pick up specific events that have been sent entities
with a desired set of components. Expanding on the Damage event, you may have a System that handles
damage events that occur on entities with health components, in order to reduce health. Or a System
that handles damage events for entities with a location and physics component, to knock the entity
away from the damage causer."

i'm still not convinced that sending messages to entities is correct

"Events also support cancellation - this allows a system to stop an event before it
eaches systems with a lower priority - for instance if you add an invincibility component
to make an entity temporarily immune to damage, you can add a system that will intercept
the Damage event and cancel it before it can reach the health system."

hrm hrm hrm

https://www.gamedev.net/topic/643311-events-and-entity-component-systems/
good first post, bad responses

https://gamedev.stackexchange.com/questions/47476/tips-for-component-based-entity-system-message-handling
"Although I haven't implemented a way to handle events (other than entity-related events),
I left that up to the user" lol

https://gamedev.stackexchange.com/questions/83767/communication-pattern-in-entity-component-system
"There is no right answer to your question and a lot of it comes from personal taste and out of need."
fair nuff

http://unity-coding.slashgames.org/component-based-entity-systems-event-driven-systems-to-implement-the-logic/
"As a system is very self-contained, events are the way to communicate with other systems and the world
outside a system in general."
yes yes fine ok

http://forums.xkcd.com/viewtopic.php?f=11&t=81459
"the major strength of component systems: you minimise communication overheads and you can easily "batch" updates."

http://tarheadstudio.com/entity-component-system/
"Have you considered an event system of some sort on top of this?"
"Yes. The way we have solved it is rudimentary though: systems send messages, which is an object with
some data, to a game manager, who propagate the message to every other system."

ok so at this point i'm convinced that my design is good

******
so we're going to go with the style of entities/components that i talked about at the start of today's notes
and there will be a bunch of systems that exist
and some systems will run on every tick
and other systems will just listen for events
and there are some examples of those two kinds of systems in today's notes above
rad

https://github.com/tonsky/41-socks/blob/gh-pages/src/forty_one_socks.cljs

http://www.compoundtheory.com/ prettiest blog ever
http://www.compoundtheory.com/brute-entity-component-system-library-0-2-0-the-sequel/
started side-effecty, went functional
ok so anywyay i'm not going to use brute

http://www.compoundtheory.com/writing-a-game-feels-like-im-going-around-in-circles/
TODO free sprites at http://www.widgetworx.com/spritelib/
apparently http://www.physicsclassroom.com/ is good for physics

http://www.compoundtheory.com/mini-game-dev-diary-1/ cool stuff

http://www.pixijs.com/ claims to be super fast

ok so i need to pick a rendering library
first contenders i found are phaser, fabric, and pixi
phaser appears to sit on top of pixi (but not any more i guess) and to be a full-fledged engine
i think that is *not* what i want, and that i want pixi or fabric instead
i just want a renderer, i don't want someone else's game engine

https://github.com/alexkehayias/chocolatier (seen above) uses pixi, read through its source if i go with pixi

http://sam-koblenski.blogspot.com/2015/08/a-barely-adequate-guide-to-javascript.html some guy who goes with pixi

"Anyway, I tried a few different options when I was building the tool, Fabric.js, Famo.us,
but nothing had close to the performance of PIXI."
hrm
pixi does have more stars/etc
i guess i'll prob go with it

https://groups.google.com/forum/#!topic/flashcodersny/rU0-3zD7QIo this guy says pixi over fabric

stumbled over http://squirrel.pl/blog/2013/03/28/two-ways-to-access-properties-in-clojurescript/ yet again
**** use only aset/aget when interacting with javascript libraries

ok so i'll go with pixi for now and if it feels too heavyweight i'll switch to fabric

http://www.mase.io/code/clojure/2015/02/07/pixi-cljs/
https://github.com/maseb/lab-pixi-cljs/blob/master/src/pixicljs/core.cljs
https://github.com/maseb/lab-pixi-cljs/blob/master/src/pixi/core.cljs

TODO next task is going to be to spend some time with pixi, make a pixi.cljs that wraps it

TODO i think the rendering system is going to have to subscribe to movement events
like, successful-move events, ones emitted by the collision system
whenever a successful move happens, the relevant entity's pixi object needs to be mutated to reflect the
new position

collisions:
https://gamedev.stackexchange.com/questions/33731/collision-detection-and-response-in-an-entity-system

*****
ok so the goal for tomorrow is to work on the `pixi` branch
learn a lot about pixi by reading and playing around with it
begin work on a wrapper library for it
and begin work on a pubsub event system so that the render system can subscribe to move events

ignore the concept of collisions for now, forget they exist

=========

2/25/16

here are my goals for today

design and build a simple event system
codify schemas for systems
  they can have an :every-tick field whose value is a map like
    {:reads #{:render-info :position}
     :fn (fn [entity] entity) ; TODO should this take a single entity or a list of entities? prob the latter for perf?
     }
  they can also have an :event-handlers field whose value is a list of maps like
    {:handles an-event-type
    :fn (fn [event] something) ; TODO should this also take a system? what values should it return? does it just perform side effects?
    }

...and ideally i'd like to start wiring the rendering system up so that it listens to events
that are emitted by the movement system (because pixi.js relies on mutability, so we'll
like have all of these objects in flight that represent each entity, and so when each
entity moves we have to mutate its corresponding object's x and y, etc),
but i doubt that i'll get to that today.

let's just mainly focus on designing an event system (likely using core.async) and codifying
the schema for System.

pixi links to look at later, haven't processed these yet:
http://sam-koblenski.blogspot.com/2015/08/a-barely-adequate-guide-to-javascript.html
http://www.mase.io/code/clojure/2015/02/07/pixi-cljs/
https://github.com/alexkehayias/chocolatier/blob/5bc509f32f12411848c995f1e11ef917e87d6cbb/src/cljs/chocolatier/engine/components/renderable.cljs
https://github.com/alexkehayias/chocolatier/search?utf8=%E2%9C%93&q=pixi
https://github.com/alexkehayias/chocolatier/blob/dev/src/cljs/chocolatier/engine/systems/render.cljs
https://github.com/alexkehayias/chocolatier
https://github.com/pixijs/pixi.js
https://pixijs.github.io/docs/
http://www.goodboydigital.com/pixi-js-tutorial-getting-started/
https://github.com/maseb/lab-pixi-cljs/blob/master/src/pixicljs/core.cljs
https://github.com/maseb/lab-pixi-cljs/blob/master/src/pixi/core.cljs

ok
so what should our event system look like?

core.async pubsub info
https://github.com/clojure/core.async/wiki/Pub-Sub
...hrm

https://yobriefca.se/blog/2014/06/04/publish-and-subscribe-with-core-dot-asyncs-pub-and-sub/

"While the pub/sub mechanism provided by core.async is higher level than working directly
with chans and mults to achieve the same thing (in fact that is how the pub/sub operations
are implemented internally) it should still be considered a set of lower level primitives
compared to say a specific event bus notification with topic namespacing, wildcard broadcasting
and other such specialised features."

"I found the idea a bit easier to understand when I thought of the publication as a
realised topic or set of topics."

re: docstrings, here's the "would this work with multiple arities?" post i've been remembering lately
https://www.reddit.com/r/Clojure/comments/3nko85/having_trouble_with_pubsub_with_coreasync_channels/

https://clojure.github.io/core.async/#clojure.core.async/pub

https://github.com/search?utf8=%E2%9C%93&q=core.async+pub+extension%3Aclj+extension%3Acljs&type=Code&ref=advsearch&l=&l=

ok it looks like i'm *kinda* on my own here re: prior art
here goes

ok i split things up a bit and made an events ns
next up: have move-system send a dummy event to render-system

ok, that worked pretty well. now let's get move-system only send the event when an entity has actually moved

ok wow i went into a fugue for a bit and all the code is all fucked up now but i think systems are now maps
and that their tick function gets called with a list of only the relevant entities
TODO that sure sounds worth writing tests for

anyway tomorrow i should look at all this code with fresh eyes and look for things that seem insane
and refactor them and simplify them
but right now the box is moving around like it's supposed to and i have no idea what i did and i'm going to
eat something soon, so i'm going to take a break

also TODO afterward (ONCE ALL THE CODE DOESN'T LOOK INSANE ANY MORE): actually automatically wire up event handlers

also eventually i should make the character tinier like in RoR, i like that style, too big atm

=======

2/26/16

ok so here's where i'm at
it is not super clear how systems should talk to each other
google has no obvious single best accepted solution

my favorites so far:
* ephemeral, "pending-foo" components - so when the collision system detects that two things have collided
  (and either kills the projectile or cancels the pending movement event), it adds a "pendingdamage" component
  to the relevant entities, and the damage system looks for those and handles them and removes them when they've
  been processed
  * pros:
    * easy to remain purely functional in this world ++
    * every system runs once per tick, they communicate with one another via ephemeral components that are
      processed / removed each tick, everything's just a function, everything's synchronous and relatively easy
      to reason about
  * cons:
    * extremely tight coupling. collision system has to know that damage system exists and emit a "pendingdamage"
      component. that seems super dumb. or it emits a "pendingcontact" component, but if several different systems
      read from those, only *one* of them can be responsible for removing them when they've been handled,
      and so all of a sudden like ordering of functions in the tick matters and everything is super tightly
      coupled together and life is awful

so probably not that one. the other alternative i have so far is

* event system - so when the collision system's sole responsibility is to _listen for_ entities that are
  attempting to move, and then either apply the movement or reject it and notify the rest of the world
  that a contact event happened, and the rest of the world can like render differently / play a noise / apply
  damage / whatever
  * pros:
    * loose coupling holy grail basically
  cons:
    * when, say, the damage component's :contact event handler gets run and it decides that entity 4 should
      have its :health decremented by 25 or whatever, it is not immediately clear *how* that change should take
      place. all the event handler has is an event - it doesn't (shouldn't!) have access to the game-state atom,
      because that'd be global mutable state.
    * everything is asynchronous now, and so i worry that this will open me up to more difficult-to-reason-about
      performance problems / general bugs

so my current plan is to go with the event-based system, and just deal with the fact that i'll have some
sort of global-ish mutable-ish state [i'll have it hidden behind an interface of functions, like
(update-entity! entity-id update-in [:foo] bar baz) or whatever].

and so the way that event handlers will update the game is by sending an event like

{:event-type :update-entity
 :entity-id 1234
 :fn (fn [entity] updated-entity)}

and there'll be a single go-block consumer whose job it is to handle these events (maybe just :update-entity,
but maybe other events like :pause-game or whatever too, not sure yet we'll get there later) and update the state
of the world to reflect decisions that have been made in systems' event handlers. and so event handlers
will take args [the-event publish-chan], and that's how they'll be able to emit messages like this.

i think this system will work. i'll need to do some thinking/designing in order to come up with a good
API for changing the state of the world, and will want to come up with a way of hiding the actual mutable
`state` atom from the rest of the program (likely via a closure of some sort), but i think i can make this work.
i don't think the ephemeral-component approach is a good one, i think this event one will work though.

cool so i did a tiny amount of refactoring and now i think i'm ready to dive into pixi
opened all those tabs from above back up again

http://www.goodboydigital.com/pixi-js-tutorial-getting-started/ "launch last month" april 2013 (?!)
"Stage represents the root of our display tree."
" A renderer draws a stage and all its contents to the screen"

ok i'm almost out of battery and need to take a break
but the next thing i need to work on is getting super familiar with pixi and like adding
something to the stage and moving it around and drawing it

i'll need to read through all these goddang tabs to get super familiar with how pixi works
and eventually i'll want to make a pretty api that sits on top of it

ok, so what's the specific problem i'm having with rendering engine reloadability?
i guess i mainly don't want my renderer and stage js objects to be blown away when the rendering ns is reloaded
what other state will we have?
likely a map from entity-id -> sprite (or some such object)
everything else can be blown away

so i guess we have two options
we put a :rendering-engine k/v pair on the GameState map
or we have a private rendering-engine atom that's kept inside the rendering system's ns

the latter seems like the less testable approach to me, which is often a smell
but i'm also not in love with having a :rendering-engine k/v pair on GameState, because that makes this
mutable data essentially global

yeah i think having a private rendering-engine atom in the rendering system's NS is fine
if we want to we can always with-redefs it in tests

ok, gotta learn more about pixi's API
does everything need to be a Sprite?
what's a Graphics?

http://sam-koblenski.blogspot.com/2015/08/a-barely-adequate-guide-to-javascript.html

objects appear to have a .clear() function

ok christ finally
******** https://github.com/kittykatattack/learningPixi appears to be the way to learn pixi
"I know for a fact that it's the best book, because I wrote it!" ugh
"If you aren't running a webserver, Pixi won't work" concerning
lots of bullshit about how you need to "install" pixi, urgh, false/misleading

apparently http://www.goodboydigital.com/pixi-js-v2-fastest-2d-webgl-renderer/ explains the "resolution"
option you can pass when creating a renderer

https://github.com/kittykatattack/learningPixi#pixi-sprites for when i eventually want to add sprites/images
how to render boxes, though?
do i need a Graphics for that?

https://github.com/bhauman/flappy-bird-demo/blob/master/src/flappy_bird_demo/core.cljs
is a good example for how to make your animationframe function take+handle timestamp delta

https://github.com/kittykatattack/learningPixi#positioning-sprites positioning

https://github.com/kittykatattack/learningPixi#velocity can set sprite velocity rather than x and y

*****
https://github.com/kittykatattack/learningPixi#pixis-graphic-primitives here we go fuckin finally

https://github.com/kittykatattack/learningPixi#the-hittestrectangle-function notes on collision detection

notes from a fellow cljs pixi dev in
https://github.com/alexkehayias/chocolatier/blob/dev/todo.org#optimizations-2014-11-29-sat
**** lots of perf notes/goals there ************
note the "This did not end up working" bit re: .- props

"Make the input system emit an event
Currently it updates it’s component state but that’s it. SHould send an event to avoid
other components querying it directly "

super interesting notes here

https://github.com/alexkehayias/chocolatier/blob/5bc509f32f12411848c995f1e11ef917e87d6cbb/src/cljs/chocolatier/engine/ecs.cljs#L133

"The component function can return 1 result or 2. If 1 result then the
    output is treated as the component state. If it is 2 then the second
    argument is events that should be emitted. If format-fn is specified
    then you can implement whatever handling of results you want."

hrm not in love with all that

a note from his event system:
;; Avoid sending messages based recieving a message to prevent
;; circular messages happening

********
https://github.com/alexkehayias/chocolatier/blob/5bc509f32f12411848c995f1e11ef917e87d6cbb/src/cljs/chocolatier/engine/pixi.cljs
his interface around pixi

https://github.com/alexkehayias/chocolatier/blob/dev/src/cljs/chocolatier/engine/systems/render.cljs
his render system

http://www.wagjo.com/benchmark-cljs/ cljs perf - 2+ years out of date though!

"Partial is very slow. Also do note that creating anonymous function costs something.
Try not to create anonymous functions inside performance sensitive loops, as they are recreated
in each iteration."
*** good to know, need to keep an eye on this if(when!) perf becomes an issue

"Assoc in map or record is slow. Much faster is to have a custom type and copy it on every assoc.
 Update in map or record is slow. Much faster is to have a custom type and copy it on every update."
hrm. hrm hrm hrm.

http://www.yeahbutisitflash.com/?p=5666 talks about viewports
iii think we can sort of ignore it for now. come back to it when we implement the camera system
(which will follow the player i guess, i haven't thought about this at all yet)

http://www.yeahbutisitflash.com/?p=6496 sort of talks about level generation
ok it talks about performance too
GPUs and stuff, sprite sheets

talks about object pooling, which i'd like to avoid since we're in cljs but it's good to keep in mind for perf
if it becomes necessary

interesting re: "borrow"/"return" terminology
that's actually an interesting idea/technique

https://en.wikipedia.org/wiki/Object_pool_pattern
"When it is necessary to work with a large number of objects that are particularly **expensive to instantiate**
and each object is only needed for a short period of time, the performance of an entire application may be
adversely affected. An object pool design pattern may be deemed desirable in cases such as these."
none of our stuff is that expensive to instantiate
"Some publications do not recommend using object pooling with certain languages, such as Java,
especially for objects that only use memory and hold no external resources."

http://www.yeahbutisitflash.com/?p=7046 talks about maps
these articles are actually really surprisingly well put together
gj, this person

ok, that's probably enough for now.
next up:
do a pass on voke.core, split out user input logic
figure out how to communicate to the game that the player has pressed or unpressed a movement key

after that.. dunno! read about collision detection algorithms, add walls?

======

2/27/16

so is input.cljs a *system*? or is it just a file?
what characterizes a system? it's either something that runs every tick, or something that listens to and
optionally publishes messages that affect the state of the game, or both.

the input system won't run every tick, but it *will* publish messages that affect the state of the game,
so let's go ahead and make it a system.

ah - but the events it *listens* to *aren't* game events!
so i don't think it's a System after all.

it's a ns that is given access to voke.system.core's `publish-chan`

ok cool input is moved out of voke.core and totally works afaict
and we have a system set up that supports :update-entity events

i had one interesting bug where my events were looking like :type :update-entity instead of
:event-type :update-entity, and so my events were being dropped on the ground and i couldn't figure out why.
was irritating to debug; i know to look for it now, but still.
i can't easily find a way to subscribe to *all* topics on a publication, which would aid debugging. asking in slack.

actually nvm, listening for `nil` as described in https://yobriefca.se/blog/2014/06/04/publish-and-subscribe-with-core-dot-asyncs-pub-and-sub/
would have helped debug this, so i'll try that next time.

ok, time to read about collision systems

https://www.toptal.com/game/video-game-physics-part-i-an-introduction-to-rigid-body-dynamics
"A rigid body naturally rotates around its center of mass, and the position of a rigid body is
considered to be the position of its center of mass."

boy there is a lot of physics in this article

********************
http://www.toptal.com/game/video-game-physics-part-ii-collision-detection-for-solid-objects
"In the context of rigid body simulations, a collision happens when the shapes of two rigid bodies are
intersecting, or when the distance between these shapes falls below a small tolerance."
"If we have n bodies in our simulation, the computational complexity of detecting collisions with
pairwise tests is O(n2), a number that makes computer scientists cringe."
"In order to optimize the collision detection process, we generally split it in two phases:
broad phase and narrow phase."

all this stuff here is about 3d simulations i think
for the broad phase he talks about "space partitioning"

"There are plenty of space partitioning algorithms and data structures that can be used for this,
such as uniform grids, quadtrees in 2D, octrees in 3D, and spatial hashing."

great summary on sort and sweep here, looks like a really interesting+simple heuristic/approach

mentions that box2d implements all this stuff, so maybe i'll end up using that library after all

"concave shapes are harder to work with" - why, though?

"In a convex shape, a line segment between any two points within the shape always falls completelyx
 inside the shape. However for a concave (or “non-convex”) shape, the same is not true for all possible
 line segments connecting points in the shape. If you can find at least one line segment that falls
 outside of the shape at all, then the shape is concave." oh that makes sense

convex hull, convex decomposition
support functions

i'm really impressed by this article

https://gamedev.stackexchange.com/questions/26501/how-does-a-collision-engine-work
" In discrete methods, objects will end up penetrating each other, and the physics
engine then works to push them apart"
talks about "sleeping" objects, and a "contact cache"

***************
http://games.greggman.com/game/programming_m_c__kids/ (from 1993 [!!!!])
"In M.C. Kids the Hamburglar has stolen Ronald’s magic bag and you, as Mick or Mack, must find
the magic bag before Hamburglar does something we’ll all regret."

"Every object can only collide with one other object per frame, so every object is assigned a
collision priority so that it will collide with the most important object. It is more important
to know that the kid hit a monster than to know that the kid hit a PickupBlock."

********
"All objects have a collision matrix, so that they can only collide with certain other objects.
The kid collides with everything. A PickupBlock only collides with the kid and monsters.
Some monsters collide with the kid, other monsters, and various project tiles. Certain other
monsters don’t collide with other monsters. Not having to check every possible collision saves tons of time."

"Collisions: Now for the fun part. NOT!" hee

"Many of the reasons for these contortions have to do with speed. Most video game systems must
run at 60 frames a second, and if you have to look up 4 or 5 tile positions per collision pixel
per frame you are going to run out of time. All this is something you should consider when
designing a platform game. It is much easier the create a platform game with no slopes, so if
you are short on time, then design your game so that it doesn’t need slopes."

http://games.greggman.com/game/tweening/ tweening/lerping

*****
http://www.hobbygamedev.com/adv/2d-platformer-advanced-collision-detection/
"Once again, as with the tile-based example, we’ll be relying on the age-old trick of waiting until
after overlap occurs in logic, then correcting for the overlap before it has a chance to render incorrectly.
That will be “collision”. (I.e. no predictive/extrapolation calculations!)"

i'm glad this guy says that's legit, because that was my exact plan

**********
"Mathematically and computationally, it’s simple to tell whether two rectangles are overlapping:
two axis-aligned rectangles don’t overlap if and only if the left of either is right of the other’s
right or the top of either is below of the other’s bottom."

well, that's for *axis-aligned* rectangles... which, maybe all of the things in voke will be?
will bullets really be ellipses or will they have rectangular bounding boxes?
probably the latter, right? no reason to do the former IMO
but i've considered like diamond-shaped bullets, and those won't be axis-aligned
so maybe this approach won't work for me. good to know about though, makes sense
although i guess the point re: axis-aligned rectangular bounding boxes is that you could *construct* one
around a diamond relatively easily (how ?), and then use *it* to test for collisions.

quad trees are good

"the simplest way to avoid tunneling – and the method used by most 2D platformers,
including Everyone’s Platformer – is to just enforce safe upper bounds on speed and design
with safe lower bounds on sizes"

makes sense

***** favorite explanation/diagram for bounding box collision
http://devmag.org.za/2009/04/13/basic-collision-detection-in-2d-part-1/

http://gamedevelopment.tutsplus.com/tutorials/quick-tip-use-quadtrees-to-detect-likely-collisions-in-2d-space--gamedev-374
more detail on quadtrees/implementation

https://katyscode.wordpress.com/2013/01/18/2d-platform-games-collision-detection-for-dummies/

the "mask approach" described here is very similar to what i'd had in mind when i was thinking about how i'd
implement collision detection from scratch

basically the main thread through all of these articles is that, yes, detecting everything one pair at a time
is n^2, and so you want to do less work than that. quadtrees and aabbs are a good way of doing a broad pass
at collision detection. see the sort-and-sweep algorithm described in an article above.

so anyway in this game i'll only be doing the broad stuff because i don't care about like actual super fine
grained detection of like whether or not a circle *really just barely* missed a rectangle

https://developer.mozilla.org/en-US/docs/Games/Techniques/2D_collision_detection

https://www.quora.com/How-can-I-self-study-Linear-Algebra tips on linear algebra
i.... don't understand this advice

http://betterexplained.com/articles/linear-algebra-guide/
ok sure let's spend a while working through this
eventually i'll look up js collision detection libraries
but i don't know anything about matrices/vectors and this seems like as good a time as any
to sit down and learn some about 'em

"In math terms, an operation F is linear if scaling inputs scales the output, and adding inputs adds the outputs"
"Our only hope is to multiply by a constant"
"However, we can still combine linear operations to make a new linear operation"
"And how could we run the same input through several operations? Have a row for each operation"

=====

2/28/16

taking a break, reading through various unrelated things for fun

https://www.toptal.com/aws/service-oriented-architecture-aws-lambda

TODO: i have no idea how makefiles work, should learn about how to write/use 'em one of these days

https://facebook.github.io/immutable-js/ neat
"the case for immutability" section a bit incoherent

http://tech.noredink.com/post/107617838018/switching-from-immutablejs-to-seamless-immutable

god, lots of reading today. forgot to paste a lot of the links i was looking at.

https://scott.mn/2014/01/20/reference_types_separate_identities_and_values/
atoms for beginners / nonclojurists

http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome

https://www.youtube.com/watch?v=MDZpSIngwm4
"single atom app state is good"

http://www.gamasutra.com/view/feature/3429/crashing_into_the_new_year_.php

******** GOOD ARTICLE ON COLLISION DETECTION
http://www.gamasutra.com/view/feature/3426/when_two_hearts_collide_.php
"The bounding box of the two objects clearly are colliding. It’s also just as clear that the objects
themselves are not. This is why being a human is great and being a game programmer is difficult."
"the game developer’s philosophy: "Do as much work up front as possible, especially if it saves run time.""

******** NOTE
"We assume that collision has not occurred and update the object’s position. If we find that a collision
has occurred, we move the object back and do not allow it to pass the boundary (or destroy it or take
some other preventative measure). However, this assumption is too simplistic because we don’t know if
the object’s previous position is still available. You’ll have to devise a scheme for what to do in this
case (otherwise, you’ll probably experience a crash or you’ll be stuck)"

on tunneling:
"An easy approach is to create a convex hull around an object’s location at two different times.
This approach is very inefficient and will definitely slow down your game. Instead of constructing
a convex hull, we could construct a bounding box around the solid."

"we can divide our world into objects that are stationary (collidees) and objects that move (colliders)
even with a v=0. For example, a rigid wall in a room is a collidee and a tennis ball thrown at the wall
is a collider. We can build two spatial trees (one for each group) out of these objects, and then check
which objects really have a chance of colliding. We can even restrict our environment further so that
some colliders won’t collide with each other — we don’t have to compute collisions between two bullets,
for example."

"In practice, these methods have manifested as octrees and axis-aligned bounding boxes (AABBs)"
"There are several ways to precompute OBBs, and they all involve a lot of math"

anyway current status is that i'm planning on just using dumb AABBs for collision detection
(if i even implement it myself! i'm mainly learning about all this stuff for fun, but expect to actually
end up just using some js library for this)

ok back to http://betterexplained.com/articles/linear-algebra-guide/
learning about matrices
[Operation Matrix] [Input Matrix]
[operation count x operation size] [input size x input count]
[m x n] [p x q] = [m x q]
[2 x 3] [3 x 2] = [2 x 2]
"Notice the matrices touch at the “size of operation” and “size of input” (n = p). They should match!
If our inputs have 3 components, our operations should expect 3 items. In fact, we can only multiply
matrices when n = p."

hm anyway i understand matrices *slightly* more but wouldn't say i have a firm handle on linear algebra.
would be worth doing the khan academy unit on it sometime
ok, anyway that's enough of that, let's go look for js collision detection libraries

hm i might have to implement something myself
something simple using SAT / AABBs

https://github.com/jriecken/sat-js relatively unused but perhaps a good learning aid

https://github.com/wellcaffeinated/PhysicsJS (unmaintained)

https://github.com/liabru/matter-js

https://github.com/liabru/matter-js/blob/master/src/collision/Detector.js super well commented

overall approach appears to be this series of passes:
1. quadtree or some other space partitioning method (broad test)
2. bounding-box tests (mid)
3. SAT test (narrow)

https://github.com/liabru/matter-js/blob/master/src/collision/SAT.js sat implementation

https://github.com/liabru/matter-js/blob/master/src/geometry/Bounds.js AABBs

https://github.com/kripken/box2d.js/ if i really want it (i don't)

actually you know what the blurb on https://www.ibm.com/developerworks/library/wa-build2dphysicsengine/
looks pretty good

"Sometimes, the complexity and overhead of a third-party physics library, such as Box2D, is overkill
for your JavaScript game"

that sure sounds like it's the case for me

here are the things i expect to build

collision detection
velocity/acceleration

here are the things i do *not* plan on including in the game

gravity
elastic collisions (eg bouncing off of things realistically) - you'll just come to a stop, not bounce off
  TODO: how will you come to a stop? immediately set velocity to 0 when you collide with a monster/wall?
    feels like there must be lots of edge cases there - what if monster runs straight at you? are you stuck to it?

all of the shapes in this game will be concave
there'll be rectangles, diamonds (obviously just rotated rectangles), spheres, ellipses
and that's it

ok i'll start on this tomorrow. will start by just doing something like

whenever an entity attempts to move:
for each other entity in the game that has a collision component: <----- TODO OPTIMIZE LATER VIA QUADTREES
compare AABBs to see if a collision happened
TODO eventually implement SAT for wavy obstacles / angled rectangles / etc

if moved entity collided with something, cancel its movement and fire a :contact message
if it didn't collide with anything, apply the movement (how? :update-event message?) and fire a :movement message

========

2/29/16

https://github.com/asciinema/asciinema-player uses phantom+doo, worth looking at when it comes time for tests

https://github.com/asciinema/asciinema-player/blob/master/src/cljs/asciinema_player/core.cljs#L31
good example of taking a ton of kwargs+defaults

he has two primary player implementations, "recorded" and "stream", and throughout core.cljs he has various
multimethods that have different implementations based on whether the player map they're operating on
is :recorded or :stream, interesting. this is basically how i'd expect people to use multimethods, but i haven't
seen them used often in the wild, people usually seem to favor protocols+records instead and i've
never been all that sure why (best guess: performance, better encapsulation?).

https://github.com/asciinema/asciinema-player/blob/master/src/cljs/asciinema_player/util.cljs#L6
is interesting, never seen/used js->clj before

tried it out, works like this:
(js->clj #js {:foo :bar} :keywordize-keys true)
{:foo :bar}

hella terminal command codes and shit in
https://github.com/asciinema/asciinema-player/blob/master/src/cljs/asciinema_player/vt.cljs

in https://github.com/asciinema/asciinema-player/commit/ab5aad1edde90f4a86e3ada80f8866e0b42d21d7
he solves a memory leak / cpu problem having to do with core.async
i have no idea how i'd go about doing that - the cpu i could diagnose via the profile tool, but memory?

http://ku1ik.com/2015/10/12/sweet-core-async.html

ok, i'm running into some issues when implementing the collision system

so basically, right now the plan was to have the movement system fire :intended-movement events whenever
a human- or ai-controlled entity wants to move somewhere, and the collision system listens for those events
and applies the new movement if the spot's clear, or rejects it and fires a :contact event if the spot's not clear.

and so in order for this to work, the collision systems needs to have access to the list of entities in the game
i suppose you could have the system keep a shadow list that basically mimics the master game state's list,
but that seems retarded.

and so the thing is that right now, there isn't a way for event handlers to get access to the state of the game.
they just get the event and a publish-chan.
well, can we pass it along in the event? i wonder

ok yeah i guess we really could

so here's what has to happen

the movement system's :reads field will be empty to indicate that it operates on the entire set of entities

the movement system then filters down so that it only operates on dudes with :intended-directions or whatever

and on each of those, it fires an :intended-movement event with fields :moved-entity, :all-entities

ok, that worked, collision detection is in.
so what next?

1) currently, the way collision detection works, you can't ever touch a wall - you can just get close to it,
    and then try to move closer to it and get denied, and so there's always a few pixels' gap.
    i suppose acceleration/deceleration would fix this, so on second thought let's just wait for that to go in.
2) if you touch a wall on your right, and try to move up+right, you stay still, you don't move up.

2) seems worth working on. what's the best way of fixing it?

we could emit N intended-movement events for player-controlled entities, one per held-down movement button.
that doesn't seem so bad, because only 1 entity would emit that many intended movement events, and you're
talking about a maximum of like 4.

maybe this should wait until after acceleration goes in, though, come to think of it, because that'll likely
change the whole movement situation pretty drastically.

ok so i guess there are two main next interesting things to work on

1) acceleration/velocities/etc
2) firing bullets

the second is obviously more immediately fun, so i'll probably start with that.

right first though i want to make x/y positions be the center of the shape

what needs to be modified for that to happen?

rendering system
collision system
level initialization

movement/input don't care though

ok cool that was straightforward enough

so, bullets.

what's the system called? bullet? projectile? attack?

sidenote: garrick recommends http://www.metanetsoftware.com/technique/tutorialA.html re collision detection
not gonna read it yet, thinking about bullets first

kiger recommends http://www-cs-students.stanford.edu/~amitp/gameprog.html , same deal

ok so right

yeah, attack system, why not; it's clear enough from the name that it's distinct from the damage system

sidenote: what sets AI-controlled entities' intended move directions / fire directions?
system.ai?

ok anyway nvm i started work on projectiles and then realized that none of it will make any sense
until i've implemented proper velocity/acceleration vector-based movement
so we gotta do that first

i'll probably think about it overnight and do it tomorrow

so how would a system like this work?
i've considered adding a new system that's separate from the movement system, but don't see the point
so i guess the movement system's responsibilities expand to look like this:

1) for each entity that *wants* to move somewhere (human-controlled, ai-controlled)
2) update its acceleration to reflect that

then,

1) for each entity with an acceleration,
2) update its velocity to reflect that

then,

1) for each entity that has a velocity,
2) update its position to reflect that

velocity is a vector with a direction in radians and a magnitude in pixels/tick
acceleratio is a vector with a direction in radians and a magnitude in pixels/tick

fwiw,
current set of games i'm mainly thinking about as inspirations
isaac, diablo, risk of rain, teleglitch

=====

3/1/16

http://buildnewgames.com/gamephysics/
makin' a case for vectors
"Vectors are like arrows–they have a length and they have a direction. They do not have
an absolute position in space. The vector [5,3] points north-east, but it doesn’t have a “starting point”."

"If you model points A and B as vectors, then you can get the line segment AB simply by
doing the vector subtraction B-A."

"Using vectors also helps you do intuitive things like adding and subtracting vectors–and keep in
mind that you can model points as vectors, so any math you can do to vectors you can do to points
as well, including rotation around any other point."

garrick's haskell SAT: http://pastebin.com/UG01CB6H

back to the gamephysics article, note his "velocity verlet" integration method

holy shit dude his bouncing+gravity ball example is really short

i... don't really want to do his full 2d example though
spring forces?

"This implementation of the separating axis theorem test is certainly not definitive, however, and you
should craft your own to fit your use-case. This example does not quit early if there’s a test axis with
no overlap; quitting early is a great performance optimization. " **** TODO WHEN SAT HAPPENS

" Also think about the difference between using quadtrees and using a simple fixed grid. Choose whichever
better fits your application; will your objects be evenly distributed throughout the game world, or
will they be clumped together?"

this is a super good point - in isaac a fixed grid would be fine, but i think in voke we'll have bigger maps
with lots of clumping (cleared parts, parts where player is actively fighting monsters / shooting / etc)
and so we'll need quadtrees

http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-1/ looks promising

TODO should my game world be expressed in terms of meters, and only translated to pixels at render time?
seems like a reasonable idea

ok http://blog.wolfire.com/2009/07/linear-algebra-for-game-developers-part-2/ looks pretty good
does a good job of explaining normalization, dot product

http://blog.wolfire.com/2010/07/Linear-algebra-for-game-developers-part-3
"What if instead of rotating each point in the model, we just rotate the model's x and y axes instead?"

"if we are rotating by 49 degrees, then we get the new x-axis by rotating (1,0) by 49 degrees and we
get the y-axis by rotating (0,1) by 49 degrees. Our new x-axis is (0.66, 0.75),
and our new y-axis is (-0.75, 0.66)."

basis vector explanation
"multiplying a 2x2 matrix with a 2D vector is the same thing as changing its basis vectors"

http://www.randygaul.net/2012/02/22/basic-2d-vector-physics-acceleration-orientation-and-friction/
is a bit more what i had in mind i think

https://gamedev.stackexchange.com/questions/14850/how-to-calculate-falling-and-accelerating-velocity

http://www.metanetsoftware.com/technique/tutorialA.html#appendixA gives good definitions of normal, dotproduct

======

3/2/16

still reading through http://www.randygaul.net/2012/02/22/basic-2d-vector-physics-acceleration-orientation-and-friction/

"Once you have this set up, you can easily use this radians orientation value to find a direction vector for your
object. A direction vector is a vector whose length is 1, which allows you as a programmer to multiply it by a
value and easily get a vector in a specific direction of a specific length.
In order to get your normalized direction vector from your angle of orientation, just use:
dirVect.x = cos( radianOrientation );
dirVect.y = sin( radianOrientation );"

yeah this article is way hackier than the other ones listed above but like doesn't require me to spend an extra
week thinking about linear algebra so i might just cheat and go with this approach :/

"Now, what if you need to solve for the angle between two points? This could be useful for homing missiles, or
AI. Knowing the angle between an enemy and the player, for instance, could be used to let the enemy know
which direction to go from there. In order to solve for the angle between two points I used atan2:
angle = atan2( player.y - enemy.y, player.x - enemy.x )
This lets me find the angle between two points, namely between an enemy object and the player. You can then
use this result and compare it with the angle of orientation of the enemy in order to deduce of the enemy
should turn clockwise or counterclockwise, or anything else you'd want!"

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Math/atan2 js atan

the comments talk about variable vs fixed timestep

ok so what now?
entities can have a Shape, with an x/y and an orientation
orientation is from negative pi to positive pi

they can also have a Motion, with a velocity that's a dx and a dy, and a top speed
you can get the entity's current speed by doing sqrt of dx^2 + dy^2

on each tick,
for each entity with a Motion,
update orientation
  (for player, it's the angle defined by the currently-held-down movement keys)
  (for monsters, it's atan2 or something, it's the angle that directly leads them to the player)
  (for projectiles, it's the angle they were created with)
calculate acceleration
  (if player is moving, acceleration is just like always 0.1 or something, or 10% of top speed or whatever)
  (same with monsters)
find direction vector
  dirVect.x = cos( radianOrientation );
  dirVect.y = sin( radianOrientation );
update velocity, capped at top-speed
  vel.x += acceleration * dirVect.x;
  vel.y += acceleration * dirVect.y;
update position
  pos.x += vel.x
  pos.y += vel.y

so Motion is really just a Velocity? nah it's got a top-speed too, so let's keep calling it Motion
give it an acceleration too

unit circle is from -pi to 0 to pi (is this insane or good?)

ok so if we do that, then down is -pi/2, right is 0, up is pi/2, left is -pi (or pi?)

what if you add each key's sins/coses together? is that retarded

ok i hacked around and acceleration/velocity sort of exists

there are a bunch of things left to do

1) don't keep recalculating 0.9* velocity forever and ever as it approaches 0 infinitely
  just like have it be the case that if your velocity falls below 0.01 or something, your velocity is set to 0
  and if you've got 0 velocity and 0 acceleration, skip velocity-updating calculations
2) update collision system so that if you try to bump into something, your velocity's cut in half or something
3) projectiles shouldn't experience friction

wow it really does feel surprisingly good right now though, and i haven't even tweaked any values yet

ok rough acceleration/velocity are in

still need to tweak values, and really in particular need to figure out a better way of dealing with collisions
with walls. how to calculate the closest non-wall spot to put the entity in?

well, i guess you know that entity 1 collided with entity 2..
but you don't currently know what *side* they collided on

oh wow zeke really wasn't kidding, corners are totally fucked up

so yeah the main next thing i need to work on is walls, then i can do bullets after

ok i think i figured it out but the code i added is, like, voluminous
refactor it tomorrow!!!!!!!!!

=====

3/3/16

ok, spent some time refactoring that code, and fixed a bug dmitriy found that made you move down if
you held left+right (nice).

walls feel good now.

dmitriy reported some aliasing
zeke reported some shuddering [either RAF was falling behind due to his cpu doing other stuff, or events aren't
keeping up to realtime], should keep an eye out for that.

cos/sin/atan2 perf seems fine according to benchmarks, 10k atan2 invocations -> 3ms, and we won't be
doing anywhere near that many.

had some ideas re: projectiles this morning, jotting 'em down:

collision system doesn't know/care about projectiles, just emits :contact events
grim-reaper system listens for :contact events (and eventually :damage ones, but that's a diff story), and
  if both entities are projectiles,
    drops the event on the floor
  if one entity is a projectile, and the other is not its :owner,
    removes the projectile
damage system listens for :contact events and behaves similarly

i'm worried about race conditions for applying damage - what if the grim-reaper system doesn't get around
to deleting the projectile in time, and 2+ damage ticks are emitted for the same projectile?
entities need some way of tracking damage so that damage application is idempotent.

either a :damage-sources field that's a list of EntityIDs, or a :time-last-damaged, or *something*.

anyway for now i guess i can start working on emitting projectiles and having a grim-reaper system reap 'em

damage can come (much) later

ok, today ended up being focused mainly on refactoring; i'll deal with projectiles next time.


ask julio for austin for cljs game stuff

met austin, see http://pettomato.tumblr.com/ , https://twitter.com/AustinTHaas

=====

3/4/16

concepts in http://pettomato.tumblr.com/image/66011458408 i haven't given any thought to:

wall time vs sim time
z-index

=====

3/6/16

need to replace the core.async-based event system with a synchronous one
determinism

====

3/7/16

ok so in my 2/26/16 notes, i talk about how it's not super clear how systems should talk to each other,
and how i ended up deciding to go with an event-based system because that gives you the loosest coupling
possible.

so i implemented one, based on core.async's pub/sub features. but since then i've been really nervous about it,
because the fact that it's built on core.async means that it's asynchronous, and so i'm worried about eg
living in a world where an :intended-movement event fired on frame 5 doesn't end up getting processed
until frame 8, etc etc.

i've been reading through "game programming patterns", which is pretty good, and realized that the solution
to this problem is super simple - if i want an event-based system here, it should be a simple *synchronous* one
that i build myself. it'll have some simple state, just a map like {:event-name [list-of-callback-functions]}.

so when i get around to it, i'll change the event system to be implemented in that way, and i will be able
to sleep way better.

ok, now i'm puzzling about projectiles. how will they work?

they don't have a :brain - they *do* have a shape, a motion, and an owner

they inherit their owner's velocity (dx and dy)
added to that is a single dx or dy number based on :intended-fire-direction

EVENTUALLY there will be a range stat that controls how far projectiles go

entities also have an associated :last-fire-timestamp. does that live on some preexisting component?
can several related components be combined together into one?

ok so entities can have a :weapon, which contains information that controls the creation of projectiles

ok, gonna take a break from implementing projectiles for a bit.

systems that still need to be massively updated to account for projectiles:

* movement
  * don't only move player-based entities
  * don't only move entities with acceleration
  * don't apply friction to projectiles
* collision
  * TODO figure out what should be updated here
* grim-reaper
  * TODO add this system at all

one thing i've been struggling with is the notion of entity "types".

several times now, i've found myself wanting to add a :type key to a component (collision, movement, brain, etc)
to indicate that a particular entity is a :monster, or a :player, or an :obstacle, or a :projectile.

an example: certain entities are projectiles, and thye shouldn't be subject to friction,
and they can't collide with other projectiles

maybe a better way of doing things would be to add an :affected-by-friction s/Bool k/v pair to :motion
and a :doesnt-collide-with #{:foo} k/v pair to :collision

that's a more direct way of expressing what i'm trying to express, i think i like it

ok taking a break for today.

tomorrow:
look into collision system
start grim-reaper system if it seems sane
refactor all this new projectile-related code

later this week:
sit down and really tighten up schema definitions, particularly around events
make events system synchronous

====

3/8/16

transcribing notes taken down on paper this morning, continuing thoughts on "type" fields in component schemas:

be wary of :type fields in component schemas. they're alluring because of course i know that a :projectile
should behave like X and Y, but that's _implicit_. the _explicit_ approach is better. see below:

:collision components should look like

{:type (s/enum :good-guy :bad-guy :projectile :obstacle :trap :projectile :gold :item :explosion)
 (s/optional-key :collides-with) #{CollisionType}
 (s/optional-key :destroyed-on-contact) s/Bool}

type :type field here is just used as a marker - it doesn't have any implicit behavior tied up in it.
the collision system doesn't have code in it that goes "ok if one of these entities is a projectile,
it should behave like thus and so". instead, the other two fields control special behavior.

the :collides-with k/v pair is optional.
if unspecified, it means that the given entity collides with everything.
if specified, it's a set that's a _whitelist_ of the things that the entity will collide with.
only entities that can move should have this field. it feels weird to specify that constraint, but it keeps
the system easier to reason about.

good guys collide with everything except projectiles owned by good guys
bad guys don't collide with gold and projectiles owned by bad guys

if i wanted to implement ghosts, i could just have them not collide with obstacles

for entities like projectiles, items, and gold, there's an optional :destroyed-on-contact k/v pair.
if this is true, when the collision system goes to fire a :contact event involving one of these entities,

the collision system is responsible for removing entities with :destroyed-on-contact true;
the grim reaper system is responsible for removing damaged/killed good/bad guys

when projectiles are created by good guys, they have a :collides-with that's like {:bad-guy :obstacle :item}
when they're created by bad guys, they get {:good-guy :obstacle :item}

projectiles will also have an :owner-id field (not on :collision, just a standalone component)
this is mainly for stuff like lifesteal, etc; collision system doesn't know/care about it

ok, now projectiles don't collide with their owner, and they're removed from the game+screen when they collide
with obstacles.

next up:
* projectiles should be fired in the direction specified by :intended-fire-direction
* projectiles should inherit their owner's dx/dy
* refactor all this

i'm seeing some perf slowdown when 30 projectiles are on the screen at once.
profiling indicates that all of our time is spent in handle-intended-movement.
i'd like to start by replacing the event system with a synchronous one, then seeing how perf goes
if perf is still bad, profile handle-intended-movement

some weird shit happens when a projectile hits a wall, we get a million duplicate :intended-movement events

ok, i think i see what's going on here.

because the event system is currently asynchronous, we're ending up in a situation where system.core removes
an entity, then system.collision/apply-movement assoces a :shape and a :motion onto the now-nil entity,
and so we end up with badly formed entities.

ugh so anyway make it synchronous tomorrow

lol all right i started on that and realized that i have no idea how any of this ever worked

events are synchronous now, but the updates they make are clobbered every frame by the swap! call in voke.core
will need to do some thinking about the best way of architecting this system.

how do systems communicate with one another? -> events seems to be the clear answer

how do events cause updates to the state of the game?
answer to this is less clear.

should there be a queue that takes in side-effecting events like :update-entity and :remove-entity,
and at the end of every frame the queue is flushed?
is this a good idea or a dumb idea?

i guess at that point there's not really much of a reason to use the event system - or is there?
the rendering system listens to :remove-entity events, after all

but yeah even so, maybe there should be some sort of (update-entity! entity-id a-fn) function that
the core game engine exposes, and a (remove-entity! entity-id) function too, and they're buffered
behind the scenes and don't use the event system at all to actually do their work
but somewhere along the line an :entity-removed event is fired so that the renderer system knows what's up.

so the voke.event system ends up being specifically for inter-system communication and non-game-state-related
side effects, and the core update-entity! and remove-entity! functions are for actually updating the state of
the game.

that could work. gonna sleep on it.

======

3/9/16

re: "i have no idea how any of this ever worked"

here's what's happening now, re: clobbering:
cljs.user=> (def foo (atom {}))
#'cljs.user/foo
cljs.user=> (swap! foo (fn [thing]
             (swap! foo assoc :blat :blot)
             (assoc thing 1 2)))
cljs.user=> @foo
{1 2}

and so of course the current event system's update-entity situation is getting clobbered, because it's all
happening inside of a swap!.

the way that things used to work was that the requestAnimationFrame loop swap!'d the main atom once per frame,
and as part of that swap! it'd fire a bunch of update-entity events. and *those events* would be consumed
by go-blocks and trigger swap!s that happened *outside* of the rAF swap!. and so that's how things actually worked.

anyway i still like the update-entity! and remove-entity! ideas from the end of yesterday's notes,
will probably put 'em in voke.state or something.

ok, cool, that totally worked the first time. nice.

running into an issue with the rendering system having trouble removing bullets. the behavior looks like this:
1) on frame N, the collision system detects that a bullet (entity with id E) has hit a wall
2) the collision system calls remove-entity! to queue entity E's removal from the game-state atom's :entities list
3) the collision system fires an :entity-removed event
4) the rendering system's :entity-removed handler fires, removes entity E from the stage and the objects-by-entity-id atom
5) the rendering system's tick function runs. it's given a list of the game-state map's entities.
  *this list contains entity E*, because the game-state atom hasn't yet been updated with the queued removal from step 2*
6) the rendering system detects an entity that isn't currently being drawn, and draws it on the screen.

an idea i've been toying with is pulling the rendering system's tick function out of the System infrastructure
and calling it directly right before the end of every rAF tick. i think i'm going to try this.

ok, that seems to have improved things.
except now, entities that collide with the left or right wall don't get removed, but ones that collide with the
top or bottom one are removed just fine. what gives?

fixed it by changing the place where :entity-removed events are emitted.

perf is okay, but suffers when there are ~30-40 projectiles on the screen at once.
i tried putting entities-can-collide behind a cache, but it's still called so many times per second that even the overhead
of looking in the cache n^2 times per tick is too expensive to keep up to realtime.
implementing quadtrees should likely fix this.

=====

3/10/16

notes from paper, mainly about priorities / next things to work on:

[DONE] 1) document/refactor attack branch
[DONE] 2) everything should have a :position and a :shape; split :x and :y out of :shape and put 'em in :position
   main use case for this right now is so that weapons can have a :projectile-shape that's a Shape
3) add a debug view, use reagent
   mainly thinking about having a slider and arrows, both of which let you revisit previous frames of history
   i guess you'll need to hit pause first or something? so there'll be a pause/play button
   use sliding window of history if memory usage becomes an issue
   the rendering system will have to handle disappearing/reappearing entities (so maybe the :entity-removed event
   goes away, and there's just an :entity-killed event that eg the loot/xp/etc systems listen to)
4) figure out what to do about this bullet collision rendering issue - right now, it looks to the player like
   bullets disappear before actually touching obstacles. this must be a common issue in games
   ideas:
   * if a bullet's moving fast and crosses 6 pixels of empty space in 1 frame before touching a wall/enemy, reposition
     it so that it's right next to its point of contact for 1 frame? don't like this idea.
   * spawn some sort of "ghost" bullet (decal?) at the bullet's contact site right after it dies, have it
     live for 1-2 frames (maybe this idea has potential)
[DONE] 5) get source maps to actually work so that i can debug this perf issue more easily
6) go through codebase and resolve any obvious TODOs worth immediately resolving
7) camera

okay, #1 and #2 are done

what do i want to do next?

#5 i guess?

ok, that was a fucking disaster, i burned 2 hours tweaking project.clj settings and in the end all i had
to do was restart chrome. oh well. source maps work now.

profiling indicates that when a ton of projectiles are on the screen, we spend:
77% of our time in move-system-tick
71% of our time in handle-intended-movement
65% of our time in find-contacting-entity
45% of our time in entities-can-collide
***4.5%**** of our time in shapes-collide (actually *checking* for collisions!!!!)

really gettin' familiar with the chrome profiling tools. good stuff. no obvious conclusions yet though

i wonder if it would be helpful to serialize the game's state during peak slowdown (where we're taking ~40ms/frame)
and then load it up and just run move-system-tick on it once and see what happens

AHA! i was making an instance of this "one-way-collision-check" function every single time two entities
were being checked for collidability! no wonder that was slow! we got back a *ton* of fps by fixing this.

ok, now one-way-collidability-check takes 25% of our time
6.66% in get-in
4.23% in not-eq

lol ok i managed to make collision detection faster but fuck up a bunch of stuff in the process

walls aren't colliding in the right places (likely due to this afternoon's :position shenanigans)
and also if the player touches a wall, the game crashes
i'm pretty fried, i'll deal with it next time

===

3/11/16

goals for today:

[DONE] 0) revert last commit from yesterday

[DONE] 1) rewrite core collision checking logic in vanilla JS, call out to it from cljs
  granger does this vanilla-js interop in https://github.com/ibdknox/ChromaShift
  https://github.com/liabru/matter-js/tree/master/src/collision has well-annotated js collision detection code

2) remove :intended-movement message, have movement system call out to collision system directly
  give colliison system an attempt-movement function that movement system can use, makes coupling explicit

http://www.bestinclass.dk/blog/brians-brain-optimized-clojurescript-html5 good perf writeup

ok actually before steps 1 or 2, i'm going to get rid of this separate :position field and put it back
in :shape, in :center like wtimoney does in https://github.com/wrmsr/voke/commit/27e3ab88b1bdc617c7643d64d96c5826c9d9d8b1

cool that was pretty easy, hopefully i didn't miss anything

on to step 1

ibdknox makes it looks pretty easy. he writes a vanilla js file, game.js:
https://github.com/ibdknox/ChromaShift/blob/master/js/game.js

which basically just defines a namespace and some functions (it looks like he's doing some sort of mapping
of entities to components and vice versa), and makes them available on window.Game.

and so to access these plain js functions from cljs, in
https://github.com/ibdknox/ChromaShift/blob/master/cljs/game/lib/core.cljs
he just accesses js/Game.a-fn-name

so let's try that.

making some progress on this approach. hilariously, the major bottleneck is converting clj datastructures
to js objects.

right now, on a profile where we spend 3161ms in process-frame,
we spend 2120ms converting entities to js objects
we spend 51ms actually checking for collisions

so if i can optimize the conversion codepath, we should be groovy.

ok continuing to work on optimizing conversions, but i'm seeing all sorts of weird perf behavior
(and btw there are some bugs in the vanilla js collision code, collisions don't seem to be happening at all)

so we spend 80% of our time in entities->js-objs

oh right uh maybe the reason that things get worse over time is that COLLISION DETECTION ISN'T WORKING
SO NO BULLETS EVER GET REMOVED
DUH

ok, like four hours later, that's enough for today

tomorrow let's circle back and clean up / document the state of the collision system

TODOs:
* kill :intended-movement message in favor of attempt-to-move function
* figure out how to get vanilla Collision js file to work with closure compiler :advanced mode

we can handle about 140 moving entities on the screen before we stop dropping the occasional frame, for posterity

just did some benchmarks
100 update-ins on :player cost about 1ms
100 get-ins on :player cost about 1ms
good to know

=====

3/12/16

notes / things i want to do next:

[DONE] 1) remove :intended-movement event in favor of attempt-to-move function
2) stop doing separate :x and :y movements, just do one combined movement and have the collision system
   sort things out.
     most of the time, you're not colliding, so moving in 2 steps all the time makes our average-case
     scenario slower.
     have the collision system attempt to apply the combined x/y movement - then if you collide with something,
     you definitely fire a contact event
     and after that, first try to move in the x direction, then in the y direction
     if both are blocked, that's fine. but make sure you fire *one* contact event total
     (can you call cljs functions from js? hopefully we don't need to get to that point)
[mostly done] 3) read prettified compiled js to see where all the overhead is in our cljs code, then keep profiling
   until as much overhead as possible goes away and most of the work is being done in js-land
4) look into quadtrees. right now we have ~140 moving entities before the system begins to slow down, and we're
   doing n^2 work. nlogn work is much much much more attractive. will need to have the quadtree live in js-land
   obviously

ok, #1 was easy enough.
right now, 13% of our time is lost inline in move-system-tick, and 8% is lost inline in attempt-to-move

hm maybe that 'self' stuff the timeline view was reporting was garbage?
the profiling view doesn't corroborate it

will stick with profiling view from now on, i think. timeline view is pretty, but kept fighting me.
we're cpu-bound here and not doing a ton of GCs or paints or whatever, so profiling view is plenty fine.

at this point, the majority of the cljs overhead i've been able to find has been optimized away.
these are the things that are keeping us slow:

1) moving in 2 steps, first x then y (see #2 above)
2) doing n^2 comparisons when doing collision checks (see #4 above)

so let's tackle them in that order.

ok i started on #1 but the collision system is currently all fucked up as a result

gonna need to do some thinking about the best way to express the collision system doing this:
* try moving the entity to its desired new x/y position
  * if that works
    * great
  * if that doesn't work
    * fire a contact event
    * try moving it to its desired new x position
      * if that works
        * great
      * if that doesn't work
        * find the closest clear x position and move it there
    * try moving it to its desired new y position
      * if that works
        * great
      * if that doesn't work
        * find the closest clear y position and move it there


we can deal with quadtrees in a few days, the collision system cljs is likely to get a bit hairy over the
next few hours of work and so i'll be wanting to do a good amount of refactoring on it
because i am about to fuck it up like crazy

the above bullet points are proving to be harder than i expected to expressin code.
wrote some awful shit, stashed it, gonna try again tomorrow from scratch.

you know what, this is proving to be more trouble than it's worth. shelving it for now.
let's do quadtrees next instead.

=====

3/14/16

ok, so does the quadtree live in js or cljs?
i'm betting js.

--- time passes ---

ok i went on a walk and did some more thinking about the 2-calls-vs-1-call movement->collisions system thing
i had some trouble working on it yesterday, both because i was pretty hungover but also because i kept
worrying that there was some case where we try to resolve a collision and just literally can't.
but i don't think that such a case exists. as long as we update the collision system every time
a) an entity is created
b) an entity is moved
c) an entity is deleted,
and we do validation at a)-time and b)-time, the collision system will never be in an invalid state.

there are a few other things i'm worried about. for instance, what if an entity's moving to the right,
and it collides with *two* entities in a single frame, and we try to resolve its collision by moving it
to the unoccupied spot to the left of the entity it collided with, but we pick the *rightmost* of the two
entities instead of the *leftmost*?
the solution is for the js collision system to return a list of all the entities collided with,
and for the resolution system (?) to do its homework and figure out which enttiy's relevant.

resolution system... i kinda like the sound of that. what would that look like?

ok, cool, i spent today following that thread and i think it turned out pretty well.
the collision system is easier to read+understand, and everything seems to be working, and i've tightened
up a bunch of loose perf spots.
lots of stuff in cljs is slow. get-in is slow. update-in is slow. assoc-in is slow. merge is slow.
calling functions is slow.

hopefully these things will improve over time? in the meantime, just gotta work around 'em.
i wonder if austin's run into any of these perf problems i've been facing?

anyway, tomorrow it's finally time for quadtrees, because today i got the 2-call->1-call thing to happen.

or maybe i'll look into a few other things first :)

* records (schema has support for 'em) - benchmark them against maps
  * interested in get-in, update-in, assoc-in performance
  * curious to read the generated js
  * http://alexkehayias.tumblr.com/post/78711349238/entity-component-model-in-clojurescript sketch re: ecs
* https://funcool.github.io/clojurescript-unraveled/#transients - would `into` be a good fit for some of our
  hot spots? assoc-ins, merges, etc?
* figure out what externs are, get collision.js hooked up / able to be advanced-compiled
  really interested to see if the cljs overhead i'm seeing persists through advanced compilation
  if not, it could render the above two bullet points unnecessary

"The intent is that, unless interop forces one to go beyond their circumscribed scope, one need not leave
Clojure to get the highest-performing data structures possible on the platform."
- http://clojure.org/reference/datatypes

hm - worth looking into this to see if collision.js could actually just be fine if we used records

would be interesting to benchmark/profile a cljs+defrecord vs vanilla-js version of collision.js

notes from benchmarking a simple entity map-vs-record implementation in cljs-sandbox:
(update-in player-map [:shape :center :x] (fn [x] (inc x))), 10000000 runs, 22819 msecs
(update-in player-record [:shape :center :x] (fn [x] (inc x))), 10000000 runs, 17327 msecs
(assoc-in player-map [:shape :center :x] 6), 10000000 runs, 19845 msecs
(assoc-in player-record [:shape :center :x] 6), 10000000 runs, 14406 msecs
(get-in player-map [:shape :center :x]), 10000000 runs, 11781 msecs
(get-in player-record [:shape :center :x]), 10000000 runs, 8446 msecs

so on the whole, operations on records appear to run in about 70-80% of the time that they take on maps.
which is certainly a speed boost, but isn't the like 10x increase i was hoping for.

tried again with advanced optimizations

(assoc-in player-map [:shape :center :x] 6), 10000000 runs, 16450 msecs
(assoc-in player-record [:shape :center :x] 6), 10000000 runs, 7049 msecs
(update-in player-map [:shape :center :x] (fn [x] inc x)), 10000000 runs, 7421 msecs
(update-in player-record [:shape :center :x] (fn [x] inc x)), 10000000 runs, 8872 msecs
(get-in player-map [:shape :center :x]), 10000000 runs, 4713 msecs
(get-in player-record [:shape :center :x]), 10000000 runs, 4284 msecs

so assoc-in appears to be super cheap for records in advanced mode for... some reason. and otherwise it appears to
mostly be a wash.

current mystery - https://www.evernote.com/shard/s11/sh/39854162-88a7-4fd6-88e5-b01f25183ef7/b63355ace4a9966e
cannot figure out what is going on here.
gonna read through the relevant cljs source and generated js i guess
might have to ask in slack
...oh christ if i expand it i see it's just flush!
whooops.

====

3/15/16

on a hunch tried this
(-> player-map :shape :center :x), 10000000 runs, 2215 msecs
(->> player-record :shape :center :x), 10000000 runs, 1502 msecs
(get-in player-map [:shape :center :x]), 10000000 runs, 2674 msecs
(get-in player-record [:shape :center :x]), 10000000 runs, 2316 msecs

so two things to try first off today:

1) try threading macros instead of get-in
2) dig into flush, see if it's easily optimizable
      seems like a perfect situation to use a transient, right? or into or something?

and then also i want to look into setting up externs for collision.js, so we can see how all this performs
(and profiles) in advanced mode

http://clojure.org/reference/transients

"You run into a similar scenario, at a higher level, when you want to initialize or transform a
large persistent data structure using multiple steps, none of which will be seen by any code other
than the constructing/transforming code. The challenge here is that the source of a transformation
will be an existing persistent data structure, and the result of the function _will_ be shared."

create a transient with (transient my-thing)
creation is o(1)
(peristent! the-transient) is o(1)
calling transient! on an entity won't make its nested maps transient, though!

well, applying transients to flush! didn't help all that much - at best, we shaved off 2% of the program's runtime

threading macros don't seem to have bought us all that much either, update-position remains at 4% of our runtime
no matter what i try

so, let's try externs next, and then finally quadtrees after that

more notes tho

(assoc player-map :renderable true), 10000000 runs, 991 msecs
(assoc player-record :renderable true), 10000000 runs, 1975 msecs
(-> player-map :shape :center (assoc :x 5)), 10000000 runs, 5620 msecs
(assoc (-> player-record :shape :center) :x 5), 10000000 runs, 2476 msecs
;
(assoc player-map :renderable true), 10000000 runs, 908 msecs
(assoc player-record :renderable true), 10000000 runs, 1480 msecs
(-> player-map :shape :center (assoc :x 5)), 10000000 runs, 2187 msecs
(assoc (-> player-record :shape :center) :x 5), 10000000 runs, 1355 msecs
;
(assoc player-map :renderable true), 10000000 runs, 773 msecs
(assoc player-record :renderable true), 10000000 runs, 1366 msecs
(-> player-map :shape :center (assoc :x 5)), 10000000 runs, 2152 msecs
(assoc (-> player-record :shape :center) :x 5), 10000000 runs, 1419 msecs
;
(assoc player-map :renderable true), 10000000 runs, 809 msecs
(assoc player-record :renderable true), 10000000 runs, 1455 msecs
(-> player-map :shape :center (assoc :x 5)), 10000000 runs, 2049 msecs
(assoc (-> player-record :shape :center) :x 5), 10000000 runs, 1450 msecs

bare assocs seem to be slower on records than on maps
but assoc-ins are faster on records than on maps
ugh whatever

ok, i got externs working, nice
that wasn't so bad
lost most of a day to this dumb issue where i had a file with the ns voke.system.collision.utils
but the file was util.cljs instead of util.cljs
because ugh

anyway that's working now
so i'm profiling the advanced-mode js
i don't completely understand it, it looks like there's two distinct-but-same codepaths that start in the move
system and bottom out in the vanilla js Collision

anyway uh it looks like quadtrees are definitely the right next step. cool. will start researching
what the hell those are

https://www.youtube.com/watch?v=TJzq_kjtGTc well this sure looks promising

hm, dmitriy suggests typed arrays
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Typed_arrays
eh, i'll look into 'em later

or spatial hashing? https://www.youtube.com/watch?v=gkKc3upnZU8

https://gamedev.stackexchange.com/questions/69776/when-is-a-quadtree-preferable-over-spatial-hashing hm

"All of which isn't to imply that a tree structure is always the right choice, of course. Flat grids
are ideal for the situation you have in your example -- dense clouds of objects pretty much evenly
spread everywhere in the world, and we're doing simple, inexpensive collision tests. Absolutely a grid
is likely to be the optimal approach in that case!"

http://zufallsgenerator.github.io/2014/01/26/visually-comparing-algorithms/

ok spatial hashing is sounding pretty good man

https://stackoverflow.com/questions/4981866/quadtree-for-2d-collision-detection

" if you look at the benchmarks in the last section you will see that of all the libraries surveyed,
quadtrees tended to perform quite poorly compared to other collision detection methods like R-Trees,
grids or segment trees."

http://gamedevelopment.tutsplus.com/tutorials/quick-tip-use-quadtrees-to-detect-likely-collisions-in-2d-space--gamedev-374
"Any object that cannot fully fit inside a node’s boundary will be placed in the parent node."
that answers the main question i've had about quadtrees

"At every frame, you’ll insert all objects into the quadtree by first clearing the quadtree then
using the insert method for every object."
hm - that's the other question i've had. seems odd but maybe it's fast?

http://0fps.net/2015/01/07/collision-detection-part-1/

http://0fps.net/2015/01/18/collision-detection-part-2/ cautions against grids when:
"High aspect ratio: If the ratio of the largest to smallest side of the boxes in the grid is too extreme,
then grids will always fail catastrophically. There is no easy fix or known strategy to avoid this
failure mode other than to not use a grid."

hm - what's "too extreme" mean here?

"when grids work they are effectively optimal.  The trouble is that when they fail, it is catastrophic."
eeeeee

********* THIS ARTICLE IS FUCKING GOLD
http://0fps.net/2015/01/23/collision-detection-part-3-benchmarks/
he says he highly recommends https://github.com/mourner/rbush , puts it in bold and italics

he says box2d is super slow

"For large, uniform distributions of boxes, grids are still the best.  For everything else, use segment trees."

https://www.reddit.com/r/gamedev/comments/3jrtpc/quadtree_vs_spacial_hashing_which_to_use/
has lots of people shitting on quadtrees

*** FYI
https://www.reddit.com/r/gamedev/comments/4adlsk/16gb_of_high_quality_sound_effects_the_sonniss/
has tons of free sound effects / audio
for later

ok anyway so he said https://github.com/mourner/rbush is good, let's look at it

consider looking into https://github.com/schteppe/p2.js if i end up doing non-box things

======

3/16/16

ok rbush was easy to use and now checking collisions takes 1% of our time
ezpz

that was a lot easier than i expected
thanks, 0fps guy!

https://stackoverflow.com/questions/5319282/game-engines-what-are-scene-graphs what even is a scene graph tho

ok, current bottlenecks appear to be
1) render system gets slow over time
2) timeline view indicates that doing many rbush.remove() calls triggers a major GC
TODO - look into some form of rbush-related object pooling

anyway i'll look into these a *little* - and also i want to read more about what rbush is and how it works -
but after that let's do something more interesting. like, i dunno, monsters?

https://github.com/pixijs/pixi.js/issues/351 mentions pixi.debug.js

http://www.html5gamedevs.com/topic/3208-pixi-performance-tile-maps-canvas-and-rendertexture/

http://www.html5gamedevs.com/topic/1315-performance-improvement-suggestions/
" I think an object culling pass should be added to skip off-screen sprites rendering."

"Off screen culling is userland responsibility. You should be culling items in your engine, that is not
something we will be adding into Pixi any time soon. The tools to make an item not be rendered are there
(visible = false) you just need to use them. Creating a tilemap where you spawn every tile and show them all
(even the ones off screen) is ineffective.
Try looking at some of the tilemap engines built on pixi to see how you can easily do a smooth scrolling
engine that only ever creates the number of tiles shown on the screen."

https://github.com/pixijs/pixi.js/issues/48

https://github.com/pixijs/pixi.js/issues/356

"less Graphics objects means less buffer switching and more batching, so better performance."

hm... how can we have fewer graphics objects?

https://stackoverflow.com/questions/33437002/pixi-js-animate-circle-improving-performance

ok cool that worked great, rendering system is no longer a perf bottleneck

so at this point we're not dropping any frames at all

so i'll just do add-entity! and then we'll be ready to start on monsters

actually i'm kinda torn between starting on monsters and starting on bigger levels / camera
i think monsters'll be more fun though

MONSTER NOTES / ORDER OF OPERATIONS:
[DONE] first just make static ones
[DONE] then make ones that fire
then draw them in red or something
and draw their projectiles in some redlike color too
then make ones that move toward you
then make ones that fire toward you
then implement health and damage
then implement invincibility+melee damage
then implement death

ok, i made a good amount of progress but now i have to go home

outstanding TODOs / things to work on next

[DONE] 1) clean up the code
2) hilariously, i can never move the player character into the stream of bad guy bullets.
   look into what's happening and fix it (bad guy bullets should be removed, contact events fired)

=======

3/17/16

https://adambard.com/blog/clojure-reducers-for-mortals/ indicates that core.reducers buys you significant
performance increases in clj. should benchmark them to see if they work similarly in cljs.

https://bendyworks.com/transducers-clojures-next-big-idea/

apparently reducers were neat but now it's all about transducers?
what?

http://kukuruku.co/hub/funcprog/clojure-transducers-reducers-and-other-stuff

scratchpad:
player is entity 0
bullet is entity 1
another bullet is entity 2

player moves in such a way that it intersects bullets 1 and 2

* resolve-collision is called with entity 0, contacted-entities 1 and 2
    * entities 1 and 2 are queued for removal, entity 0 is allowed to make the move it wanted to
* resolve-collision is called with entity 1, contacted-entities 0
    * entity 1 is queued for removal
* resolve-collision is called with entity 2, contacted-entities 0
    * entity 2 is queued for removal

a few options on how to proceed
* voke.state's remove-entity! pipeline can squash duplicates
    * i don't like this, seems like it's hiding smelly code
* collision system can use a function that sits on top of remove-entity! and fires a -stop-tracking-entity
    * i think i like this approach

hm, approach 2 seems to fuck us actually
by the time that resolve-collision is called on entities 1 and 2, they've been removed from the collision system
and so it's like "what"
should removal be made somehow eager? *can* it be? i don't think so

what situations are we worried about here

in the same tick:
player runs into bullet, takes damage, destroys bullet
bullet runs into player, causes damage, destroys bullet

etc

how to avoid/solve?

right so we just defer updating the vanilla-js collision system's state until the update-entity event
is actually *processed*, rather than when it's queued, that makes more sense / makes things more consistent

but so what if the player and the bullet are moving toward each other, and intersect in the same frame?
you still end up with a situation where entity 0 has moved into entity 1's space, and entity 1 has moved
into entity 0's space

so you're *definitely* going to wind up with duplicate contact events - one for [0 1], another for [1 0]
and they're processed synchronously, with no queueing, so you can't easily dedupe

i guess the collision system could keep an atom that's reset every frame
and the atom has a set of sets like {0 1}
and so if you notice a collision between entities 0 and 1 and you resolve it, you record it
hm but like what goes in the set / how is it checked

maybe you just have an atom that's a set of dead entities
and if you get an attempt-to-move! call for an entity that's already been killed this frame, you just
drop it on the ground

that solves the problem for projectiles, but
what about if a player and a monster both try to move into each other?
the player's nudged so it's right next to the monster, and a contact is fired
the monster's nudged so it's right next to the player, and a contact is fired

the end goal is that the player is only damaged once
whose responsibility is it to dedupe this?

does the collision system keep two atoms, each of which is reset every frame,
and one of them is a set of dead entity IDs,
and the other is a set of pairs of IDs that have had collision events fire?

======

3/18/16

i ended up doing all that stuff above re: collision system

hung out with the pdx clojure guys last night, they said transducers definitely sound relevant to the perf/
overhead issues i've seen. boy i have a lot of reading to do

also at some point i should look into http://gafferongames.com/game-physics/fix-your-timestep/ again

also need to look into having a moving camera - i think we can just adjust the root Graphics node's
x and y, might be pretty easy to get working

======

3/21/16

i have done nothing for the past 48 hours aside from playing the division.
i'll get back to work tomorrow.

=====

3/22/16

spent most of day doing adult stuff, taxes etc.

here's where voke is currently at

1) i need to read / process / decide http://gafferongames.com/game-physics/fix-your-timestep/
2) i want to look into transducers to see if they can help eliminate some of the cljs-land overhead
i've been seeing in profiles.
3) continue work on monsters as per notes from a few days back; spin up a voke/system/ai/ folder with movement,
attack, etc namespaces, as well as a system namespace

assorted notes from hanging out with the clojure guys the other day:
https://www.conj.io/
https://github.com/rm-hull/monet
"if you're using a lot of functions inside maps, that's a sign that you might want multimethods"
"if you're doing a lot of type checks, that's a sign that you might want protocols"

http://gafferongames.com/game-physics/integration-basics/
"An excellent option for greater accuracy and less memory when simulating a large number of particles
is verlet integration. In this case, the integrator does not require storing velocity per-particle, as
it derives it from the difference in the previous two frames position values. This makes collision
detection and position fix-up (eg. pushing particles out of collision) really quick and easy to implement."
sounds super interesting

=======

3/23/16

http://gafferongames.com/game-physics/fix-your-timestep/

ok i'm having a hard time processing this writing/code style for some reason
so in "semi-fixed timestep" he's got an approach where
every frame, you check to see how long it's been since the beginning of the last frame, call that X
let's say X is .1 seconds
if so, you process N ticks of your game's logic, where N is .1 / (1/60), which is basically 6
and then you render
let's say X is 0.001 seconds somehow
if so, you process 1 tick of your game's logic

"we’re now taking multiple steps per-display update including one additional step to consume any
the remainder of frame time not divisible by dt. This is no problem if you are render bound, but
if your simulation is the most expensive part of your frame you could run into problems including
the so called “spiral of death”."

"You really need to ensure that it takes significantly less than X seconds of real time to update X
seconds worth of physics simulation. If you can do this then your physics engine can “catch up” from
any temporary spike by simulating more frames. Alternatively you can clamp at a maximum # of steps
per-frame and the simulation will appear to slow down under heavy load. Arguably this is better than
spiraling to death, assuming of course that the heavy load is just a temporary spike."
hm

"The renderer produces time and the simulation consumes it in discrete dt sized chunks." hm
new code chunk
at the start of each frame, you check to see how long it's been since the beginning of the last frame, call that X
you keep an "accumulator" value that basically stores the.. remainder of any.. trailing frame time.
bad wording on previous line but this stuff is unusual for me
basically it seems like this is the exact same as the above code chunk, except it addresses the
"including one additional step to consume any the remainder of frame time not divisible by dt"
bit from the first chunk

"we only ever integrate with steps sized dt so it follows that in the common case we have some unsimulated
time left over at the end of each frame. This is important! This left over time is passed on to the next
frame via the accumulator variable and is not thrown away."

code snippet from game programming patterns
http://gameprogrammingpatterns.com/game-loop.html#play-catch-up

"Note that the time step here isn’t the visible frame rate anymore. MS_PER_UPDATE is just the granularity
we use to update the game. The shorter this step is, the more processing time it takes to catch up to real
time. The longer it is, the choppier the gameplay is. Ideally, you want it pretty short, often faster than
60 FPS, so that the game simulates with high fidelity on fast machines."

"The end result is the game simulates at a constant rate using safe fixed time steps across a range of hardware.
It’s just that the player’s visible window into the game gets choppier on a slower machine."

i'm really impressed by the clarity of this author's writing. this is much more comprehensible than the
fix your timestep article

i'm not super sure about this whole "render(lag / MS_PER_UPDATE);" thing, though - probably won't do that
i don't like the idea of having to teach the rendering system about velocities + positions
i dunno, maybe it would help address the issue where bullets "appear" to be vanishing a little bit before
they get to walls, because physics + collision detection happens before rendering

ok so at the end of the day, do i want to do this?
i guess i can cut a branch and give it a shot
maybe it won't even be that bad tbh
so we can try seeing what would happen if we ran the simulation at like 100fps and just render at 60fps
will we be able to get the performance necessary for that, though? already difficult enough hitting
60fps, and we're definitely not render-bound...
i dunno, man

======

3/24/16

http://www.html5gamedevs.com/topic/5509-how-do-you-guys-write-your-timestep-stuff-any-advice/
"setTimeout is good if you need your loop to continue running when the window is blurred", hm

"You need to make your calculations based on the delta, even if requestAnimationFrame will most
likely be ~60fps, because not ALL devices are 60fps. And in the future, when all devices are 120hz,
people might still be playing your game! "

okokok i'll need to do this good timestep business, fine

http://codeincomplete.com/posts/2013/12/4/javascript_game_foundations_the_game_loop/

"One additional note is that requestAnimationFrame might pause if our browser loses focus, resulting in
a very, very large dt after it resumes. We can workaround this by limiting the delta to one second"

nice

i'll limit it to 1 frame i think, rather than 1 second, to avoid tunneling / etc

"The basic idea is to accumulate our dt until it is greater than our desired fixed timestep, call
update with the fixed timestep, and carry over the remainder to accumulate for the next time."

http://codepen.io/anthdeldev/pen/QwGpxM

http://www.isaacsukin.com/news/2015/01/detailed-explanation-javascript-game-loops-and-timing
***** this is a very good article

========

3/28/16

ok cool back in the saddle

so right now i'm trying to get the core game logic to tick at 100fps, and leave the rendering system at 60fps
and i'm running into this situation where the rendering system is being told to move entities that it doesn't
yet know about

i guess the right thing to do here is for the rendering system to discard movement events if it isn't already
tracking the entity, because it'll pick the entity up at the next rendering tick

okok that was easy enough to fix.

now i'm digging into some weirdness re: getting the attack system to generate evenly-spaced bullets.
i'm running into issues because
* the attack system uses (now) to figure out how much time has passed, so it can check to see
  if the given entity is ready to fire again
* (now) currently uses js/performance.now, which tracks *wall* time, not sim time
* multiple sim ticks can happen in rapid succession

so i guess we need to have a clock that tracks sim time. might as well add it to util i guess
nah let's do voke.clock

ok made some progress with time

ran into an issue where the monster's weapon was behing like this:
it would shoot a lot of bullets quickly with little spacing between them for a while
then it would shoot them with more spacing between them for a while
then it would revert back, etc

it was supposed to fire 20 times a second

each tick, the amount of time that had passed since the last time the weapon had fired looked like this sometimes:

16.66666666666424
33.33333333332848
49.999999999992724

and other times it looked like this:

16.66666666666788
33.33333333333576
50.00000000000364

and so basically sometimes the weapon would fire every 4 ticks, and sometimes it would fire every 3 ticks
because of something something floating point math

=======

3/29/16

ok whatever transducers
https://www.youtube.com/watch?v=6mTbuzafcII

https://youtu.be/6mTbuzafcII?t=27m26s mentions speed

there's no actual (mapping f)
just (map f) returns a transducer

http://blog.cognitect.com/blog/2014/8/6/transducers-are-coming

pretty good code snippets on that post

http://kukuruku.co/hub/funcprog/clojure-transducers-reducers-and-other-stuff

(def cc (vec (range 10000000)))
(time (reduce + 0 (->> cc (filter odd?) (map inc))))
"Elapsed time: 697.390000 msecs"
(time (transduce (comp (filter odd?) (map inc))
                 +
                 cc))
"Elapsed time: 358.080000 msecs"

https://gist.github.com/ptaoussanis/e537bd8ffdc943bbbce7
**** lots of discussion on this one

http://stackoverflow.com/questions/26317325/can-someone-explain-clojure-transducers-to-me-in-simple-terms

ok so the transducer is the process, like
(comp
  (map inc)
  (filter even?))
that's a transducer right there apparently.
whereas (map inc) is.. a reducing function? or is it also a transducer
hm i think inc is actually the reducing function
(map inc) is a transducer

a poster on that SO thread suggested that transducers may be more valuable for folks like rich / david / etc
than they are for plebs like me, abstraction-wise
but still might be able to use them for perf

http://clojure.org/reference/transducers

To apply a transducer to an input collection and construct a new output collection, use into
(which efficiently uses reduce and transients if possible):
(into [] xf (range 1000))

ok, anyway let's see if we can get any perf out of all this business

profile indicates that we spend 7.2% of our time in process-update-events

lol i ended up with this just completely batshit insane reimplementation

  (if (seq update-events)
    (assoc state
           :entities
           (transduce (fn [step]
                        (fn
                          ([result] (step result))
                          ([result event]
                           (step result
                                 [(event :entity-id)
                                  ((event :fn) (get result (event :entity-id)))]))))

                      (fn ([acc] acc)
                        ([acc [k v]]
                         (assoc acc k v)))

                      (state :entities)

                      update-events))
    state)

which is completely retarded - i'm sure i'm doing this wrong - and affects perf not at all, not even a little

anyway i don't think transducers are even relevant to this particular situation. all i want to do is
take a map of {thing-id: thing}
and a list of events that look like {:thing-id an-id :fn a-function}
and apply those events to the original map
and i think that the preexisting implementation in voke.state already does as good a job of this
as we're likely to get

http://ignaciothayer.com/post/Transducers-Are-Fundamental/

transducers seem to basically be useful when you have a list/stream/whatever of inputs, and you want
to do some arbitrary operations on them, and so if you have like ten operations that you want to chain together,
transducers can buy you a lot of performance there.

but in my situation, i tend to have some inputs and i want to apply all of them to a particular single
map, and vanilla reduce seems to be about as good as it's possible to get

ok started work on ai movement
the monster trundles along after the player
but if both of them move into each other, weird shit happens in collision resolution
if player is above and monster is below, and they move toward each other vertically, player's x-position gets
nudged so that it's to the right of the monster

i'll deal with it tomorrow

to make things simpler, have the monster always move up very slowly

====

3/30/16

this situation is a bit difficult to debug / reason about. i wonder if it would be helpful to slow things to
like 5fps and to add a pause button - so if you hit P, time stops. that could be useful

anyway so what's happening?

player is 0, moving down
monster is 5, moving up

A:
system resolves for 0
nothing contacted in x direction
contacted 5 in y direction
0's bottom is moved to be right above 5's top (todo confirm this is working correctly)

B:
system resolves for 5
nothing in x direction
contacted 0 in y direction
5's top is moved to be right below 0's bottom

at this point 0 has y 291.01412121520923
5 has y 315.61896848408577

the difference between those two numbers is 24.60484726887654

so the resolution system puts 0 and y too close together!

...hm i think this is happening because step B isn't aware that step A has happened and 0's position has shifted
0 starts at y=290.608 and is moved to y=291.014
5 starts at 316.024 and is moved to y=315.618

yeah

well, why is B happening?

0 is moving down
5 is moving up

0 attempts to move
A happens
0 is nudged to be in a good spot so it's right above 5
js system's state is updated to reflect this

5 attempts to move
B happens because 0 is *right* above 5
cljs system is using out-of-date center for 0, moves 5 to the wrong spot

one resolution: have cljs system ask for most up-to-date position of 0 before moving 5

ok i did that

still a few lingering problems

sometimes the player teleports in.. certain situations. not sure which. particularly if it's chasing you
and you stop moving (?)
also if you're shooting a bunch of bullets and it collides with you as a bullet's dying, sometimes it crashes?
not sure what's going on in either situation

ok i fixed the second of thsoe two things
haven't started on the first yet

ok, what's happening here
can't really reproduce it reliably
it seems to happen when the monster catches up to you - diagonally - as you're slowing to a stop

resolving for 5 -> no further logging?!

is it the situation where an entity's corner precisely collides with your corner?

yeah i think it might be

we handle a collision for 5
we check each axis to see if 5 is clear to move on that axis
and it *is* clear to move on both axes
but then we move it and bad shit happens

======

3/31/16

ok i did some thinking about this corner collision situation

so the problem is that we're in a situation where you're clear if you *just* move laterally, and clear if you
*just* move vertically, but if you actually apply both axes' movement direction, you collide with something

right now, the resolution system's like "cool you're clear on top and clear on the right so go ahead and
move up and right", and then you're in an invalid place and things get a little fucked up

so i think the right way to solve this is to detect when we're in this situation (pretty easy: when we've
been asked to resolve a collision, but we appear to be clear vertically and horizontally)

and when that happens:

take the list of entities that we know we've collided with
break them down into all of their component lines
  so eg an entity with width 10 height 10 that's at x=20 y=40 would have 4 lines
  x=10, x=30, y=30, y=40

take the line that the moving entity is traveling on - figure out a way to express it, we have its position
and its direction so it should be easy to turn that into a line; call that L or whatever

then, for each of our collided entities' lines, calculate the point at which line L intersects with it
so now we have a set of points
then all you do is figure out which of those points is closest, and - say the entity is moving up+right - you
just move its top-right corner to be at (or slightly slightly before) that point

i think i have a little more hammering out to do, but that sounds like a reasonable way of solving the problem

======

4/4/16

http://www.eff-lang.org/ looks neat, found via an article pwrice sent me

which was https://codewords.recurse.com/issues/six/immutability-is-not-enough , which i thought was good

======

4/5/16

garrick says his game state handling works similarly to voke.state, except with a priority int as well,
to determine the order in which updates are applied. interesting

ok well let's try this line stuff

======

8/30/16

whoops it's been a while

reading through some links from http://www-cs-students.stanford.edu/~amitp/gameprog.html

http://intrinsicalgorithm.com/IAonAI/2012/11/ai-architectures-a-culinary-guide-gdmag-article/ talks about finite
state machines vs behavior trees vs planners

i really like amit's aside on AI systems:

In choosing a technique for AI in your games, keep it as simple as possible; read this. If you know the
answer, put the answer into the program. If you know how to compute the answer, put the algorithm for
computing it into the program. Only if you don’t know the answer, and don’t even know how to compute the
answer, should you resort to complex techniques that can learn how to find the answer. These complex
techniques can come at a high price, in terms of programming time, game performance, difficulty of
debugging, and lack of control.

the "lack of control" bit was non-obvious to me, and is echoed in this "culinary guide" article when he talks
about planners:

"""
From an implementation standpoint, a major plus of the planner is that a new action can be dropped into the game
and the planner architecture will know how to use it. This speeds up development time markedly. All the author says
is, “here are the potential things you could do… go forth and do things.”

Of course, a drawback of this is that authorial control is diminished. In a FSM or BT, creative, “outside the box”
solutions were the exception from the predictable, hand-authored systems. In a planner, the scripted, predictable moments
are the exception; you must specifically override or trick the planning system to say, “no… I really want you to do
this exact thing at this moment.”
"""

according to this taco guy, behavior trees are more common than planners, but FEAR used a planner:
http://alumni.media.mit.edu/~jorkin/goap.html

`While utility-based systems can be used in many types of games, they are more appropriate in situations where there
are a large number of potentially competing actions the AI can take—often with no obvious “right answer.”`

http://alumni.media.mit.edu/~jorkin/gdc2006_orkin_jeff_fear.pdf

`If the audience of GDC was polled to list the most common A.I. techniques applied to games,
undoubtedly the top two answers would be A* and Finite State Machines (FSMs). Nearly
every game that exhibits any A.I. at all uses some form of an FSM to control character
behavior, and A* to plan paths.`

so i will probably be using FSMs and A* when it comes time for monster behavior

i guess monsters can have states like

idle
pursuit
combat
leash

etc

"As much as we like to pat ourselves on the back, and talk about how smart our A.I. are, the
reality is that all A.I. ever do is move around and play animations! Think about it. An A.I. going
for cover is just moving to some position, and then playing a duck or lean animation. An A.I.
attacking just loops a firing animation. Sure there are some implementation details; we
assume the animation system has key frames which may have embedded messages that tell
the audio system to play a footstep sound, or the weapon system to start and stop firing, but as
far as the A.I.’s decision-making is concerned, he is just moving around or playing an
animation."

"The previous case study illustrates the first of three benefits of a planning system. The first
benefit is the ability to decouple goals and actions, to allow different types of characters to
satisfy goals in different ways. The second benefit of a planning system is facilitation of
layering simple behaviors to produce complex observable behavior. The third benefit is
empowering characters with dynamic problem solving abilities."

perhaps overkill for our purposes in voke, but cool to read about

..."This dynamic behavior arises out of re-planning while taking into account knowledge gained
through previous failures. In our previous discussion of decoupling goals and actions, we saw
how knowledge can be centralized in shared working memory. As the A.I. discovers obstacles
that invalidate his plan, such as the blocked door, he can record this knowledge in working
memory, and take it into consideration when re-planning to find alternative solutions to the
KillEnemy goal."

http://aigamedev.com/open/review/planning-in-games/

"In the cases of action/combat games, we can easily build robust AI that looks deliberate using
simple reactive techniques like behavior trees. In fact, it's difficult to tell the difference
for such applications between the behavior generated by a planner compared to more reactive
approaches, yet the planning process will be noticeably slower at runtime and require more development time."

https://archives.nucl.ai/recording/building-a-galaxy-procedural-generation-in-no-mans-sky/
"we're building a game, not a tech demo" - har har

http://aigamedev.com/open/article/hfsm-gist/ heirarchical FSMs

http://aigamedev.com/open/article/bt-overview/ behavior trees

==========

9/3/16

http://gamesfromwithin.com/data-oriented-design

"Programming, by definition, is about transforming data: It’s the act of creating a sequence
of machine instructions describing how to process the input data and create some specific output data"

"In general, the ideal data is in a format that we can use with the least amount of effort"
"In any case, the goal is to minimize the amount of transformations, and whenever possible,
you should bake your data into this ideal format offline, during your asset-building process."

"To achieve the best possible data layout, it’s helpful to break down each object into the
different components, and group components of the same type together in memory, regardless of
what object they came from. This organization results in large blocks of homogeneous data,
which allow us to process the data sequentially"

http://buildnewgames.com/particle-systems/
** good article

object pooling makes a lot of sense in particle systems

"Instead what we need is a pool of particles. When we want to fire a particle out, we will
grab an available one from the pool. When a particle dies, it will be returned to the pool
to be recycled later."

=========

9/4/16

http://norvig.com/lispy.html

http://norvig.com/lispy2.html

http://www.redblobgames.com/pathfinding/a-star/introduction.html
***** great

"Dijkstra’s Algorithm can find paths to all locations; A* finds paths to one location."

super fuckin great article

a* is djikstra + greedy best first search

"If you want to find paths from or to all all locations, use Breadth First Search or Dijkstra’s Algorithm.
  Use Breadth First Search if movement costs are all the same; use Dijkstra’s Algorithm if movement costs vary.

If you want to find paths to one location, use Greedy Best First Search or A*. Prefer A* in most cases."

"A* is guaranteed to find the shortest path if the heuristic is never larger than the true distance.
As the heuristic becomes smaller, A* turns into Dijkstra’s Algorithm.
As the heuristic becomes larger, A* turns into Greedy Best First Search."

"What about performance? The best thing to do is to eliminate unnecessary locations in your graph."
recommends reading http://www.redblobgames.com/pathfinding/grids/algorithms.html if using a grid

"I’ve not needed any of these optimizations in my own projects." interesting
quadtrees are mentioned

http://theory.stanford.edu/~amitp/GameProgramming/Heuristics.html

http://theory.stanford.edu/~amitp/GameProgramming/UserExperience.html

"Making units too smart is almost as bad as making units too dumb. If the player has to deal
with fog of war but the pathfinder has access to the entire map, the units will mysteriously
know where to go even though the user does not. That’s a clear sign to the user that something
odd is going on. On the other hand, it gives better paths. A compromise is to scale up the
movement costs on unexplored areas."

http://theory.stanford.edu/~amitp/GameProgramming/MapRepresentations.html

"The most common alternative to grids is to use a polygonal representation. If the movement cost
across large areas is uniform, and if your units can move in straight lines instead of following
a grid, you may want to use a non-grid representation."

"In many grid games, there are large areas of maps that have uniform movement costs. A* doesn’t
“know” this, and wastes effort exploring them. Creating a simpler graph (navigation mesh,
visibility graph, or hierarchical representation of the grid map) can help A*."

https://web.archive.org/web/20110723003329/http://www.ai-blog.net/archives/000152.html

this guy really likes navigation meshes

=========

9/5/16

http://www.redblobgames.com/pathfinding/grids/graphs.html

"Graph search algorithms like Dijkstra’s Algorithm and A* work on weighted directed graphs,
sets of nodes connected by edges that have numeric weights (movement costs) attached to them."

http://www.redblobgames.com/pathfinding/a-star/implementation.html

just implements a Graph, which is a set of (directed) locations and edges, no Node class

http://aigamedev.com/open/article/bt-overview/

pretty bad article

http://www.gamasutra.com/blogs/ChrisSimpson/20140717/221339/Behavior_trees_for_AI_How_they_work.php

"a behaviour tree is a tree of hierarchical nodes that control the flow of decision making
of an AI entity. At the extents of the tree, the leaves, are the actual commands that control
the AI entity, and forming the branches are various types of utility nodes that control the
AI’s walk down the trees to reach the sequences of commands best suited to the situation."

"A core aspect of Behavior Trees is that unlike a method within your codebase, a particular
node or branch in the tree may take many ticks of the game to complete."

hm
makes sense, interesting tho

so i guess the idea is that a particular node on an entity's behavior tree is active at
any given point in time, and it can have a certain state associated with it -
example states are success, failure, and running

it keeps talking about how nodes can return a value to their parent - eg:

"A composite node is a node that can have one or more children. They will process one or
more of these children [...] and at some stage will consider their processing complete
and pass either success or failure to their parent, often determined by the success or failure
of the child nodes. During the time they are processing children, they will continue to return
Running to the parent."

not sure i 100% follow this

i guess the idea is that one way of using a BT is to:
every tick, walk each npc's BT to see if any states have completed
for each active node: check all of its active children and see their statuses
if a child node is Running, then ignore it / let it continue
if it's marked as Success, then do something about that
if it's marked as Failure, then do something about that

this article is pretty solid; it makes BTs sound way more complicated than i'll ever need
in any game i'm likely to build, though; cool concept, but more useful in complex FPS/RPG games
where you really want to have rich/complex NPC behavior

my dudes are only ever gonna be idle, chasing, attacking, healing, or leashing, and probably
not ever really anything else to speak of

looks like BTs are actually most useful in a context where you've got some sort of GUI
tool that you've built to allow your characters' BTs to be manipulated, and you have some
sort of established library of Node classes, and so you're not actually writing code when
you're manipulating a character's behavior, you're just using this tool and dragging Nodes around

ok fuck it let's try to read the re-frame screed

https://github.com/Day8/re-frame

"we believe in one-way data flow"

"Although app-db is a Reagent atom (hereafter ratom), I'd encourage you to think of it as
an in-memory database. It will contain structured data. You will need to query that data.
You will perform CRUD and other transformations on it. You'll often want to transact on this
database atomically, etc."

ok, the history-lesson portion is all pretty straightforward

talks about `subscription`s, which appear to be a tool that you can use to have your component
functions query app-db (rather than just having them directly do like (:b @app-db) or whatever)

"subscription handlers" - functions that do a named query

"components never source data directly from app-db, and instead, they use a subscription."
"subscriptions are only ever used by components (they are never used in, say, event handlers)."

   (subscribe  [query-id some optional query parameters])

(register-sub) function hooks up query IDs to query functions

so far, it just seems like we've added a layer of indirection between component functions
and the app-db atom; hasn't yet been explained what this buys us

"We don't want to perform this computationally expensive re-sort each time something unrelated in app-db changes."

"Luckily, we can easily fix that up by tweaking our subscription function so that it chains reactions"

********
"That 3rd, expensive reaction will be re-run when either one of its two input Signals change,
right? Not quite. reaction will only re-run the computation when one of the inputs has _changed in value_."
********

this seems to be the main point of the discussion so far - using chained reactions so that
you only do expensive recomputations when you actually *have* to, rather than redoing them
every time the db changes in any way

"An application has many handlers, and collectively they represent the control layer of the application."

events are just data, like [:header-button-clicked :about] or whatever

you fire events with (dispatch)

event handlers take a) the value of @app-db and b) an event (a vector), and return the
new value which should be reset! into @app-db

(reg-event-db) is used to register events

"It is almost like app-db is the temporary place where this imagined perpetual reduce stores its on-going reduction."
cute

i wonder if multiple handlers can subscribe to the same event?

eg he keeps talking about how there's this stream of all events that have happened
how do you actually record that stream? can you make a handler that subscribes to all events
and just conjes them onto a list?

anyway reframe seems good, just like a good base common vocabulary for writing apps using reagent

=======

9/6/16

https://www.youtube.com/watch?v=fU9hR3kiOK0
samza

good talk, bit general but good intro to why streams / idempotence / etc are good in db-land

=======

9/7/16

ok cool

so what was i working on six months ago, anyway?

the last thing i wrote was "let's try this line stuff" - what the hell does that mean?

looks like i was tinkering around in collision.resolution, something to do with corner collisions

i should really start by going through and resolving every TODO i find in the codebase

the "line stuff" seems to refer to my notes from 3/31/16

=====

9/14/16

did some reading on kubernetes for no reason, that was fun

https://youtu.be/9MKY4KypBzg?t=52m22s has a good bit on coordinated omission
"when you see a vertical rise in a percentile chart, you should be extremely suspicious
of the input: your data is probably wrong."

recommends that you test your measurement system. seems like a good idea

always measure max time, can be a hint re: coordinated omission

https://www.usenix.org/system/files/conference/atc14/atc14-paper-ongaro.pdf raft paper

ok anyway i'm trying to set up dirac, a tool for debugging cljs

https://github.com/binaryage/dirac/blob/master/docs/installation.md

ok so things are kinda broken but kinda working

in order to get dirac and figwheel to happen at the same time, i do this:
(per https://github.com/bhauman/lein-figwheel/wiki/Using-the-Figwheel-REPL-within-NRepl )

lein repl
(use 'figwheel-sidecar.repl-api)
(start-figwheel!)

once all that's done, i get dirac and figwheel and things are mostly groovy.

this is obviously somewhat cumbersome though

i still need to solidify my understanding of this whole system, i'm kinda just flailing atm
in particular, i need to set up cursive integration per
https://github.com/binaryage/dirac/blob/master/docs/integration.md

and also need to figure out why my code isn't being run when you load the html page any more
complains about `voke` being undefined, even though `voke.core` has been goog.require'd

ok, connecting cursive to dirac was really easy, not sure exactly what it buys us quite yet

@smw in #dirac says that boot has really simple tooling around auto code reloading
gives this snippet:

(deftask dev-cljs-repl
  "Run a restartable system in the Repl"
  []
  (comp
   (environ :env {:http-port "3300" :dev true})
   (watch :verbose true)
   (system :sys #'dev-system :auto true :files ["handler.clj"])
   (reload :port 55554)
   (cljs-repl)
   (cljs)
   (speak)))

will have to take a look at that in the future

https://github.com/adzerk-oss/boot-reload
https://github.com/adzerk-oss/boot-cljs-repl
https://github.com/boot-clj/boot-cljs-devtools

====

9/15/16

https://github.com/adzerk-oss/boot-test

http://tech.adstage.io/2016/09/12/how-we-test-full-stack-clojure.html

http://clojure.org/guides/spec

so apparently a big part of spec is this concept of a central registry, so you do things like

(s/def ::date inst?)
(s/def ::suit #{:club :diamond :heart :spade})

(s/valid? ::date (Date.))
;;=> true
(s/conform ::suit :club)
;;=> :club

but is it not clumsy to have to do stuff like constantly referring to voke.specs/foo, voke.specs/bar, etc?

because like 99% of the time you're not going to be in the `voke.specs` ns

"You will see later that registered specs can (and should) be used anywhere we compose specs."

"When an or is conformed, it returns a vector with the tag name and conformed value:"
(s/def ::name-or-id (s/or :name string? :id int?))
(s/conform ::name-or-id "abc")
;;=> [:name "abc"]
(s/conform ::name-or-id 100)
;;=> [:id 100]

s/nilable exists:
(s/valid? string? nil)
;;=> false
(s/valid? (s/nilable string?) nil)
;;=> true

interesting - spec guide mentions #: syntax for auto-namespaced map keys, like this:

#:{ :foo {:bar :baz}}

apparently gets translated to eg

{:voke.core/foo {:voke.core/bar :voke.core/baz}}

not sure if it gets applied recursively, so it might just be

{:voke.core/foo {:bar :baz}}

yeah, doesn't get applied recursively:

user=> (= #:foo{:bar {:baz :quux}} {:foo/bar {:foo/baz :quux}})
false
user=> (= #:foo{:bar {:baz :quux}} {:foo/bar {:baz :quux}})
true

documented in https://groups.google.com/forum/#!topic/clojure-dev/8tHLCm8LpyU

interesting discussion on that thread

back to the spec guide, this paragraph is probably super important, on entity maps:

Clojure programs rely heavily on passing around maps of data. A common approach in other
libraries is to describe each entity type, combining both the keys it contains and the structure
of their values. Rather than define attribute (key+value) specifications in the scope of
the entity (the map), specs assign meaning to individual attributes, then collect them into
maps using set semantics (on the keys). This approach allows us to start assigning (and sharing)
semantics at the attribute level across our libraries and applications.

so i guess what they're saying here is that instead of doing this throughout your application:

(def Card {:name str? :mana-cost int?})

you should instead be doing something like (unsure of the syntax here, making up this map-of function)

(def Card (map-of [::name ::mana-cost]))

i guess that makes sense!

ok, apparently the (s/keys) macro is what i was looking for

http://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/keys

(s/def ::person (s/keys :req [::first-name ::last-name ::email]
                        :opt [::phone]))

"The map spec never specifies the value spec for the attributes, only what attributes are required or optional."

"Much existing Clojure code does not use maps with namespaced keys and so keys can also specify
:req-un and :opt-un for required and optional unqualified keys."

"Unqualified keys can also be used to validate record attributes"

i don't really understand what's up with keys* - it talks about how it "can be embedded inside
a sequential regex structure". what's that?

gives as example:

(s/def ::server (s/keys* :req [::id ::host] :opt [::port]))
(s/conform ::server [::id :s1 ::host "example.com" ::port 5555])

hm ok i guess - so keys* is for validating kwargs for functions?

s/merge is for combining entity maps

this focus on use of namespaced registered keywords is interesting - it's basically equivalent to just
doing regular defs, like (def Foo {:bar :baz}), and just passing Foo around, but instead
we're doing (s/def ::foo {:bar :baz}) and referring to ::foo everywhere. wonder what that buys us?

is it mainly for performance reasons (not passing around tons of data, if that even matters),
or is this nice for some other reason?

maybe it's nice because you don't have to actually import voke.specs to refer to ::voke.specs/foo,
as seen below:

user=> :foo.bar/baz
:foo.bar/baz
user=> ::foo
:user/foo
user=> :user/foo
:user/foo
user=> (= :user/foo ::foo)
true

that does seem like a pretty compelling reason; i had trouble avoiding circular-import errors
when using Schema and doing the passing-around-Foo-everywhere style mentioned above. cool neat

ok also yeah uh there is the obvious bit where namespaced keywords are good map keys

right so in schema land, you're usually doing things like {:foo Foo}, and also referring directly
to Foo throughout your code; but in spec-land, ::foo serves both of those purposes (?)

not sure how i feel about multi-spec, wonder if anyone uses it

"The multi-spec approach allows us to create an open system for spec validation, just like
multimethods and protocols. New event types can be added later by just extending the event-type multimethod."

special collection functions:
coll-of, tuple, map-of

"Both coll-of and map-of will conform all of their elements, which may make them unsuitable
for large collections. In that case, consider every or for maps every-kv." hm

on s/cat vs s/tuple:
"The choice between a regular expression and tuple here is to some degree a matter of taste,
possibly informed by whether you expect either the tagged return values or error output to
be better with one or the other."

"Spec also defines one additional regex operator, &, which takes a regex operator and constrains
it with one or more additional predicates."

(s/assert) exists, asserts are off by default but can be toggled on

(s/fdef) is the good shit, lets you spec a function.
interesting that rather than going the route schema did and providing an alternate implementation
of `defn` that has new syntax, they prefer to do this:

(defn foo [etc] bar)

(s/fdef foo :args something :ret bla)

it makes sense - these guys want to keep the language's syntax as simple as possible - it's just interesting

"Because the args are sequential and the args are positional fields, they are almost always
described using a regex op, like cat, alt, or *."

s/fspec for higher order functions

there's a typo on the guide -
"so often it’s not helpful to spec the :ret value of a function (as it’s just code)."
should read
" so often it’s not helpful to spec the :ret value of a macro (as it’s just code)."

might be fun to figure out how to contribute a fix

"The Clojure macroexpander will look for and conform :args specs registered for macros at
macro expansion time (not runtime!)."

that's neat

fdef still feels kinda clumsy to me - eg
:args (s/cat :game ::game)

vs

[game :- Game]

again, i get that they don't want to introduce new syntax, but i hope that there's some sort
of nice sugar so you don't have to always do (s/cat :foo ::foo :bar ::bar)

i wonder if fdef's :fn ever gets used, seems like a nice-to-have that nobody would use in practice

submitting a PR to the spec guide was really easy, https://github.com/clojure/clojure-site/pull/139
gj github, nice simple UI flow for the whole process

"The s/gen function can be used to obtain the generator for any spec."

(s/exercise-fn) looks pretty neat! the example usage looks like this:

(s/exercise-fn `ranged-rand)

i'm not sure what the backtick quote is for in this context?

"Instrument takes a fully-qualified symbol so we use ` here to resolve it in the context
of the current namespace."

...huh. hm. what?
i guess this is the var equivalent of doing ::a-keyword
ok i guess

"Spec does not trust custom generators and any values they produce will also be checked
by their associated spec to guarantee they pass conformance."

nice

gen/fmap looks neat, very useful in the examples they give for custom generator use cases

**************
"We mentioned earlier that clojure.spec.test provides tools for automatically testing functions.
When functions have specs, we can use check, to automatically generate tests that check the
function using the specs."

neat!

"To test all of the spec’ed functions in a namespace (or multiple namespaces), use enumerate-namespace
to generate the set of symbols naming vars in the namespace"

(-> (stest/enumerate-namespace 'user) stest/check)

double-neat!

wonder if that works on `instrument`

http://blog.cognitect.com/blog/2016/9/15/works-on-my-machine-understanding-var-bindings-and-roots
explains what the term "root" means in the context of vars

explains difference between (binding) and (with-redefs) - the former alters a dynamic var's bindings
/ frames, the latter temporarily alters a var's root

"Var roots are global. Var dynamic bindings are thread-local, and dynamically scoped."

=========

9/16/16

http://leeorengel.com/from-schema-to-spec/

acknowledges that spec is noticeably more verbose than schema

i skimmed the parts where he's actually writing test.check tests, but this looks like a
useful resource to go back to when i'm interested in actually doing that stuff

"Compared to spec, schema felt a bit more natural to me at first coming from a more strongly
typed background as the schema information is right there next to what it is specifying."

same here, minus the strongly typed background

says spec is "more composable" and "feels like it fits into the language more naturally",
which i do also have to agree with

"I’ve seen some debate about where the best place to put specs are; to me it seems pretty
logical to co-locate them directly with the code they spec."

that's what i would do in schema if i didn't have to worry about circular imports so often
so i'll probably eventually go back to doing this
right now i think everything's in voke.schema

anyway good article, well written

http://www.lispcast.com/clojure.spec-vs-schema

"The library is a collection of small tools that do different jobs that can be used together.
There is a tool for maps (called keys) that checks for the presence of required and optional
keys and checks that their values conform to the named attribute. There is a tool for sequences
that uses regular expression operators."

good point yeah - in spec, maps -> (keys), sequences -> regex operators

"The keys function takes a list of required keywords which must be namespaced. Those keywords
play double-duty. They check for the presence of required keys and they name the spec that
the value must conform to."

http://gigasquidsoftware.com/blog/2016/05/29/one-fish-spec-fish/

is fine

http://derek.troywest.com/articles/the-elements-of-style

"If you find a pure function named this-and-that refactor `this` and `that` and compose elsewhere."

https://github.com/bbatsov/clojure-style-guide/issues/124

"We will not be adding any other "-" forms to core. I think perhaps if we could do it over,
defn- would not be added either, but we're not going to take it away."

interesting

https://stuartsierra.com/2015/05/10/clojure-namespace-aliases is good

https://stuartsierra.com/2015/08/25/clojure-donts-lazy-effects
***** i like this

"Never mix side effects with lazy operations."

https://github.com/jonase/kibit

TODO set up kibit

https://github.com/tolitius/boot-check is a boot analog

okok
darwin recommends installing https://github.com/binaryage/cljs-devtools , taking a look

note that https://github.com/boot-clj/boot-cljs-devtools exists

https://github.com/binaryage/cljs-oops looks useful

apparently a way of not having to deal with externs files

"Instead of (.-nativeProp obj) write (aget obj "nativeProp") which compiles to obj["nativeProp"]"

TODO take a look at cljs-oops next time i have to deal with anything related to externs files

=======

9/17/16

https://www.youtube.com/watch?v=VNTQ-M_uSo8

https://www.youtube.com/watch?v=dSqLt8BgbRQ

i like his bit about how when you're changing code, you're changing your mental model of the
system first, and then serializing that change back out into code, around 9 minute mark

cute idea - use code coverage tools to reduce a function into just the lines that actually
get executed by running your test case, calls it a program slice

https://www.youtube.com/watch?v=_9RgHXqH8J0
****** good talk on graphql

https://www.youtube.com/watch?v=mty0RwkPmE8&list=PLetHPRQvX4a_jQjvn54Q-d1WYZ52nDfnT&index=11
history of clojurescript

=======

9/18/16

right - the whole point of connecting intellij to your dirac repl (or to whatever other repl you're using)
is so that you can get vim-fireplace-like behavior in intellij, by using cmd-shift-p / etc to evaluate
forms, and play around with things that way. right right.

https://medium.freecodecamp.com/javascript-modules-a-beginner-s-guide-783f7d7a5fcc#.g2dt5cawr
*****
super good article on js modules

https://medium.freecodecamp.com/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b#.kpqslvqr1
great intro to docker

https://www.youtube.com/watch?v=33mTFjPIN10&list=PLetHPRQvX4a_jQjvn54Q-d1WYZ52nDfnT&index=7
this guy's totally in love with klipse, an in-browser clojurescript/python/ruby/etc repl

looks neat
apparently a main selling point is that it's super-live, and also that it's totally clientside,
you just add a <script> tag to your page (blog post, etc) and it's there, no need
to worry about eg uploading something to gist.github.com and then including an iframe or whatever, etc
https://github.com/viebel/klipse

https://github.com/aengelberg/loco
constraint based programming
looks like it'd be useful for project euler

https://github.com/sbelak/huri
library for data science
http://viewer.gorilla-repl.org/view.html?source=github&user=sbelak&repo=huri&path=examples/examples.cljw neat examples

http://gorilla-repl.org/ hadn't heard of this before
clojure notebook repl
https://github.com/JonyEpsilon/lein-gorilla

https://news.ycombinator.com/item?id=11991479
one repo vs many repos
google has one giant repo (?!?!?!?!?!)
https://www.youtube.com/watch?v=W71BTkUbdqE
*****

https://www.youtube.com/watch?v=Rzdxgx3RC0Q
caching at netflix
some of this went over my head, not too much tho
https://github.com/Netflix/rend
good narrative documentation

=========

9/19/16

https://www.youtube.com/watch?v=6IYm34nDL64
clojurescript + react native + mobile apps

https://www.youtube.com/watch?v=Oh5oC98ztvI
great behind-the-scenes talk on graphql + its history

https://www.youtube.com/watch?v=Elg17s_nwDg
great talk on the cljs compiler
******* really good talk

========

9/20/16

https://www.youtube.com/watch?v=_1rh_s1WmRA
ztellman on a frontend server he built at fitbit
pumpkin carver parable
"in every case, having many many people serving one queue will give you the best behavior
under adverse conditions" - money quote
*****************
talks about load balancing approaches
round robin, least in flight
"you improve what you measure" -> "everything you ignore will get worse"
good shit
for his frontend server, it makes more sense to track _overhead_ as opposed to total latency
makes sense
his key metrics: p999 overhead, request rate, error rate

https://www.youtube.com/watch?v=n7aE6k8o_BU
pattern matching
i like his bit about the start/work/end pattern in recursion, around the 36:00 mark

https://www.youtube.com/watch?v=0rmR80neExo&list=PLNoHgLVTxtaqo1c_V2I-8wkDrCGImb9v5&index=4
datomic in production
great speaker

http://patrickgombert.github.io/2015/datomic-performance/
datomic perf notes, bit over my head atm since i've never used it

http://www.learndatalogtoday.org/
datalog tutorial - looks really cool actually

https://github.com/lambdaisland/thirdpartyjs
how to use third party js libraries in cljs

https://betterexplained.com/articles/matrix-multiplication/

ok so anyway
i was super confused for like two weeks because i thought dirac was necessary for debugging cljs
turns out you can just call (js-debugger) and use chrome devtools
i used to know this, but had completely forgotten it because i put programming down for like six months

so i'm trying to figure out why sometimes you (or the monster) teleport

i have a sneaking suspicion that it's related to the fact that there's this JS collision system,
and it's always 100% kept up-to-date with every entity's location + bounding box and is updated multiple
times per tick,
and there's the list of cljs entities that we're processing this tick, and they're updated a total of
once per tick
and so these two sources of truth can get out of sync with one another, and anyway that seems like
a potentially super bad situation
also, i could swear i've seen at least one xxx comment saying "diagonal collision resolution will need this info"
which seems relevant

trying to get the issue to repro now, so i can verify that regular chrome devtools (plus cljs-devtools)
is all you need to debug cljs

this is super difficult to repro, so what i really need is a reliable failing test case / reproduction

ok, got a repro

new-center: 10.446 (that seems really low, wtf)
ok this is weird, here's what i'm looking at:
https://www.evernote.com/shard/s11/sh/edad4953-6aa4-4011-a59b-fa265ab2f6b2/6e46cf56db9cff72

i'm seeing two different values for new-center, one's 10.4, the other's a map
some sort of weird artifact with cljs-devtools?
ignoring the first one for now - i think that's supposed to be x-distance, not new-center

yeah, and here where it says "voke.events/publish-event", i think it should say "entity"
if i could repro *that*, could contribute a fix to the cljs-devtools project
but let's put that aside for now and focus on the bug in my app

ok so entity is the monster, and looks like this:
https://www.evernote.com/shard/s11/sh/ba234b99-1298-45a4-9f88-e8605e2f3379/5108c7f256f8b026
(cljs-devtools map formatting is actually really good, nice)

so new-center is (408.7, 257.6)
new-velocity is (0, 0)
current center is (398.2, 252)
current velocity is (0, -3.2)

seems odd that x velocity is 0
it looks like this atm
https://www.evernote.com/shard/s11/sh/326d398d-9154-4561-9b88-064ae36a41bf/8830244b7113be66
its left side is stuck up against the player, and it's trying to move up, so the current velocity
actually makes a lot of sense

so if the current velocity is (0, -3.2), then why are we trying to move this thing to the
right by ten pixels? that would indicate of a velocity of (10, -3.2), which we are *not* seeing
so let's go up the callstack

ok, we're in resolve-diagonal-collision - this is probably where the teleportation bug is!
seeing more cljs-devtools formatting errors - i see 4 things named entity, for instance; ugh
definitely gonna have to look into this and see if i can fix it... anyway

here are our variables:
https://www.evernote.com/shard/s11/sh/f17d497f-b8ba-43f7-95b0-25f04e151219/e6cbbf0e8fab51ab
https://www.evernote.com/shard/s11/sh/8159036c-5fe7-4e8b-b4d3-eeae24593851/2606d4892fec8781

so again, entity is our bad guy, and he's got a
position of (398.2, 252.05)
velocity of (0, -3.2)

and he's colliding with the good guy, who's got a
position of (373.27, 232.48)
velocity of (-0.065, -4.8)

and these guys are 25px by 25px
so currently their centers are 24.93px apart on the x axis
and 19.57px apart on the y axis

that doesn't seem right
ok cool, rounding error on my part just now - they're actually 25.01px apart on the x axis
but definitely only 19.57px apart on the y axis
but that part doesn't matter, because they're > 25px apart on the x axis, so they are currently not overlapping
so that's cool

so wait - if they're currently not overlapping because they're >25px apart on the x axis,
and their x axes are moving _away_ from each other (good guy is moving slightly to the left, and is
to the left of the bad guy)
then why the hell are we in resolve-diagonal-collision in the first place?

time to go up the call stack
this cljs devtools naming issue is really frustrating
also i can't seem to evaluate arbitrary expressions at breakpoint time, like i can't put a watch on
(finder :x), etc

i bet that's what dirac would be useful for - having a repl available right now

ok so anyway new-center is (397.3, 248.853)
new-velocity is (-0.97, -3.2)
that's interesting - so the monster is trying to move left after all! that actually makes a lot of sense
let's go back down the callstack again

yeah ok right - i was looking at `velocity` earlier but i should have been looking at `new-velocity`
still, though, is this really a diagonal collision? feels like this is a straightforward situation
where the monster is trying to move up and left, and up is clear but left is not clear,
and so it should be allowed to move up but not left

i wonder if this has to do with the 0.1px no-man's-land spacing between entities
back up the call stack

so in move-to-closest-clear-spot, we have
new-center (397.3, 248.85)
new-velocity (-0.97, -3.2)
x-position, x-velocity (397.3, -0.97)
y-position, y-velocity (248.85, -3.2)

i don't get why new-center's x and x-position's x are the same
shouldn't new-center's x be something invalid, inside the good guy?

ok so the bad guy's center is currently (398.284, 252.05)
...and it's trying to move -0.97 pixels to the left, which puts it at 397.3px as the new x position

and it just so happens that good guy's x center is (373.274445, 232.48)

and 373.274445 + 12.5px is. 385.774
and that plus 12.5px is 398.274

and anyway so it just happens that.. what exactly?

incidentally, good guy is moving 0.06538px to the left on the x axis atm
which means that good guy's new x position (which we can't see atm) is 373.20462
and that plus 25px is 398.20462

ok let's recap
we have the bad guy, and he's trying to move up and to the left
he is currently touching the good guy on his left side, and his y-center is a little bit below good guy's

so is he clear to move to the left?
well, he's at 398.284445 right now
and he's trying to move to 397.3097869
and that _is_ indeed clear
wait is it

ok ONE MORE TIME
good guy's right edge is at x = 385.774445
bad guy's left edge is at x = 385.784445
bad guy has an x velocity of -0.97465
meaning that he wants to move his left edge so that it's at 384.809795
and that's no good

ugh but why have i been focusing so much on x position? of *course* bad guy wants to move to the left,
into good guy, and of *course* that isn't clear

well, i've been focused on this because i'm in move-to-nearest-clear-spot, and the way it works is by saying:
we've got an entity!
it's trying to move to new-center!
it's collided with one or more other entities!
what happens if we move it just vertically? was that successful?
what happens if we move it just horizontally? was that successful?
if both of those appear to have been successful, then we know it's a corner collision - handle that
if just one of them was successful, then go ahead and just apply that single-axis movement

and so in our situation it tries to move the entity vertically, and that succeeds
(y-position is equal to (new-center :y), y-velocity to (new-velocity :y)

and it tries to move the entity horizontally, and that *appears* to succeed
(x-position is equal to (new-center :x), x-velocity to (new-velocity :x))

but that's fucked up! moving the entity horizontally should not succeed
so what's going on in this call to (find-new-position-and-velocity-on-axis) ?
i think it might be too late to find that out since i don't have a working repl since we're in a breakpoint

that function has a call to find-cosest-clear-spot, which has a ton of scary comments in it
so that's probably where we're fucking up atm

=======

9/21/16

ok so where were we

so the issue is that we're in move-to-nearest-clear-spot, and we're trying to move bad guy up and to the left
he's clear if he moves straight up, but not clear if he moves to the left
right now, (move-to-nearest-clear-spot) calls (find-new-position-and-velocity-on-axis) in order to see if we're
clear on each axis.
that function returns a 2-tuple of [axis-clear-position axis-new-velocity]
and so what move-to-nearest-clear-spot does is: it checks on both x and y axes, and sees if those return values
are the same as the values that the entity is already trying to use to move.
so like let's say you're at x=10 and trying to move right by 1px;
you're trying to set yourself to x=11, and you're trying to set your new velocity to be ~1.
if find-new-position-and-velocity-on-axis returns [11 ~1], then that indicates that you're clear to move right
if it returns [10.5 0], though, that indicates that you ran into something

and so the issue is that bad guy is trying to move left, and it's *not* clear to move left, but
find-new-position-and-velocity-on-axis is reporting that it *is* clear to move left. so something
in that function's callstack is buggy.

so that function is basically a wrapper around find-closest-clear-spot

i can't figure out the best way of setting a breakpoint in there that only gets triggered when the issue happens
so i guess we'll just leave the current breakpoint as-is, add some logging to this function, and try
to repro again

notes from find-closest-clear-spot:

; ok so
; bad guy is at 398.284445
; good guy is at 373.27445
; the js collision system says that good guy's *actually* at 373.2221
; bad guy is trying to move to 397.30978
; bad guy's new velocity is -0.97465

; so arithmetic-fn is +
; shape2 center axis is 373.2221
; so the thing should be running (+ 373.2221 12.5 12.5 0.01)
; which is 398.2321
; which seems correct. but that's not what find-new-position-and-velocity-on-axis is returning
; so maybe this function isn't being called after all

i think that find-new-position-and-velocity-on-axis might not even be calling this function after all

ok so find-closest-clear-spot is exonerated, because if it were being used, the x-velocity that
find-new-position-etc returns would be 0. but it's not 0!
so something's going wrong with this set intersection.

blat blat blat blat blat

added some print statements

seems like the reason this is so hard to repro is that it has something to do with timing, not sure why

so i have a repro here that looks like we actually sincerely do have a corner-only collision

good guy is at (455.293, 125.876), velocity (-2.250, 0)
bad guy is at (478.340, 150.886), attempting to move to (477.169, 150.585)
so good guy's _actual_ x position is currently 452.8927

anyway so he's clear to move on the x, and he's clear to move on the y
so we try to resolve the corner collision

and it turns out that the corner collision algo tries to move him to (480.393, 160.778)
which is super incorrect - he's getting teleported 10px down for no reason

anyway now that i know this is a corner collision bug, i should be able to just find a repro
by putting good guy and bad guy at specific positions that trigger this bug

ok, added some more logging to resolve-diagonal

maybe it has something to do with the fact that we're basing these equations on the shape's
center, rather than its leading corner, which is what we _actually_ want to position?

good guy at (723.624, 196.997)
bad guy at (700.7, 222)
bad guy wants to move to (702, 221)
bad guy being moved to (698.524, 232.200) by resolve-diagonal

ok i did some math on paper
and i'm pretty convinced that the issue is that we're basing this line math on the entity's center
rather than its leading corner

so TODO:

1) make the math be based on its leading corner rather than its center
2) make sure resolve-diagonal gets up-to-date colliding-entity centers from the js collision system
   before it breaks them into lines

i'll deal with that stuff tomorrow

=======

9/22/16

ok, here's where i'm at

i think that the teleportation bug is caused by resolve-diagonal-collision using the center of
the moving entity, rather than its leading corner, as a basis for its math

so i'm going to change that and see if it fixes things

i also think that resolve-diagonal-collision needs to be given an up-to-date view of all of the relevant
collided entities' positions from the js collision system

i should make that change first, before the leading corner change, and see if there's a way to make this happen
at the top of the collision resolution system, rather than at leaf functions like resolve-diagonal and
find-closest-clear-spot

this bug took a long time to track down (assuming that i actually _have_ tracked it down).

i think that there are a few reasons for that, aside from me having forgotten how to program over the past
six months or so

the foremost one is that i had absolutely no intuition about what parts of the system were good and what
parts might be buggy. this is because there aren't any tests, at all, for any of this code. i think the
program is now big enough that it merits tests, so that future bug hunts don't take this long.

also the bug was somewhat difficult to figure out how to reproduce reliably - but (and again, this is assuming
that i'm correct about the bug being in resolve-diagonal-collision) after all, though, it was in a big function
that had been added to the system extremely recently and had no tests, and so if the function *were*
tested when it were written, it would have been obvious that it was buggy, and all of this could have been
avoided. so that's cool

i'm also going to start using github issues to track things i want to work on, because again
i think the program has gotten big enough that there's value in that sort of thing

ok, cool
so let's start with giving the resolution system the most up-to-date view of the relevant collided entities

ok that was easier than expected
and i did the leading corner stuff to resolve-diagonal-collision

so i think we're more stable now
i did see one bizarre situation where it looked like there was a ghost player/monster-sized square
i'm going to hope that that was just an artifact from a weird figwheel reload
if i see it again in a non-figwheel situation then i can worry about it

ok, all done! merged the branch into master

time to start on tests first, i think. let's just get something super super simple running

howwww do i test cljs again

http://www.agynamix.de/posts/2015-09-22-doo-and-figwheel.html
this guy's creating a runner.js file by hand which he uses to make phantom run his tests
i don't think he knows about doo

https://github.com/bensu/doo/wiki/End-to-end-testing-example cool info on running full end-to-end tests
with a clojurescript frontend and a clj backend with just a single `lein test` command

http://www.lispcast.com/testing-clojurescript
***** ok this is super super super good
great context / narrative

http://www.agynamix.de/posts/2015-09-22-doo-and-figwheel.html documents an issue i remember running into actually
good job to this guy
hopefully figwheel's fixed its error since then though

========

9/23/16

https://gist.github.com/alandipert/4669472
interesting pattern for using a particular type of macro in cljs - guy's interested in locality,
so in the same cljs file where the macro is used, you can see what it's actually doing
i guess you could do this for lots of different kinds of macros, as long as you don't need access
to macros' ability to suppress/delay the evaluation of their inputs

travis or circleci?
travis seems more popular, have already used it with cljstone
https://mediocre.com/forum/topics/a-tale-of-two-ci-tools-differentiating-travis-and-circleci
these guys did a pretty exhaustive comparison, and circleci comes out sounding better
plus they use clojure, so what the hell, let's give 'em a shot
if i hate it, i can always switch to travis really easily
meh fuck it let's stick with travis, circleci doesn't seem to notice the doo plugin even though
it's defined clearly in my project.clj
...oh right, wrong branch

========

9/24/16

https://jstaffans.github.io/2015/11/19/fun-with-specter.html
**** dece

https://github.com/technomancy/leiningen/blob/stable/doc/TUTORIAL.md#checkout-dependencies this exists

spent a few minutes thinking about a workflow for automatically running tests (easy with doo)
so that i can immediately see their output in the browser (via figwheel) or in the editor (with cursive)
ended up just going with this super simple approach:
use the Terminal intellij plugin (accessible via hovering over the bottom left corner of the editor and clicking
Terminal) and just run `lein doo phantom test` in there
good to go
i wonder if there's a way to colorize the output from this command?

http://blog.venanti.us/ultra/
https://github.com/greglook/whidbey/ - repl colorization, doesn't do anything for tests though
installed it, repl colorization is nice, neat
https://github.com/brentonashworth/lein-difftest exists but just for clojure and is super old
https://github.com/greglook/puget - looks like it's clj-only atm

might have to make a lein plugin myself that does this, or fork doo to add support
i don't know anything about terminal colors
but http://blog.jayfields.com/2012/05/clojure-expectations-colorized.html seems like a good jumping-off point

i tried out specter briefly in state-test; i don't think it buys us anything over (get-in) in this particular
situation, but it might become useful for transforms or more complicated selects if i run into situations
where i have those. had a little trouble figuring out the relevant ns form - wasn't immediately clear
what the relevant namespaces were, what's a macro, what's not a macro, how do i require macros again, etc -
so i'm just jotting down what that ended up looking like here

(ns voke.state-test
  (:require [cljs.test :refer [deftest is testing]]
            [com.rpl.specter :refer [ALL]]
            [voke.state :as state])
  (:require-macros [com.rpl.specter :refer [select]]))

(def blank-game-state (state/make-game-state []))

(deftest adding-entities
  (with-redefs [state/buffer (atom [])]
    (state/add-entity! {:id 0 :renderable false} :combat-system)

    (print (select ALL blank-game-state))

    (let [updated-state ((state/flush!) blank-game-state)]

      (print (select ALL updated-state))
      (print (select [:entities 0] updated-state))
      (is (= (get-in updated-state [:entities 0])
             {:id 0 :renderable false})))))

====

9/25/16

ok, i've been working on testing handle-keyboard-events

it's pretty straightforward, except for two things:
1) can't figure out an elegant way to wait for the implementation of handle-keyboard-events
   to actually do its work, since it happens in a go block. i've got a (<! (timeout 100))
   using the implementation provided in https://gist.github.com/swannodette/5882703 , and that's
   working fine, but it's obviously gross and potentially flaky.
2) this function manipulates both the :input and the :motion components, which i guess makes sense
   but for some reason i thought it was only the :input component. seems to have a write-only relationship
   with the :motion component.

re: colorization in cljs.test output, @pat says:
@jrheard assuming you are using a unix terminal you will have to create a custom report
function that uses ansi escape codes; Figwheel uses ansi colors, id look there

cool, been doing lots of testing, that's been going pretty well.

things left to test:

voke.system.core (done)
ai system (do this later)
collision system
attack system (do this later)
movement system (done)
rendering system (nah)



=====

9/26/16

whooooaaa
https://github.com/mneise/clojurescript-site/blob/master/content/reference/javascript-module-support.adoc
seems to exist already, i should check that out

cool, wrote tests for the collision system, that was satisfying.
was going to implement a macro that would DRY up the tests a bit more, but i couldn't decide what
syntax i wanted to go with and i'm a big hung over so i'll do it some other time.

trying to switch to commonjs modules for our vanilla js files, having a bit of trouble
http://mneise.github.io/posts/2015-06-08-week-2.html seems relevant

========

9/27/16

modules are working! i think

http://inform-fiction.org/manual/DM4.pdf

ok it's time to figure out what leiningen profiles are, my profile.clj is getting too verbose/repetitive
also i'm switching to the mit license as long as i'm in here

https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md

https://www.reddit.com/r/Clojure/comments/54q5ng/newbie_question_passing_around_the_entire_state/
i really like this discussion

http://frenchy64.github.io/2015/06/19/gradual-typing.html

https://lambdaisland.com/blog/25-04-2016-union-types
********** super cool post

someday i should read
https://github.com/lambdaisland/uniontypes/blob/master/src/lambdaisland/uniontypes/core.cljc
and try to completely understand it
it looks pretty good

https://github.com/thegeez/clj-board/
trello clone in clj/s with re-frame

https://github.com/weavejester/ittyon
state management system for clj games

might be fun to try running https://github.com/weavejester/codox on voke as-is
heh never mind

ok right right right back to profiles
https://github.com/technomancy/leiningen/blob/master/doc/PROFILES.md again

"You can place any arbitrary key/value pairs supported by defproject
into a given profile and they will be merged into the project map when that profile is activated."

"Certain profiles are active by default unless you specify another
set of profiles using the with-profiles task. Each of the default profiles have different semantics"

"The :default profile specifies the profiles that are active
by default when running lein tasks. If not overridden, this
is set to :leiningen/default, which is a composite profile with [:base :system :user :provided :dev]."

:default profile seems pretty relevant - can i just add to it without overriding it?

"Remember that if a profile with the same name is specified
in multiple locations, only the profile with the highest "priority"
is picked – no merging is done. The "priority" is – from highest
to lowest – profiles.clj, project.clj, user-wide profiles, and finally system-wide profiles."

no, i don't think leiningen profiles are relevant here
i have some :foreign-libs that i want included in every cljs build

slack says that deps.cljs is the answer

seeing errors in closure compiler land when i try using that approach, though:
https://gist.github.com/jrheard/633ddf58e673ffc663b84401f81abefe

ok fuck this i'm just going to live with having :foreign-libs copypasted in several :builds
notes for posterity re: deps.cljs:
https://github.com/clojure/clojurescript/blob/eaebc1cdb39e3fed9e7e36ec1315337b77a0350d/src/main/clojure/cljs/closure.clj#L1746
https://groups.google.com/forum/#!msg/clojurescript/pJ_EYHkYAUs/mLi8XfiQxZsJ
https://github.com/clojure/clojurescript/wiki/Dependencies

ugh whatever this commonjs module business just is not working and i don't want to be stuck
in this rabbit hole forever

i'm going to just back out my changes

https://www.youtube.com/watch?v=TW1ie0pIO_E
*********** good
oh this is the guy behind chocolatier
talks about ecs around 7:40
he uses events too to avoid coupling
he likes devcards
around 24:45, he's got some sort of thing where he's extending hashmaps in order to autogenerate
a reagent component of the game's state?
talks about using middleware around 25:49
perf tips:
* variadic function signatures are slow, use multiple arities instead
* avoid partials
* apparently (empty? []) is slow, (seq []) is fast
* don't use (= :a :a), use (keyword-identical? :a :a)
* protocols/records/types are fast
* avoid intermediate collections
     around 30:43
     "break it out into a (loop), create a transient accumulator, use recur, maybe even use a plain js array"
* the ^boolean typehint is apparently actually useful
* he says that :static-fns can give you a 30-40% speed boost (?!?!?!)
* also mentions :elide-asserts

https://github.com/arcadia-unity/Arcadia

https://www.youtube.com/watch?v=lql2yFXzKUs&index=22&list=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb
http://store.steampowered.com/app/411610/
he likes clojure.zip/zipper
oh wow yeah this looks perfect for dialogue trees
down, right, up, edit, etc
***** around the 18 minute mark he starts talking about using core.async for scripted animations

ok, spec time

http://clojure.org/about/spec
interesting, hadn't heard of https://github.com/miner/herbert before
it has a similar conform function
jesus christ it is super spooky that the library has this like homage/tribute to the specific random
star trek episode i'm about to go see at the hollywood in like two hours
what the hell man

anyway back to this document
it's pretty good
it's interesting how focused they are on keeping maps' "keysets" separate from their
key-> value specs, it's not something i would have thought of as a problem

i'm not sure i understand the bit about semantic change and compatibility, i don't see how it's
relevant to spec from what i've seen of it so far

the "names are important" passage explains why the branches of :ors, etc, are named - makes
a lot of sense, very smart

interesting passage:
"Invariably, people will try to use a specification system to
detail implementation decisions, but they do so to their detriment.
The best and most useful specs (and interfaces) are related
to purely information aspects. Only information specs work over
wires and across systems. We will always prioritize, and where
there is a conflict, prefer, the information approach."

kind of handwavy, sounds nice but i'm not 100% sure what they mean by it

spec/keys' ::req portion supports (and) and (or), didn't know that

"By convention, specs for data should be registered under keywords
and attribute values should be registered under their attribute name keyword."
i have no fucking idea what this means, asking in slack

anyway overall pretty good document

=========

9/29/16

https://www.youtube.com/watch?v=kb-m2fasdDY
**** good shit
on rpc in the context of having a ton of services talking to each other:
"without types, it's a crazy mess! but it's not immediatley a crazy mess - you're
borrowing against a _future_ crazy mess when someone will change something, and then
maybe a couple of hops downstream they were depending on some subtle distinction between
an empty string and null..."
"we could have fixed all of this if we just had types"
around 22:40, talks about standardizing dashboards ****** good shit
tracing very important when you have a ton of services

on logging in a standard format across all languages in a world where 1000 engineers
have started within the last six months:
"mandates are tricky - give them tools that are so obvious and easy to use that they wouldn't
do it any other way"

later, on mandates: they're bad
instead: pure carrots, no sticks

starting on the transition to spec
some parts are straightforward, some are not
do i use namespaced keywords that match my project's namespaces, like :voke.system.collision/foo?
or do i use namespaces that are concepts, like :collision/foo?
asking in slack

wow http://www.clojure-toolbox.com/ has a ton more stuff on it than the last time i looked

ok i've been doing a ton of spec conversion

it's been mostly mechanical once i got going, although coming up with namespaces for keywords
was a bit tricky

i'm going to need to come up with some sort of grep command that finds bare non-namespaced keywords

TODO - go back after initial round of speccing and see if any fdefs could benefit from a :fn

if i had to do this over again i would have used find/replace or sed waay more

======

9/30/16

slack says cursive EAP has support for #:foo{:bar :baz} syntax, gonna try upgrading
https://cursive-ide.com/eap.html

neat

playing around with gen, exercise, and test.check
gen and exercise both accept an "options map", documented as:

`
Optionally an overrides map can be provided which
should map spec names or paths (vectors of keywords) to no-arg
generator-creating fns. These will be used instead of the generators at those
names/paths. Note that parent generator (in the spec or overrides
map) will supersede those of any subtrees. A generator for a regex
op must always return a sequential collection (i.e. a generator for
s/? should return either an empty sequence/vector or a
sequence/vector with one item in it)
`

notes from me rubberducking into slack:

i’ve got a somewhat complex map spec that i’m trying to s/exercise,
and i’m getting the dreaded "Couldn't satisfy such-that predicate after 100 tries.” error.
what are the primary things i should be looking for when trackingdown the root cause?
i’m familiar with s/and and how you should eg do int? first, followed by even?, etc (edited)
is naive `s/and` usage the primary trigger for this error, or
are there other categories of spec misuse that often cause it? (edited)
(if it’s helpful, the spec i’m trying to exercise is
https://github.com/jrheard/voke/blob/spec/src/voke/specs.cljs#L74 ) (edited)
i’ve only got one s/and in here, and it’s a `(s/and number?
pos?)`, so i feel like there must be some other category of thing i’m doing totally incorrectly
hm, seems to be specific to :component/input
this guy’s the culprit: https://github.com/jrheard/voke/blob/spec/src/voke/specs.cljs#L22 (edited)
the documentation on :kind says: "Note that if :kind is specified
and :into is not, this pred must generate in order for every
to generate.”; and adding `:into #{}` fixes the issue. guess
i need to sit down and take some time to understand the semantics of `:kind` and `:into`.

interesting - in http://tales.sveri.de/posts/2016-05-28-clojure-spec.html , he has his
(s/fdef) calls *above* his (defn)s. wonder if that works, and if so how

ok anyway i fixed a lot of tests and i think the game is working again
i am so glad i wrote all these tests
they were really really really really useful just now

ok now let's set up instrumentation and generative testing

hm, it's not obvious what the right way is of actually defining / checking the output of
these generative tests

let's read the documentation for test.check

man i just cannot get (-> 'foo stest/enumerate-namespace stest/check) to work
maybe it doesn't support cljs? i don't know

anyway stest/summarize-results is useful

=======

10/1/16

heyyyyy
http://leeorengel.com/from-schema-to-spec/
looks relevant

so it turns out test.check has this macro called defspec that i should look at
and also test.chuck exists but i don't understand what it is / how it relates to test.check

http://www.anthony-galea.com/blog/post/hello-parking-garage-meet-clojure.spec/
mentions that test.chuck includes a string-from-regex generator, seems handy in certain situations

http://blog.colinwilliams.name/blog/2015/01/26/alternative-clojure-dot-test-integration-with-test-dot-check/

i think i can ignore test.chuck for now

https://github.com/clojure/test.check/blob/master/src/main/clojure/clojure/test/check/clojure_test.cljc#L63
mentions there's this concept of a "test var"

https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/test.cljc#L206
has the same concept

i am having just a devil of a time testing update-fire-directions
seeing output that indicates that quick-check isn't running on my guy at all?
like, i just see the empty list as a return value from stest/check
which seems bad

let's see if we can figure out how to generate an example value from our fn's spec's :args

======

10/2/16

ok so i've got a local copy of clojurescript that i'm pointing my project to via checkout dependencies
i found one issue, which is that the cljs spec documentation says your option maps should look like
{:clojure.spec.test.check/opts {:num-tests 100}} but actually they should be {:clojure.test.check/opts {:num-tests 100}}

i don't think i've seen the issue i'm trying to track down - where (stest/check `foo/bar) sometimes returns [] -
since starting work with this local clojurescript. maybe it was a bug that has been fixed on master?

another frustrating issue: the doo runner (or *some* piece of code) hangs indefinitely after the test run completes
when i've got an s/check test, so `lein doo phantom test auto` no longer works. irritating

=====

10/3/16

ok i submitted a jira issue and patch re: the options map documentation issue, that feels nice

i'm strongly considering just not using (stest/check) until that whole part of the system
has had another few months to be fully baked - in particular, re: doo integration
although i'm toying with the idea of spending a few days digging into this and maybe fixing
any underlying issues in cljs/doo, so we'll see

but anyway i do want to have instrumentation

so i'm gonna poke at that next

so what's the best way of getting this?
let's take a look at leiningen preloads, i saw that dirac / devtools uses them, they sound useful here

https://github.com/clojure/clojurescript/wiki/Compiler-Options#preloads

couldn't get it to work, complained about no such namespace voke.preload
wondered if it might be the case that preloads have to be .clj instead of .cljs, but that wasn't it
it's on the classpath, src/voke/preload.cljs
oh well

couldn't find any example projects that use their own preloads via github code search,
only found a million pages of devtools.repload, dirac, etc

ok, turned on instrumentation
immediately getting a failure in process-a-tick
it's complaining that.. game-state/entities isn't a map, and that none of the entities it contains are maps
how can that be?

useful tip for navigating big spec failures: look for ":in "

for one thing, looks like the spec for :game-state/entities is incorrect:
(s/def :game-state/entities (s/coll-of :entity/entity))
shouldn't be using :coll-of here, it's a map of int -> entity

ah, map-of exists, nice
v easy

that seems to have fixed it

ok, i had another issue where i had gotten mixed up about the right syntax for having multiple constraints
on fdef args

i was doing things like this:

:args (s/cat :foo (s/and :bar/bar
                         #(contains? (% :foo) :baz))

but instead i should be doing

:args (s/and (s/cat :foo :bar/bar)
             #(contains? (% :foo) :baz))

and that makes much more sense.

ok, merging this spec branch into master
looks pretty good so far
there are a few TODOs i should go back and resolve
mostly in the attack system, which could really use another pass

=====

10/4/16

there's something in input-test that makes testing freeze when stest/instrument is called
but it doesn't reproduce reliably
v frustrating

ok time to learn how to write macros
http://www.braveclojure.com/writing-macros/ is good

======

10/5/16

ran into some issues around cljc files
i need to sit down and read about cljc files' semantics/rules from scratch

http://blog.cognitect.com/blog/2016/10/5/interactive-development-with-clojurespec
** good article

good examples of exercise, exercise-fn

notice how when they have several functions that share the same arg spec, they extract it out
into its own named/defed thing; should look into doing that in eg the collision system

https://github.com/clojure/clojurescript/wiki/Using-cljc
on cljc
doesn't answer my questions

http://stackoverflow.com/questions/14781868/how-do-i-deal-with-required-clojurescript-code-from-clojurescript-macros
seems relevant
looks like i can refer to namespaced symbols directly in the syntax-quoted body of the macro, so i'll try that

back in http://www.braveclojure.com/writing-macros/
**** man this is good
"One subtle pitfall of using macros is that you can end up having to write more and more
of them to get anything done. This is a consequence of the fact that macro expansion happens before evaluation."
too true, dude

"But report, operating at macro expansion time, just can’t access those values. It’s like
it has T. rex arms, with runtime values forever out of its reach."

"Double evaluation and variable capture are two other subtle traps for the unwary, but you
can avoid them through the judicious use of let expressions and gensyms."

this article is super good overall, big fan

ok time to try to understand https://github.com/lambdaisland/uniontypes/blob/master/src/lambdaisland/uniontypes/core.cljc
example usage in the readme on https://github.com/lambdaisland/uniontypes
looks neat but i don't think i'll be immediately reaching for it
neat application of spec tho

https://www.youtube.com/watch?v=GglfimrfYn4&list=PLZdCLR02grLq4e8-1P2JNHBKUOLFTX3kb&index=8
neat, not directly relevant to any stuff i'm working on but neat

ok anyway my current plan for the next few hours is to
1) clean up voke.system.attack
2) take one more look at stest/instrument and stest/check, particularly re: voke.input, to see why they've been behaving poorly

did 1; tried again to do

(stest/instrument (stest/enumerate-namespace 'voke.events)), but i get an error message complaining
that stest doesn't exist. poked dnolen, he says it's a bug, opened CLJS-1811. fun!

i'll continue to poke around and instrument/check a few namespaces, and try to see why voke.input is being
so recalcitrant, but will put off putting together a fully polished cljs.spec.test setup until cljs-1811 is fixed

hm, even adding a single
(stest/check `events/publish-event)
to events-test causes tests to hang, but only _sometimes_
guess i need to add some printfs, eh

i think i may have found another bug in cljs spec test
it looks like calling (stest/check `foo/bar) has the side effect of instrumenting foo/bar
i don't think that's intentional
it looks like (stest/unstrument 'foo/bar) is supposed to only return 'foo/bar if it was unstrumented
gonna compare against the clj implementation

yeah, in clj, if you unstrument a noninstrumented var you get [] back

opened cljs-1812

aha - i was having trouble tracking down the implementation of set!
i think it's here:
https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/compiler.cljc#L1022

ok i had fun poking around with stest again but i think i'm going to put it down yet again

=====

10/6/16

example gen override usage via slack:

(defn foo [x] (println "FOO" x) (inc x))
(s/fdef foo :args (s/cat :x ::x))
(s/def ::x clojure.future/int?)
(stest/check `foo
             {:gen          {::x #(gen/return 10)}
              ::stestc/opts {:num-tests 1}})

where gen is [clojure.spec.gen :as gen]

https://www.youtube.com/watch?v=JaKLSH4csqE&list=PLPgnbBCmP6ZMfHPJ4yMwuoLEZvEe5LVe8&index=7

"names are orders of magnitude more common than any other form of indirection"

=====

10/7/16

ok, came up with some stuff on the bike ride in re: health, damage

so we have a health system and a health component, and it looks like this:

:component/health {:health/health 100
                   :health/max-health 100}

super simple. the system listens to :contact events, which cover situations like this:
1) projectile touches something it can damage
2) non-projectile entity touches something it can damage
which i guess are basically the exact same thing. TODO: where is "the amount of damage i do on contact" encoded? come back to this
3) player walks over a food / health / etc powerup
4) monster fires healing projectile at another monster

the player will likely also be able to heal himself using spacebar items like in BoI; for that,
the inventory system will listen for :use-consumable-item events (fired by the input system)
if the player has a consumable item in their inventory, the item runs a function from game-state -> game-state
this can eg heal the player, stun all enemies, turn the game upside down, etc etc i don't know
if the player has no consumable item, nothing happens

and there's a death system that either runs every tick or listens to :damage events and removes any dead entities
(at the start or end of the frame)

https://idea.popcount.org/2016-09-20-strange-loop---ip-spoofing/
good article

oh right, re: the above topics, i forgot about status effects

so when the player's hit by a bullet, or a bad guy touches him, he takes some damage and
turns temporarily invincible

that's a status effect, so there's a component that looks like this

:component/status-effect {:status-effect/effects [{:status-effect/type :invincible
                                                   :status-effect/expiration 123853283}]}

and that'll also be used for eg poison, stun, etc etc

ok, so where does "the amount of damage i do" go?
how about just a plain old :component/damage component?
if it exists, it signifies that entities who a) collide with it and b) can take damage (have a health component
and are not invincible, etc) should be damaged

so what does this mean for systems, though?
do we have a health system *and* a damage system?
or just a damage system?

one approach:

the damage system listens for :contact events, performs no actions/modifications on entities, and
emits :damage events. this seems like an unnecessary layer of indirection, but i could see it being useful
for eg lifesteal; projectiles that spawn monsters when they successfuly hit; etc. i like this actually

ok so the health system listens to :damage and :heal events, and updates entities' health accordingly,
and is just really really small and that's ok

seems fine to me

https://8thlight.com/blog/eric-smith/2016/10/05/a-testable-clojurescript-setup.html
**** good
explains how to set up a cljs project + environment from scratch
"It's idiomatic to create a function and call that as the last line of your main ClojureScript namespace"
good because that is what i do
https://github.com/bhauman/lein-figwheel/wiki/HTML-watcher-including-browser-reloading
has info on how to get figwheel to reload when you make html changes
i am... not going to do that

he uses this doo-all-tests function, i haven't seen that before

http://adventofcode.com/ looks cool, will have to take a look at that

ok setting these things aside for now, back to health/damage

i'm torn between whether to have the health system handle death, or whether to have a separate
death system
i think i'll probably do the latter? just seems like the health system will be really small, but whatever

=======

10/10/16

spec notes from slack:

<me>
noob question, i’m sure, re: conformer - i reached for conformer when i was operating on
data that looked like “123”, but i wanted (s/conform ::my-spec) to parse the integer such
that it ended up being 123. what should i use instead of s/conformer in situations like that,
for coercion of this sort
i felt like i read about something that would solve this problem idiomatically in the rationale
or guide, but couldn’t find it when i went back to look for it

<seancorfield>
yes I have a lot of cases where I have strings as input but I want them conformed to integers
(for API input specs). But @alexmiller has told me a couple of times that is "not idiomatic"
and to avoid conformers like that :(

<me>
hm, i don’t understand - the strings have to be turned into integers at _some_ point, right?
is it more idiomatic to have a secondary, non-spec transformation layer that happens after s/conform?
i’m sure @alexmiller has good reasons for saying that, but i don’t understand what spec users are actually supposed to do here

<alexmiller>
The downside is that once you enshrine a conversion into your spec, you have made a conformance
decision for all future consumers that has removed information. If you understand this ramification
and are willing to live with the consequences, then that's up to you.
There are many ways to apply conversions - you should be aware of when you are conflating conformance and conversion though

<me>
i think i follow those statements, but a “in situations like that, try doing this instead” example would be supremely helpful :slightly_smiling_face:

<alexmiller>
There's not one answer
You can apply post transformations
You can apply a second spec
You can apply a different spec in one case vs@another
Etc
And in some cases conformers might be the right answer

====

10/11/16

been reading through the cogmind devblog all afternoon
super neat stuff
http://www.gridsagegames.com/blog/2016/09/ability-effect-systems-scripted-content/ seems relevant

http://www.gridsagegames.com/blog/2014/07/dungeon-metrics/ talks about randomly generated dungeons
also pathfinding

"Another tip for more efficiently addressing issues during
development: Always have the generator output the random
seed used to generate each map (I have mine added to an
ongoing list). That way you can always feed the seed back
into the generator to repeatedly generate the same map
and find out what went wrong or how the algorithm could be improved."

oh fuck he has a whole series of posts on this topic
http://www.gridsagegames.com/blog/2014/06/procedural-map-generation/
***** TODO COME BACK TO THIS LATER

https://github.com/binaryage/dirac/blob/master/docs/about-repls.md
boy this is complicated
https://lambdaisland.com/guides/clojure-repls

=====

10/12/16

already learning some new stuff from https://lambdaisland.com/guides/clojure-repls/clojure-repls
apropos
pst
dir

http://vvvvalvalval.github.io/posts/2016-07-24-datomic-web-app-a-practical-guide.html
recommends luminus
maybe come back to this when i actually use datomic

http://nommu.org/memory-faq.txt

http://lwn.net/Articles/250967/

=====

10/13/16

i'm going to spin up a roadmap.md to just be a central master list for feature ideas, etc
i don't yet completely understand the relationship between dev-diary.txt, roadmap.md, and
the github issues tracker, but this still seems like a sane idea

let's read this series http://www.gridsagegames.com/blog/2014/06/procedural-map-generation/

he describes a few common techniques for generating randomized maps
bsp trees (rooms and corridors) - seems very relevant
drunkard's walk
cellular automata

"Beyond choosing a method of generation (or mixing multiple methods), any number of parameters
must be established and tweaked to produce layouts that work for the gameplay. Many small
rooms or fewer large rooms? Lots of long corridors, or no corridors at all, just rooms separated
by doors? An expansive winding cave system that draws the player to explore and lose themselves
in it, or a mostly linear cavern contoured as it is for the atmosphere?"

i currently want:
fewer large rooms
medium-length, fat corridors inbetween them
(i don't want the player to be able to just funnel everything into a chokepoint and hold the fire button
and kill everything without having to think - monsters should be able to spill through chokepoints and
overwhelm you)

******
come to think of it, teleglitch's levels did a good job of this - fat corridors
separated by wide automatically opening+closing doors

"Cogmind is mostly ranged combat, so wider corridors and large rooms are much more common to give combatants room to find a shot."

*****
"the primary factor I pay attention to when tweaking map parameters is the number and density
of loops. By loops I mean places where multiple pathways reach the same destination. A map
with few or no loops in its layout will require lots of backtracking, and backtracking is _not_ fun!"

"Long paths that lead to dead ends had better at least contain treasure or access to a new area."

he uses a combination of tunneling and cellular automata

http://www.gridsagegames.com/blog/2014/06/mapgen-tunneling-algorithm/

i don't want to use tunnelers, i want more of a cavelike feel than a room-and-corridor feel

i wonder.. this is funny+dumb
i think that because my current collision system can only handle axis-aligned bounding boxes,
these roguelike dungeon generation articles are going to be surprisingly relevant for me
because really it's going to be like the _level_ is laid out on a very coarse grid, but the player
and monsters can move about with a much much higher granularity

so basically it's gonna be like if you're playing a zoomed-in version of the cogmind mines, for instance
neat! dumb but maybe actually also kinda cool

apparently it's difficult to make 2-width corridors happen, just 1-width and 3-width? weird

"During the generation process tunnelers are responsible for laying the paths that take the
player from an entrance to an exit, of which there are usually several with a guaranteed
amount of space between them. How tunnelers move and what they decide to do pretty much determines
what most of the map will look like."

**** note - important phase in generation is to pick an entrance and an exit, and create one
or more paths from the entrance to the exit. makes sense

he talks about cellular automata in http://www.gridsagegames.com/blog/2014/06/mapgen-cellular-automata/
says he likes http://www.evilscience.co.uk/a-c-algorithm-to-build-roguelike-cave-systems-part-1/
and that it's nonstandard

"I don’t have a lot of experience fiddling with cellular automata, but the few times I tried
it was somewhat difficult to tweak for good results. This method produces good results _with ease_."

======

10/14/16

ok, gonna pause for a second and work through https://github.com/Rovanion/webgl-clojurescript-tutorial

that was all right but i didn't really understand any of it
https://github.com/thi-ng/geom/tree/develop has an impressive list of features i don't understand
"React.js component helpers for WebGL" hm
see also https://github.com/kovasb/gamma if i ever want to do webgl stuff

https://www.reddit.com/r/roguelikedev/comments/57dnqk/faq_friday_49_awareness_systems/
wow i'm going to read all of these

https://www.reddit.com/r/roguelikedev/comments/2tcvaj/faq_friday_1_languages_and_libraries/

https://bitbucket.org/libtcod/libtcod/wiki/Features seems worth reading at some point
"fov toolkit" and "pathfinding toolkit" seem relevant

https://www.reddit.com/r/roguelikedev/comments/2yuuom/faq_friday_8_core_mechanic/ is good
i haven't thought about voke's core mechanic, i think that's fine

voke's really just a learning experience

if i want to make a super cool roguelike after this, _then_ i can do a lot of research and thinking
and design before i start to actually work on it

http://www.gridsagegames.com/blog/2014/03/balance/
lol jesus christ ok nvm maybe i'm not interested in actual gamedev, this looks so boring

http://jere.in/time-travel-is-hard
he talks about having trouble saving the whole game state whenever things change
clj solves that :)

`One thing that doesn't get mentioned enough is that 'omnidirectional light emitters' can
easily be simulated by a circular FOV algorithm, and 'beam light emitters' can easily be
simulated by a conical FOV algorithm. So the lesson for newbie developers is that if you
implement a flexible FOV algorithm you get lighting for 'cheap', if not 'free'. You still
have to think about ambient light levels and how that plays into Character's FOV in a world
where there's lighting, but it gets you out of the gate.`

in https://www.reddit.com/r/roguelikedev/comments/30fvqp/faq_friday_9_debugging/
they complain that unit tests aren't useful in roguelikes
because "Many of the bugs in roguelikes are due to combinations
of inputs that you didn't think of. Unit tests can't help
here, because in order to write the test, you'd have had to have thought of that combination."
generative tests to the rescue?

https://www.reddit.com/r/roguelikedev/comments/358mt5/faq_friday_12_field_of_vision/

"Cogmind uses a brute force Bresenham raycast model that shoots rays from the FOV origin
to every cell along the edges of a bounding box that represents the farthest possible area
visible, and each ray quits after either reaching the maximum sight range or as soon as it
hits an opaque wall. Yes, there is lots of overlap, but it also ensures a more liberal result
that catches everything that should be seen. It’s worth the extra cost, rather than having
the occasional odd piece missing around a strangely shaped map feature. (And becomes absolutely
necessary if you want to properly implement semi-transparent cells.)"

adding fov sounds like a fun idea, not sure if i'll actually do it though

https://www.reddit.com/r/roguelikedev/comments/3b4wx2/faq_friday_15_ai/
"The one roguelike I didn't do this in, Gruesome, just has random AI movement, some with
slightly different weightings dependant on the unit's colour. I've seen interesting discussion
from players on how the AI is super-smart and tries to keep in safe areas. It's all false,
but humans are great pattern spotters :) This taught me that there's no point spending time
on complex AI - humans don't notice it well and will imagine that stupid AI is complex anyway :P "

*********
this first post is really good
particularly re: maintaining a certain distance range, and pack tactics / hit and run pack

"A Smart Object can consist of multiple Interactions, and an Interaction holds an Action
Chain, which basically guides an actor through a chain of actions required for the interaction
(rather than the actor "knowing" how to interact with everything, the Smart Object tells
the actor how it should be interacted with)."

this whole comment - https://www.reddit.com/r/roguelikedev/comments/3b4wx2/faq_friday_15_ai/ - is very good

the demons guy's post is interesting
"How do monsters decide whether to use their turn doing something else, like moving, rather than using an ability?"
"For the most part, the AI hates moving and regards it as little better than doing nothing.
It will only consider moving if none of the ability->target evaluations come up as Average
(100.0) or better, and the chance of it doing a move instead of the best it found is roughly
proportional to how how far below Average that best evaluation was."

"In NetHack 3.4.3, monsters tend to avoid the previous four squares they've stepped on. This
causes them to have a tendency to go down corridors rather than random-walk back and foth.
In NetHack 4, monsters have a goal square at almost all times (they can go without one for
a turn, in which case they'll pick a new one at the end of the turn). Lots of things set
a monster's goal square, such as seeing the player, hearing noise, seeing an item they want
to pick up, and the like. If a monster reaches its goal, or cannot make progress towards
the goal, it picks a new one on the next turn."

*****
"Currently I have some sort of ability-based AI, where different behaviours are not coded
in each AI, but on the abilities. I just add a list of abilities to each creature, then when
that creature tries to attack, it runs through all its abilities getting the situational
value for each of them, and choses the best one for the situation."

https://www.reddit.com/r/roguelikedev/comments/3b4wx2/faq_friday_15_ai/csjjo2b
***** this is much more relevant to my situation

http://www.roguebasin.com/index.php?title=Monster_attacks

https://www.reddit.com/r/roguelikedev/comments/3ldi50/faq_friday_21_morgue_files/
interesting
BoI has this, cogmind has this

http://www.gridsagegames.com/blog/2014/10/player-always-right-existential-approach-game-ai/
on simpler-is-better AI
"Any game that can should try to get away with the simplest AI possible and work up from
there as necessary, just beyond whatever point at which the AI is apparently behaving stupidly."

https://www.reddit.com/r/roguelikedev/comments/3slu9c/faq_friday_25_pathfinding/
he likes A*
"It uses Manhattan distance to the goal as the heuristic, and search data is sorted in a binary heap."
"Pathfinding is easily the single most CPU intensive process in Cogmind (and many other games).
Right now 47% of the CPU cycles are spent calculating paths!"
gonna have to watch out for that
i think i'll just avoid it by having pathfinding only be run every eg 10th tick
(will have to avoid thundering herd)

robinson's clojure a* implementation is:
https://github.com/aaron-santos/clj-tiny-astar/blob/master/src/clj_tiny_astar/path.cljx
"It returns a list of (x, y)s from the start to end positions if a path exists."

https://www.reddit.com/r/roguelikedev/comments/448jw6/faq_friday_31_pain_points/

https://www.reddit.com/r/roguelikedev/comments/50qbig/faq_friday_46_optimization/

"FOV is not really an issue, because it would be crazy to try calculating the huge number
of FOVs practically in real time, and at the sight ranges which are common in Cogmind (16+).
Instead I opted to only calculate the player's FOV, while all other actors just use direct
lines to check for visibility of nearby hostiles."

http://www.goldenkronehotel.com/wordpress/2015/10/10/tightening-up-the-graphics-on-dungeon-floor-3/

TODO understand http://humbit.com/pathfinding/test.html

ok, back to http://www.gridsagegames.com/blog/2014/06/mapgen-cellular-automata/

he talks about "guided" cellular automata - makes the cave fit into a longer, thinner box
in order to avoid the player having to do a lot of backtracking

http://www.gridsagegames.com/blog/2014/07/dungeon-metrics/
he's talking about taking a generated map and analyzing it based on a bunch of different heuristics
if the map seems like it's bad, throw it away and generate another one
eg
* playable space, with a lower and upper bound
* number of rooms of different sizes
* minimum distance between entrance and exit

"Once you’ve decided to keep a generated map, there’s still plenty to be done. It’s time
to analyze the content and layout to record what useful info we can."

"The simplest component we’ll want to remember is where all the rooms/caves are located.
Caves are a different story since they were grown randomly. To find them
we just scan the map with a standard floodfill."

TODO what's a floodfill

"General statistics collected from the final map may also affect what you decide to do with
it as a whole, data like the percent composition by cell type, maximum and average seclusion
of areas, the largest individual hall/cave, etc. These could of course be used as additional
requirements to filter out unwanted maps."

"So what do we do with all this collected data besides decide whether to throw away a map?
The obvious application is object placement."

"My favorite analytical tool for cave systems is the relative connectedness of each cave."

"Because the number of direct cave connections alone is less meaningful in many scenarios,
I define “connectedness” as the number of immediately connected caves plus the number of
caves those are connected to as well."

"Less connected caves in different parts of the map are likely positions for entrances/exits,
and others are good candidates for placing loot, secrets, or perhaps nastier surprises for nosy explorers.

At the other end of the spectrum, well-connected caves are where most enemy activity will
probably be concentrated."

************************
dude this makes so much sense

rimworld: https://www.youtube.com/watch?v=RMBQn_sg7DA this video fucking rules
***********
reachability, pathfinding, closest-item finding
regions remind me of geoquads vs latlongs
just a coarser granularity
y'know, rimworld's levels look a _lot_ like the ones i want to generate
AABBs and all
this might be super super relevant stuff

i like how he says it's mostly about your data structures, algorithms become clear based on those
i'm going to steal this region concept

he talks a lot about recalculating regions, rooms, etc when the geography changes, but i don't
plan on having the maps change in mid-game - nothing will be creating or destroying geography
so that makes things simpler
we can precalculate a bunch of metadata and know that the geography-based portions of it will not change

around 24:00 he talks about regions with shared spans, and about hashing the spans
i didn't understand why the system he describes works, but it looks like there are some implicit
rules about where spans live, and that's how neighboring regions can share spans
qualifying areas for spans: bottom row, left column, top+1 row, right+1 column
and so that's how they overlap. see?

i _don't_ understand how the system works if a fully enclosed room is wholly inside one region though

overall the region system seems like a very good idea, nice

=======

10/15/16

ok cool
it seemed like i must have some other stuff to work on first before tackling world generation,
but i don't think there's anything super high on the list

i obviously need to get around to making different kinds of enemies at some point, but might as well
have a big world to test them out in, right?

i really like the way rimworld's levels look, they're 400x400 grids that still manage to have an open
cavelike feel. i can't find any info on how they're generated, but they look like the ones generated
by cellular automata in http://www.gridsagegames.com/blog/2014/06/procedural-map-generation/
so that's the approach i'm going to look into first

heh, i see viebel in slack talking about klipse again - maybe if this goes well i can show
it off as a blog post? we'll see

so yeah look into cellular automata and then spend a lot of time processing and implementing
http://www.gridsagegames.com/blog/2014/07/dungeon-metrics/

which come to think of it i'm still processing

so he's talking about room connectivity, and how that's a useful metric
the bit about seclusion is interesting, makes sense in tunneled levels

http://www.gridsagegames.com/blog/2014/07/dungeon-prefabs/ is interesting, i prob won't use it though

http://www.gridsagegames.com/blog/2016/03/generating-populating-caves/

"“encounters,” wherein caves (analogous to rooms in room-and-corridor
maps) each have their own content pulled from a pool of
available encounters that themselves generally fall into one of four categories: fluff, rewards,
risk vs. reward, and danger."

sounds relevant

"the cave generator itself, which isn’t even a part of the game engine (i.e. it can be run without Cogmind at all)"

this is what i was planning for my generator too, cool
i think it's just going to output a 2d vector of edn
which can be used by the game engine to create a level, or visualized using dev tools of some sort

http://www.gridsagegames.com/blog/2015/05/map-composition/

ok spinning up https://github.com/jrheard/voke/issues/34 to track this issue and centralize related links

http://dungeonmaker.sourceforge.net/DM2_Manual/index.html
this claims to be the most advanced dungeon generator on the planet, but appears to be from 2005

"I always like to watch the movie of creating a labyrinth/dungeon hybrid, because there are
a lot of surprises, and some very tricky environments get created. But would these environments
be fun to play in? I really don't know. No doubt it depends much on the game dynamics, and
unconventional dungeons such as these would have to be playtested before any decision is
made on including them in a game. The fact that the DungeonMaker is capable of making develishly
difficult dungeons should not induce us to base a game on them. It may well be that simpler
dungeons are more fun."

i like that

" The lower down you go, the better treasure you can get. Every dungeon has a number of magical
artefacts and one major treasure. When you steal one of these, the AI will mount a serious
attempt to corner and catch you, while they might otherwise have been content to just see
you leave. If you steal the major treasure, the alarm will even go out to neighboring dungeons,
and they will already be in an alert hunting stance when you enter them. "

https://www.reddit.com/r/gamedev/comments/1dlwc4/procedural_dungeon_generation_algorithm_explained/

this isn't going to be super relevant, he's got room-and-corridor levels, but probably still interesting

"At this point we have 150 random cells in a small area, most are overlapping. Next we use
simple separation steering behaviour to separate out all of the rectangles so that none are
overlapping. This technique ensures that the cells are not overlapping, yet in general remain
as tightly packed together as possible."

this post is pretty good actually

http://pcg.wikidot.com/pcg-algorithm:drunkard-walk
heyyy what - procedural content generation wiki?!

anyway this seems like a good algorithm to start with, since it's so easy
update: it was really easy

http://forums.roguetemple.com/index.php?topic=4128.0 makes more sense now

http://pcg.wikidot.com/pcg-algorithm:dungeon-generation

"There are two basic approaches to dungeon generation: place the rooms first, then attempt
to connect them via corridors; or place the corridors using a maze generation algorithm,
then unify sections of the maze to form rooms.
 The first approach is easier to understand and by far more common, but it does not guarantee
 connectivity between all parts of the dungeon for every dungeon generated, so may require
 an existing dungeon layout be discarded and started again."

"Depending on the complexity of dungeon layout attempted, the tunnelling code required to
connect the rooms can get extremely complex and be prone to connection failures, and consequently
disconnected segments of the dungeon. The usual approach is to use a spanning tree algorithm
to validate that all rooms are connected correctly, by adding rooms at end endpoint of the
corridor to the spanning tree."

this is the second time i've seen spanning trees come up - this will likely be the data structure
we use to figure out whether there's a clear path from the entrance to the exit

http://www.roguebasin.com/index.php?title=Articles is a gold mine of general game concepts

lol fuck i have 80 open tabs now

"There are many algorithms that will generate a dungeon. What they do is to fill a dungeon
with rooms passages, stairs, traps, doors, items, and monsters, often in that order. Which
comes first can be an interesting decision."

i think i want to do:

stairs first
then caves
then passages
then everything else

http://www.roguebasin.com/index.php?title=Roguelike_Dev_FAQ#How_do_you_make_sure_all_your_rooms_and_passages_are_reachable.3F
explains how floodfill is useful to figure out which rooms are reachable

http://www.roguebasin.com/index.php?title=Basic_BSP_Dungeon_generation
this is a really good explanation

http://roguelikedeveloper.blogspot.com/2007/11/unangband-dungeon-generation-part-one.html lol jesus nine parts
ok it looks like this will be worth reading, gonna come back to part 2

"Cellular Automata Dungeons" is listed on the roguebasin of "things which are hard to code", auspicious

http://www.roguebasin.com/index.php?title=Creating_Measurably_%22Fun%22_Maps
"First connect the dungeon beginning to the dungeon ending. The beginning is generally the
cave entrance or the stairs up or wherever the player begins that dungeon level at. The end
cell is up to you to define. Connect these two cells using DSP and stash the returned path.
Now you have two sets of nodes. Nodes on the path (path nodes) and nodes not on the path
(pointless nodes). The key idea is to "solve" the pointless nodes such that the player either
wants to or has to visit most of those pointless nodes (thereby adding them to the path nodes)."

this is relevant to the gridsagegames concept of "seclusion", which he mainly talks about
in tunneled maps

"There are many ways to "solve" pointless nodes. Before we discuss them, you must group the
pointless nodes into pointless areas. A pointless area is a collection of all pointless nodes
that can reach each other without crossing any path nodes"

http://www.roguebasin.com/index.php?title=Data_structures_for_the_map

http://www.roguebasin.com/index.php?title=Delving_a_connected_cavern
i can't see any of the generated dungeons :( so i am going to ignore this article

http://www.roguebasin.com/index.php?title=Dungeon-Building_Algorithm

http://www.roguebasin.com/index.php?title=Random_Walk_Cave_Generation
mentions that dynamically resizing the map helps make drunkard's walk generation less bad

http://www.roguebasin.com/index.php?title=The_Incredible_Power_of_Dijkstra_Maps
****** this seems potentially relevant (eventually)
"Most of the things a monster will do involve moving toward something or moving away from it."

http://www.roguebasin.com/index.php?title=Programming_Roguelike_Magic
"But once I started adding more spells, a lot of code needed to be unnecessarily duplicated.
For example, a magic missile spell and a icebolt spell do not really differ very much, and
neither do a fireball and a firebolt."

http://www.avanderw.co.za/voronoi-dungeon-generator/
i don't really like the maps this generates, too room-and-corridor for my taste

ok, returning to http://roguelikedeveloper.blogspot.com/2007/11/unangband-dungeon-generation-part-one.html
(i still haven't read the posts on cellular automata that i've had up for days and am planning to use!)

this series is pretty boring tbh
gridsagegames' articles are way better
ok yeah i give up on this series

http://www.gamasutra.com/blogs/AAdonaac/20150903/252889/Procedural_Dungeon_Generation_Algorithm.php
******* SUPER GREAT stuff for room-and-corridor (not relevant here but still cool)

ok i've read every non-cellular-automata tab
so it's time to read those now
my brain is tired though, gonna take a break

========

10/16/16

i actually think i'm going to start first by spinning up a little tool to help visualize
dungeon generation algorithms

i'm planning on using either reagent [i should probably just do this] or some webgl react-y
tool (i think gamma exists but is very new, maybe something else exists too, if none of these
options are compelling then just use reagent) to draw the dungeon generation process on
a web page.

i plan to modify eg drunkards-walk to return {::grid grid, ::active-cells <list of cells
that were actively being visited, in chronological order>}

i haven't looked into cellular automata yet, but from the shape of the generated dungeons
it looks like they might have several cells be visited at the same time, so maybe active-cells
will end up being a list of lists, we'll see. anyway it should be pretty straightforward

and so the visualizer will just draw a grid of squares where filled ones are dark,
empty ones are lighter, and the currently visited cell is green; and there'll be
a button you can press to generate a new dungeon, and (TODO think more about this)
a rewind progress bar feature

https://news.ycombinator.com/item?id=9753897 has gamma videos

wow http://demo.thi.ng/ws-ldn-8/gol/ is pretty sick, i should look through this

https://medium.com/@thi.ng/workshop-report-hi-perf-clojurescript-with-webgl-asm-js-and-emscripten-a545cca083bc#.47xf4fyka
********* GOOD SHIT, RELEVANT TO PERF
is by the guy who made the other webgl library

this looks really relevant to me because it's describing operating on a ton of grid
items / doing neighbor lookups / etc in cljs, which i'm going to be doing all the time

he implements a macro version of get-in that's 5x faster

"The more obvious improvement to speed up the simulation was using a flat 1D vector to encode
the grid and calculate cell indices for the 2D coordinates, much like in a pixel buffer.
This not just gives us better cache locality, but instead of get-in we could now just use
nth, gain a ~6x speed up and somewhat simpler code."
*************************************
yeah i'll probably end up doing this

he uses typed arrays, i haven't looked into that at all

"avoid keywords or collections as functions (use get instead)"
i should look into that - i prefer using collections as functions rather than using get
because i don't like that (get foo bar) doesn't throw an error if foo is nil, but spec
should solve that problem

he talks about how you can use web workers to get more processing power

ok uh anyway i think webgl is overkill for the visualization i have in mind, i'll just use reagent

basic visualization up and running
next up:
animate world generation over time
convert grid to 1d vector (compare drunkard speed before / after)

======

10/17/16

ok, animation works, nice
next up: performance pass
plan:

1. figure out how to accurately time eg 100 executions of drunkard's walk before optimization
2. profile it
implement each of the following items, timing execution before/after to measure speedup
(pending what we find in profiling step)
3. don't call count-empty-cells fn on every pass, just pass a num-empty-cells variable along
    as part of the loop/recur's state
4. convert data structure to 1d grid
5. instead of using a cljs vector of :full :empty keywords, convert to a js array of 0 or 1
   (it can still return a cljs vector of keywords though, just convert to that at the end)
6. look into typed arrays

but first i'm gonna clear my chrome tabs

https://github.com/facundoolano/advenjure

https://facundoolano.wordpress.com/2016/10/16/from-clojure-to-clojurescript/

"I found that some built-ins I used to implement them, like read-string and eval, are not
directly available in ClojureScript, but a bit of googling revealed how to bring them back."

neat info about eval, read-string, saving game state to localstorage

huh, i didn't know that javascript regexes don't support named capture groups
apparently http://xregexp.com/ is a solution

refers to http://www.spacjer.com/blog/2014/09/12/clojurescript-javascript-interop/
(have i read this before?)
******* good shit, great primer on basic js cljs interop

https://github.com/ptaoussanis/tengen

ok cool let's look into benchmarking a clojurescript function

https://github.com/ptaoussanis/tufte potentially relevant
wow this looks _great_
i am going to use this
note: be wary of https://github.com/ptaoussanis/tufte#how-does-tufte-compare-to-hugoduncancriterium though

ok, timing 100 executions of drunkards-walk with 30x30 grid and 150 empty cells
(this first run is taking so long that i'm doing other stuff on my computer while i wait for it,
which is likely going to throw off the benchmark a bit)
results:
{:id :drunkard, :n-calls 100, :min "1.22s", :max "6.5s",
:mad "677.51ms", :mean "2.36s", :time% 100, :time "236.06s"}

ok, now let's profile it in chrome devtools
hm, the output's really noisy if i try to do this:

(let [grid (full-grid 30 30)]
    (js/console.profile "drunkard")
    (dotimes [_ 10]
      (drunkards-walk grid 150))
    (js/console.profileEnd))

lots of schema and figwheel stuff.
gonna turn off instrumentation and try to run this outside of figwheel
oh lol turning off spec instrumentation already immediately makes this _way_ faster, oops
let's benchmark it again before doing anything else

{:id :drunkard, :n-calls 100, :min "158ms", :max "550ms",
:mad "62.19ms", :mean "275.92ms", :time% 100, :time "27.59s"}

ok, 10x faster. so yeah spec instrumentation adds a ton of overhead, gotta remember to turn it off
let's keep going though
trying profiling again

running this directly in js console:
console.profile("drunkard");
for(var i = 0; i < 25; i++) {
    voke.world.generation.drunkards_walk(voke.world.generation.a_grid, 150);
}
console.profileEnd();

haha yeah it looks like 89% of our time is spent in count-empty-spaces
so let's kill that
now we get:

{:id :drunkard, :n-calls 100, :min "7ms", :max "42ms", :mad
"4.14ms", :mean "15.32ms", :time% 100, :time "1.53s"}

so so far that's a 154x speedup, nice
profiling again

looks like we spend a surprising amount of time in rand-nth-weighted
not going to bother optimizing that just yet, unless it turns out that cellular automata need it too
wow and the bulk of the rest of our time is spent in the(into) call that just assembles the
list of directions and weights
so uh ok i'm going to stop here
assoc-in and get-in take 4.94% and 3.8% of our time, respectively
and conjing the cell onto historical active cells takes 3.68%

soooo yeah, that was a pretty easy optimization pass
let's add controls to the visualization UI for width, height, and target empty cells now

lol gonna need to make the css a bit more intelligent
hm i wonder how long generating a 100x100 grid takes
TODO come back and benchmark

ok i'm playing around with sliders
having trouble getting the slider's displayed value to change when its backing atom changes
seems like the <input> tag isn't being rerendered for some reason

lol i forgot to use r/atom

ok anyway now things are looking pretty and interactive
grid generation takes too long for my taste though
so let's do a cleanup pass and then convert to a 1d grid
TODO be sure to benchmark grid generation before+after, and drunkard's before and after

hm ok i actually just benchmarked grid generation and generating a 50x50 grid just takes 37ms, which is ok
i think that the reason that modifying grid width takes so long is that it forces a redraw of every
cell in the grid

so anyway i think i'll put off going to 1d for now
let's look into cellular automata, yeah?

http://pcg.wikidot.com/pcg-algorithm:cellular-automata
example is broken :(
" All state transitions take place at the same time; everything looks at its neighbors and
decides what to change to, then everything changes state at the same time."

"The grid may be of any dimension (e.g. a line or a cube of cells)" interesting

http://www.roguebasin.com/index.php?title=Cellular_Automata_Method_for_Generating_Random_Cave-Like_Levels

so it looks like the variables involved are:
* percentage chance at initialization time that a given cell is a wall
* number of times you run the process
* specific thresholds re: number of your neighbors that are / are not walls at each step of the process

this page says "Very large maps tend to not look as natural, or may require some very fine tuning."
that's a little concerning

this page is pretty great though
it suggests switching rules after a few generations, which is interesting

jlund3's notes on this page re: flood fill / connectedness are great:
"This algorithm creates good looking caves, but the problem is isolated caves. The way I
solved this is by picking a random, open point on the map and flood filling. Any open point
outside the flood filled portion gets turned back into a wall. I then check to see if the
flood filled portion of the map is more than some threshold percent of the map. If the map
is ~45% open it usually looks alright. If the percent is below this, I just start over.
This turns out to work quite well. On large maps, almost always you will select the largest
open connected area, and you won't have to restart the regeneration very often, if at all.
On very small maps, this doesn't happen as often, but its also very quick to regenerate
because the map is small. It ends up that this method just does the right thing to rectify
the non-connected maps naturally!"

i doubt it's that simple, but still looks like good advice

https://gamedevelopment.tutsplus.com/tutorials/generate-random-cave-levels-using-cellular-automata--gamedev-9664
has a handy generator near the top of the page that you can use to try out different parameters

"If you look carefully, flipping the solid and empty blocks makes an island-generator too."
heh cute

this article is actually pretty good
i like that he counts off-map points as being neighbors, makes walls form naturally around
the edges of the map, good stuff

seems like just running the simulation a bunch of times (eg like more than 5 times) makes
for good, rounded cave systems

he suggests placing treasure in places that are surrounded by lots of walls, because they're
usually tucked into corners at the edges of the cave system
anyway i like the article

https://jeremykun.com/2012/07/29/the-cellular-automaton-method-for-cave-generation/

lol:
"The idea of randomized content generation (often called procedural generation) is not particularly
new. It has been around at least since the 1980’s. Back then, computers simply didn’t have
enough space to store large, complex levels in memory. To circumvent this problem, video
game designers simply generated the world as the player moved through it."

"Furthermore, we should note the automaton’s rapid convergence to a stable state. Unlike
Conway’s Game of Life, in practice this automaton almost always converges within 15 steps,
and this author has yet to see any oscillatory patterns."

"There is no overpopulation that causes cells to die off, so once a cell is born it will
always survive. The only cells that do not survive are those that begin isolated. In a sense,
B678/S345678 is designed to prune the sparse areas of the grid, and fill in the dense areas
by patching up holes."

interesting okay fuck awesome great:
he has a solution for using cellular automata on big grids

"Since cellular automata are inherently local manipulations, we should not expect any modification
of B678/S345678 to do this for us. Instead, we will use B678/345678 to create a low-resolution
image, increase its resolution manually, and smooth it out with — you guessed it — another
cellular automaton! We’ll design this automaton specifically for the purpose of smoothing out corners."

interesting - on http://homepages.math.uic.edu/~jkun2/other/cellular-automata/ he suggests
first running the initial ruleset, then *alternating* between increasing the resolution
and running the second ruleset a few times (eg ~4)

seems to work pretty well!

ok let's reread http://www.gridsagegames.com/blog/2014/06/mapgen-cellular-automata/

oh, _i_ see
so this is actually really different from the versions described in all previous articles
those operate on the whole map at once, in stages where every cell is considered and updated
simultaneously, and you run like 2-10 iterations of that whole-map sweep

but in this method, you pick cells at _random_ to consider, one at a time
i didn't get that the first time i read evilscience's article

"One of the variables you can tweak using this method that is not normally adjustable when
using cellular automata is the number of cells randomly visited, which is where some of the
additional variety comes in. Lowering the number of applications will result in some rougher
maps, but a final smoothing phase can still operate on that and get some interesting results"

so yeah we should consider also having a final smoothing phase that uses the traditional
cellular automata approach

cool let's give this a shot

ok gave it a first pass
likely pretty messy and wrong
look at it again tomorrow

gonna do a quick perf pass for funsies actually
ALTHOUGH THIS ALL NEEDS TO BE CLEANED UP AND REFACTORED, READ THIS LINE TOMORROW, DO IT
i just don't have the brainpower for that tonight

currently, (automata 50 50 0.45 500) 100 times ->
{:id :automata, :n-calls 100, :min "36ms", :max "124ms",
:mad "9.9ms", :mean "56.36ms", :time% 100, :time "5.64s"}

let's try with native js arrays

after converting:
{:id :automata, :n-calls 100, :min "25ms", :max "43ms", :mad
"3.49ms", :mean "29.97ms", :time% 100, :time "3s"}

and it looks like there's more room for improvement -
now we spend a *ton* of our time in (apply array (foo bar baz)) calls
is there a way to make js arrays faster than this?
look at that tomorrow
AND REFACTOR ALL OF GENERATION AND VISUALIZATION AND GIVE THINGS BETTER NAMES

converting js array initialization to not use (apply array) brings us to
{:id :automata, :n-calls 100, :min "22ms", :max "128ms",
:mad "7.9ms", :mean "40.07ms", :time% 100, :time "4.01s"}
which seems worse?
anyway kill rand-nth-weighted, reimplement in js

brief notes, might as well take this down:

(defn -make-js-row [width full-probability]
  (let [arr (make-array width)]
    (loop [i 0]
      (when (< i width)
        ; todo nix rand-nth-weighted, implement in plain js (?)
        (aset arr i (rand-nth-weighted {false (- 1 full-probability)
                                        true  full-probability}))
        (recur (inc i))))
    arr))

(defn -make-js-grid [width height full-probability]
  (let [arr (make-array height)]
    (loop [i 0]
      (when (< i height)
        (aset arr i (-make-js-row width full-probability))
        (recur (inc i))))
    arr))


(defn -make-js-row2 [width full-probability]
  (apply array
         (take width
               (repeatedly #(rand-nth-weighted {false (- 1 full-probability)
                                                true  full-probability})))))

(defn -make-js-grid2 [width height full-probability]
  (apply array
         (take height
               (repeatedly #(-make-js-row2 width full-probability)))))

(profile
{}
(dotimes [_ 1000]
  (p :manual
     (-make-js-grid 50 50 0.45))
  (p :apply
     (-make-js-grid2 50 50 0.45))
  )
)

; {:id :apply, :n-calls 1000, :min "10ms", :max "74ms", :mad
; "3.02ms", :mean "14.26ms", :time% 56, :time "14.26s"}
; {:id :manual, :n-calls 1000, :min "8ms", :max "54ms", :mad
; "2.52ms", :mean "11.35ms", :time% 44, :time "11.35s"}

also i poked around on klipse - (for) is definitely much faster than
loop/recur on a handmade array - for returns a lazy / chunked sequence, which is nonzero overhead
loop/recur just makes and modifies an array
it's faster than doseq, too
so favor loop/recur when you need perf

======

10/18/16

http://blog.klipse.tech//klipse/2016/10/16/klipse-is-fast.html

http://blog.klipse.tech/clojurescript/2016/04/09/clojurescript-protocols-secret.html

ok, removed the call to rand-weighted and just used (rand) because that's all we needed, and now:
{:id :manual, :n-calls 1000, :min "0ns", :max "10ms", :mad
"436.97μs", :mean "306μs", :time% 96, :time "306ms"}

so that's pretty fuckin decent!

let's try profiling in the browser again

oh also before i forget
TODO update the visualization of automata such that:
when a cell is visited and is turned into a wall, make it look green
when it's turned into an empty space, make it look red
otherwise don't draw anything on it

ok profiling

array->grid takes 20% of our time
new-value-at-position takes 61% of our time
let's try loop/recur again

ok i did that on a manual js array instead of doing apply array
i didn't benchmark before/after, that was a mistake
but anyway it looks like that was a speedup
now we spend half of our time in the clojure = function, half in array->grid
benchmarking before fixing the = bit:
(calling (automata 50 50 0.45 500) 100 times)

{:id :automata, :n-calls 100, :min "13ms", :max "50ms", :mad
"4.87ms", :mean "21.67ms", :time% 100, :time "2.17s"}

lessons from slack:
set! is javascript =
coercive-= is ==
identical? is ===

after removing cljs eq:
{:id :automata, :n-calls 100, :min "5ms", :max "19ms", :mad
"1.85ms", :mean "8.01ms", :time% 99, :time "801ms"}

ah, found another = call, now we get:

{:id :automata, :n-calls 100, :min "4ms", :max "12ms", :mad
"997μs", :mean "6.05ms", :time% 100, :time "605ms"}

ok, now array->grid takes 66% of our time

poked at it with help from david and alex in slack.
before:

(into []
    (for [row an-array]
      (into []
            (for [full? row]
              (if full? :full :empty)))))

after:

(into []
        (map (fn [row]
               (into []
                     (map (fn [cell]
                            (if (true? cell) :full :empty)))
                     row)))
        an-array)

so now we get:
{:id :automata, :n-calls 100, :min "1ms", :max "18ms", :mad
"1.94ms", :mean "3.58ms", :time% 96, :time "358ms"}

and array->grid is about 30% of our time.
i think this is about as fast as we'd ever want this to be for now, stopping here. nice!

http://blog.fikesfarm.com/posts/2015-11-03-planck-static-function-dispatch.html
http://blog.fikesfarm.com/posts/2016-04-14-static-free-clojurescript-repl.html

cool seems like i can just leave this off in dev

s3b4 looks interesting

eh, having trouble focusing, think i might just take a break for the rest of the day
TODO:
smoothing phase
look at http://www.evilscience.co.uk/wp-content/uploads/2014/02/app.png
and http://www.evilscience.co.uk/a-c-algorithm-to-build-roguelike-cave-systems-part-1/ again

=======

10/19/16

plans for today:
add support for a smoothing phase; can be super-simple/dumb at first, can be fleshed out later.
  will reuse lots of logic from the current automata function.
  time to think harder about names again, i've really been letting that slide so far

OH ALSO LOOK INTO FLOOD FILL AND FIGURE OUT WHEN TO USE IT
also need to do some thinking about how to connect caves together, and which ones to fill in, etc

make the UI a little easier for people who aren't me to understand
make the whole thing redraw whenever any of the automata-specific sliders are touched
add animation support to the automata visualization, and add a slider that lets you determine
  how many cells are animated per frame (eg 1, 5, 10, etc)
add support for a history slider (TODO think more about how this will work, best way of integrating with UI)

but first, let's finally work through austin's devs tutorial

except actually first let's go eat some dim sum
delicious
ok, devs time

https://github.com/austinhaas/DEVS/blob/master/doc/tutorial.clj
aw dang he wants me to work through this interactively
okok one sec

ok, that was interesting
not 100% sure what to make of it
super well-done/formatted tutorial though!

http://www.onyxplatform.org/learn/
https://www.youtube.com/watch?v=YlfA8hFs2HY
talks about difference between batch and streaming
batch is relatively well-understood, streaming less so
in streaming, it's very possible you can never see the whole data set because it's infinite or
very large/long-lived (eg all tweets)
and so while in batch land can be just stateless immutable transformations of data, in streaming
land you have to keep state
makes sense

i don't understand much of what he says starting around minute 9
i wish he used simpler words
i think he practiced this too much

he casually mentions https://github.com/stuartsierra/dependency - this looks really really useful!

anyway it looks like the upshot is that onyx is a useful tool for processing streaming data in clojure
apparently it does batch too

ok anyway back to the tool
playing around with the different variables - initial chance, survival threshold, birth threshold, iterations
0.45 s3 b4 iter10000 is looking pretty good!

https://www.evernote.com/shard/s11/sh/4766f63d-d93a-4d37-9e36-9d008e60faed/633ce93e72c0fc9c
^ iter40000 there
s3 b4 definitely look like the right thresholds, iter40000 looks good too
although there's an interesting relationship between grid size and desired # iterations
i don't fully understand it yet but it seems like the larger the grid, the more iterations
you need in order to hollow out the right amount of space
which makes sense, there are more cells you need to visit, so you need more random iterations

let's take a look at the smoothing phase, maybe that'll help a lot actually

started cleaning up in preparation for smoothing phase
i kinda wanna do another perf pass though
measuring 200 invocations of (automata 100 100 0.45 3 4 20000 nil)

{:id :automata, :n-calls 200, :min "41ms", :max "215ms",
:mad "13.99ms", :mean "65.36ms", :time% 100, :time "13.07s"}

NOTE we spend 27% of our time in the garbage collector
10% of our time in conj
7% of our time in =
5% of our time in array->grid
35% of our time in -new-value-at-position
which says it spends 28% (of the whole bucket of 100%) in "self time"
and 5% in -get-neighbors

so i guess the first step is to figure out why we're doing so much gc and fix that

i'm gonna do a prod build real quick to see what the profiles there look like
yeah, on prod we spend 35% of our time in GC

http://rundis.github.io/blog/2015/clojurescript_performance_tuning.html

"A couple of function showed a lot of own-time in the profiler. I really couldn’t figure
out why though. They didn’t seem to do much, but delegate to other functions. I tried a range
of things until I stumbled accross this blogpost by Stuart Sierra."
links to https://stuartsierra.com/2015/06/01/clojure-donts-optional-arguments-with-varargs
not relevant to me though

googling around for info on js gc issues

https://www.alexkras.com/simple-guide-to-finding-a-javascript-memory-leak-in-node-js/ is
probably not relevant since i don't think i have a _leak_, but whatever, i'll read this

"There are 4 types of data types in JavaScript: Boolean, String, Number, and Object. First
3 are simple types, and they can only hold on to the data that is assigned to them (i.e.
string of text). Objects, and everything else in JavaScript is an object (i.e. Arrays are
Objects), can keep references (pointers) to other objects."

heh here's what my timeline looks like, note the blue memory graph:
https://www.evernote.com/shard/s11/sh/f10c0c33-5bea-42e6-81cb-0d1912b0a8c6/a17df90c6da1cc8b

oh fuck nice - the timeline view lets me do this:
https://www.evernote.com/shard/s11/sh/edc9be6e-d8f7-4182-af0a-9ce23cc226d6/b4aa93fe109daef9
i always thought bottom-up view was worthless but now i see what it's for, nice
or anyway i think i do

oh wow, the profile tab has several awesome things i didn't know about
heap snapshot
allocation timeline
allocation profile

let's try them out, shall we

the allocation profile one indicates that it basically all comes from array->grid?
https://www.evernote.com/l/AAuZTK7NlexG_bP6qP1lR1yJoJ7DY2CsSWg
TODO LOOK INTO THIS

https://docs.google.com/presentation/d/1wUVmf78gG-ra5aOxvTfYdiLkdGaR9OhXRnOlIcEmu2s/pub?start=false&loop=false&delayms=3000&slide=id.g31ec7af_0_29
has info on leaks

=======

10/20/16

https://hacks.mozilla.org/2012/11/tracking-down-memory-leaks-in-node-js-a-node-js-holiday-season/

TODO try just removing the array->grid calls and see what that does to perf (and to reported gc)

{:id :automata, :n-calls 200, :min "47ms", :max "183ms",
:mad "22.04ms", :mean "90.39ms", :time% 100, :time "18.08s"}

shaved a little time off, not much though

gc-wise, it now says 48% of our allocations are in COMPILER (?) and 52% in new-value-at-position
and lo and behold, our memory allocation looks much less insane when graphed:
https://www.evernote.com/l/AAvSfj1nfOdFa7pNTiBepKtqIRwfquegx_M

{:id :automata, :n-calls 200, :min "36ms", :max "126ms",
:mad "11.13ms", :mean "56.32ms", :time% 100, :time "11.26s"}

so yeah, it definitely looks like there's something going on here
wonder if it's fixable?

=====

10/23/16

https://www.youtube.com/watch?v=L3ugr9BJqIs

good stuff. good explanation of the 3-snapshot technique, i didn't realize that the whole point
was about "allocations between snapshot 1 and 2 _that are still around in snapshot 3_".

i talked with dnolen on slack yesterday re: the allocations i'm seeing; he wasn't surprised, since my
code isn't doing all that much work otherwise. i still think it'd be good+fun to look into using
chrome devtools, just for fun.

things to look into using:
containment view
dominators view

i poked around in the memory view, this time manipulating the cellular automata vis's sliders manually
instead of calling automata in a loop, and this time the memory allocation profile said that we do
all our allocations in reagent/react, by making a ton of react elements. this probably makes a lot of sense
- i don't think react+reagent were made with this use case in mind.
seems like an acceptable limitation to live with since this is just a visualization tool -
we'll just have to keep the grid sizes relatively low in situations where the vis has interactive
sliders and so its parameters can change very frequently.

i think we should still be able to get away with generating+visualizing really big grids in this tool
as long as they're just kicked off by a big "generate" button.

so i think this tool's headers/tabs will eventually look like:

drunkard's | cellular | tunneler | foo | voke dungeon generation

where the first N-1 tabs have lots of sliders and let you visualize how these things work
on a smaller grid, and the last one just has a "generate" button and generates a big 400x400 (or
whatever) map

ok, smoothing seems to be working
gonna do another perf pass
one behavior note - lots of empty spots along edges of the grid, should add another pass that fills 'em in
by hand
eh, ignore the perf pass bit, turns out adding a console.log call to each iteration of the
smoothing pass function slowed us down a lot, but now that that's removed most of the overhead
appears to be in react/reagent

if that's the case, and the last tab of the visualization tool won't have sliders of any sort,
then i should just have it write to a canvas directly
this way it can write to a nice big huge grid
i might give that a shot right now tbh

ok, nice, did that
profiling yet again
we spend the vast majority of our time in automata-smoothing-pass, which is to be expected
also, i should definitely bump up the number of random-cell iterations pre smoothing, i'll do that first
did that, not sure if it makes a difference? i miss sliders :/
gonna try a prod build and profile that if i can

ok i have a profile here
before i try something - i think if i replace an = or two in smoothing-pass with identical?, we'll save
20% of our time - i need to get some benchmark timings
based on (automata 400 400 0.45 4 5 400000 12)

calling that 10 times yields:
{:id :big-grid, :n-calls 10, :min "4s", :max "5.5s", :mad
"510.8ms", :mean "4.69s", :time% 100, :time "46.9s"}

now let's try identical?

{:id :big-grid, :n-calls 10, :min "2.96s", :max "3.55s",
:mad "124ms", :mean "3.18s", :time% 100, :time "31.84s"}

niiiiice

ok, now it's down to new-value-at-position

is there anything we can do to make this function faster?

it spends 6% of our time in get-neighbors, and 35% of our time in new-value-at-position "self time"
let's research terms like "js profiling self time" to see if there are any tips on how to diagnose this

yeah not really
the only thing that's jumping out at me is this bit:
(.-length (.filter neighbors true?))
let's have neighbors just return the number of full neighbors directly

hm, have i made this somehow.. slower?
{:id :big-grid, :n-calls 10, :min "4.45s", :max "5.01s",
:mad "132.38ms", :mean "4.63s", :time% 100, :time "46.28s"}
yeah this is worse. what gives? profile time

oh, i think that this completely fucked up timings, interesting:
[new-i new-j] (if (identical? i (inc x))
                            [(dec x) (inc j)]
                            [(inc i) j])
because end up constructing and calling nth on a cljs persistent vector a jillion times in a tight loop
so: don't do unpacking like this in a tight loop!

niiiice, now we're down to this:
{:id :big-grid, :n-calls 10, :min "1.44s", :max "2.29s",
:mad "222.74ms", :mean "1.71s", :time% 100, :time "17.06s"}

so we're down from mean time 4.69 to mean time 1.71s (although we're only doing 10 iterations)
but anyway it definitely looks like we've at least made this 2x faster
so that's cool!
new-value-at-position now only has 6% self time
num-full-neighbors is where most of the self time lives now, which makes sense
20% in the garbage collector, though! TODO: take a look at allocation profiles again

i had a few ideas while i was walking around today, and i'm going to try to write them down
before i forget them all (i may have already forgotten a few)

* switch all grid drawing in the visualization tool from reagent to canvas
    reagent is great for controlling UI, but it isn't made for turning a grid of 16000 divs on and off
    TODO record fps before/after this change
* some rejiggering of the various r/atoms will be necessary - figure out how to add a watch to all of them
    that checks what tab is selected and redraws the canvas accordingly
* remove the width/height sliders, just set those values to 100 and tune cell size to match
* in order to better understand the effect of the various sliders, make it such that when they are
    manipulated, the _same_ dungeon is redrawn - do this by sending along a seed for the random number
    generator in these situations. in this way it will be more obvious what the effects of eg
    greater or fewer random-cell iterations, or greater or fewer applications of the smoothing stage, etc
    actually have on the generated level.
* when grids are generated, just draw the finished product on the screen immediately;
    make a second "animate" button available that the user can click to animate the current grid's history

i think that's everything!
also at some point we'll probably want to read kyzrati's post on tunnelers, and implement that strategy
and maybe even the BSP room-generation technique, and/or a combination thereof, just for fun

also, TODO - the current algorithm generates a map that's pretty to look at and has nice big open-space caves,
but has no sense of direction in it - you're not at all guidedfrom the start to the end. will have
to come back and think more about this. kyzrati hints at forcing your caves to fit into a more vertical
slice, which i think could help a lot

current timeline stats with reagent vis indicate frames taking about 400-600 ms when you drag
sliders around on the automata visualization, let's try converting to canvas now

switched to canvas, frames now take about 60-90ms, and that's with a bigger grid and with
a ton of smoothing passes (eg 12) applied. nice!

now that this is so much more responsive, i *really* want to get that random seed feature described above in,
but i should finish converting the whole thing to canvas (i.e. drunkards, setting aside animation for now)

TODO doesn't look like it's possible to pick a seed in JS - look at http://stackoverflow.com/questions/521295/javascript-random-seeds
https://github.com/clojure/test.check/blob/ebcc57dd631e25ee39bc059899e3bbd9ddf24ee9/src/main/clojure/clojure/test/check/random.cljs
looks promising

=====

10/24/16

quick rng notes before i forget
https://github.com/clojure/test.check/blob/ebcc57dd631e25ee39bc059899e3bbd9ddf24ee9/src/main/clojure/clojure/test/check/random.cljs
seems to come with a seedable rng
testing it against (rand) yields:
{:id :new, :n-calls 1000000, :min "0ns", :max "12ms", :mad
"4.45μs", :mean "2.23μs", :time% 31, :time "2.23s"}
{:id :regular, :n-calls 1000000, :min "0ns", :max "2ms",
:mad "1.3μs", :mean "648ns", :time% 9, :time "648ms"}

so it's definitely slower than the builtin rng, but not slow enough to matter afaict

saw this fly by on slack: argument about component vs mount
yogthos likes mount, everyone else likes component and is mad at him (?)
https://www.reddit.com/r/Clojure/comments/41p73n/contrasting_component_and_mount/
https://www.reddit.com/r/Clojure/comments/3zppdn/the_beauty_of_clojure/

implicit vs explicit comes up a long in this argument
mount implicit, component explicit
i like explicit tbh

yogthos says:
I find that keeping resources at the edges makes things more
testable, whether you pass resources as an argument or reference
a var, you’re still tying them to your business logic
I would argue that if you need resources for most of the testing, then there’s too much coupling going on

poking at seeding now
http://davidbau.com/archives/2010/01/30/random_seeds_coded_hints_and_quintillions.html#more
looks pretty useful

ok things are looking pretty sweet atm
TODO - kill the whole :history thing, no longer needed
measure performance before/after

ok, let's measure the current state of performance + memory usage

calling this 200 times:
(automata 100 100 0.45 3 4 20000 12 4 5)
{:id :automata, :n-calls 200, :min "66ms", :max "155ms",
:mad "10.13ms", :mean "85.79ms", :time% 100, :time "17.16s"}

memory-wise, looks like we just allocate 67k from array->grid, which seems low+fine

anyway now let's remove all history/etc code
ok, done (i think, haven't reread the whole thing but it seems to run)
now we have:

{:id :automata, :n-calls 200, :min "43ms", :max "123ms",
:mad "5.95ms", :mean "53.67ms", :time% 100, :time "10.73s"}

noticeable speedup! about 60% of the time it used to take

profiling now
we spend 12% of our time in rand-int (definitely due to the slower seeded rng implementation)
16% self time in new-value-at-position
40% self time in num-full-neighbors

oh wow, i never noticed this before - the chrome profiling tool has "focus this function"
and "exclude this function" buttons, which seem very useful

anyway that seems to be the whole story - those two functions are where the remaining time is spent

interesting - the truth_ call i also see us spending some time in (about 7% self time)
is what's emitted when you call (and foo bar)
(thanks klipse!)
i wonder if there's a way to restructure this cond for performance?

blog.fikesfarm.com/posts/2015-12-04-boolean-type-hints-in-clojurescript.html
seems very relevant!!!!!

ok! with the help of that url and klipse, i've got:

(let [foo (get [true] 0)]
  (if foo 1 2))

emits a truth_ call

(let [foo ^boolean (get [true] 0)]
  (if foo 1 2))

does *not* emit a truth_ call
let's try this out!

huh - it doesn't seem to affect perf at all, according to tufte!
without hint:
{:id :automata, :n-calls 400, :min "43ms", :max "100ms",
:mad "5.71ms", :mean "54.44ms", :time% 100, :time "21.78s"}
with hint:
{:id :automata, :n-calls 400, :min "43ms", :max "106ms",
:mad "6.06ms", :mean "53.99ms", :time% 100, :time "21.6s"}

let's look at chrome profiler

hm, in chrome profiler i still see 7% of our time spent in truth_!
i'm misunderstanding something - i think that this (and) call may be throwing a spanner in the works
TODO continue to investigate

words for grep: BLOG STUFF BLOG NOTES
jotting down ideas i had on the plane:
eventually make the visualization tool into a blogpost
left sidebar, right main content area with the grid in it
add some explanation/narrative about the different algorithms
include sliders inline with the prose
right hand side has grid and generate-another button
when we get to cellular, explain each phase one at a time, including like 1-3 sliders inline with each phase
so the reader can play with them
then at the end, draw all the sliders again in a master control box
so the reader can play with the whole shebang
it's fine to have two copies of each slider because reagent
maybe include a reset button in this box that puts the sliders back to their defaults or something

also have a separate post where we talk about perf investigations
talk about how klipse was useful for seeing emitted js
loop/recur on a mutable js array much faster than eg (for)
right syntax for using (into) - (into [] xform coll) instead of (into [] (xform coll))
any other perf notes that can be scrounged from the past two week's worth of dev-diary entries

also write a post about keeping a dev diary

=======

10/25/16

spun up a github-pages repo, added the above blog post ideas to it as github issues

let's get back to figuring out what's going on with this code:

(defn -new-value-at-position
  [js-grid x y w h survival-threshold birth-threshold]
  (let [cell-is-full? (-> js-grid
                          (aget y)
                          (aget x))
        num-full-neighbors (-num-full-neighbors js-grid x y w h)]
    ; TODO think more about how this cond is structured
    ; play with klipse to see exactly when truth_ is emitted
    (cond
      (and cell-is-full?
           (>= num-full-neighbors survival-threshold)) true
      (and (not cell-is-full?)
           (>= num-full-neighbors birth-threshold)) true
      :else false)))

profiler says that we're spending a noticeable amount of time in truth_
which, again, is documented here: blog.fikesfarm.com/posts/2015-12-04-boolean-type-hints-in-clojurescript.html

had a hard time coming up with something that worked, but this does:

(defn -new-value-at-position-inner [^boolean cell-was-full ^boolean meets-survival-threshold ^boolean meets-birth-treshold]
  (or
    (and cell-was-full meets-survival-threshold)
    (and (not cell-was-full) meets-birth-treshold)))

(defn -new-value-at-position
  [js-grid x y w h survival-threshold birth-threshold]
  (let [cell-is-full? (-> js-grid
                          (aget y)
                          (aget x))
        num-full-neighbors (-num-full-neighbors js-grid x y w h)]
    (-new-value-at-position-inner cell-is-full?
                                  (>= num-full-neighbors survival-threshold)
                                  (>= num-full-neighbors birth-threshold))))

wow, this really seems to do the trick:
{:id :automata, :n-calls 400, :min "33ms", :max "65ms", :mad
"4.8ms", :mean "41.16ms", :time% 100, :time "16.46s"}

let's try it again the way it was before:

yeah, _wow_!
{:id :automata, :n-calls 400, :min "43ms", :max "111ms",
:mad "7.24ms", :mean "53.04ms", :time% 100, :time "21.22s"}

noticeable difference! shaved off about 20%!

profiling indicates we still emit a truth_ in num-full-neighbors, let's see

====

10/26/16

got rid of all the truth_s, everything's fast enough for now
poking around at jekyll/blog stuff now
going to keep notes in here even though this is a different repo, oh well

https://www.taniarascia.com/make-a-static-website-with-jekyll/
has good (very specific) info on setting up + theming a new jekyll install

i don't understand what the deal is with bundle exec
https://github.com/jekyll/jekyll-help/issues/225
bundler.io/rationale.html

"This is important: the Gemfile.lock makes your application a single
package of both your own code and the third-party code it ran the last
time you know for sure that everything worked. Specifying exact versions
@of the third-party code you depend on in your Gemfile would not provide
the same guarantee, because gems usually declare a range of versions
for their dependencies."

still looking around for reasons why jekyll / github pages might be a bad idea
as far as i can tell, these are the only cons:
* you can only blog from your laptop, can't do it from phones / internet cafes / whatever
    (partially addressed by the github web edit UI, also i don't care about this)
* big jekyll blogs with lots of posts can take a long time to build
    there's an incremental build feature that fixes this

that seems to be about it. seems like a safe bet, i'm the target demographic

looking at jekyll themes now
https://jekyllthemes.io/ is a decent list
i like:
https://jekyllthemes.io/theme/15489219/lanyon
https://github.com/poole/lanyon

i'll probably go with this one
looking at others just in case
yeah, all the others look like butt, and lanyon is _really_ good
gonna use it

https://help.github.com/articles/adding-a-jekyll-theme-to-your-github-pages-site/
that page is dumb
i think the idea is to just clone the theme repo

cool, done

pondering converting my old core.logic post to jekyll blog
and making the code snippets interactive via klipse
i think core.logic needs to be "bootstrap"/"self-host" compatible for that to happen
and i don't think that it is yet
questions:
what does bootstrap-compatible mean?
http://blog.klipse.tech/klipse/2016/10/16/klipse-is-fast.html seems to indicate that i can
still use core.logic in klipse, but that it's slower to start up - is this true?

on the first:
http://blog.fikesfarm.com/posts/2015-07-17-what-is-bootstrapped-clojurescript.html
https://anmonteiro.com/2016/08/om-next-and-bootstrapped-clojurescript/
https://github.com/omcljs/om/pull/752/files

=====

10/27/16

ok, looking into doing a simple blog post on that first-pass drunkards implementation
i'd like to have like six snippets, and each has a canvas that it writes to,
but i want the code to look like (draw-grid a-grid) every time, not (draw-grid a-grid :canvas-1)
viebel suggests adding a data-pre-run feature to klipse snippets that does eg (reset! canvas-id :canvas-1)
and that sounds pretty reasonable to me. so i guess i get to learn how to develop klipse now

i also need to finish reading the jekyll docs

re: voke and maps, i think we're at a good stopping point at the moment - i eventually want
to get maps to be more directed (kyzrati talks about this in
http://www.gridsagegames.com/blog/2014/06/mapgen-cellular-automata/ and
http://www.gridsagegames.com/blog/2014/07/dungeon-metrics/ )
but there's no reason to focus on that when i'm not yet at a point where i can even actually
_play_ these maps - let's focus on that first.

also need to figure out a way to merge this branch into voke master. i think that for now
a hack is totally okay - just have a check in the game loop's input handling that checks for
the letter 'v', and kills the game and displays the tool when it detects a v keypress.
we can have menus/etc later, no need to do them yet.

interesting note in https://jekyllrb.com/docs/configuration/ about incremental regeneration:
"Under the current implementation, incremental regeneration will only generate a document
or page if either it, or one of its dependencies, is modified. Currently, the only types
of dependencies tracked are includes (using the {% include %} tag) and layouts. This means
that plain references to other documents (for example, the common case of iterating over
site.posts in a post listings page) will not be detected as a dependency.
To remedy some of these shortfalls, putting regenerate: true in the front-matter of a document
will force Jekyll to regenerate it regardless of whether it has been modified. Note that
this will generate the specified document only; references to other documents’ contents
will not work since they won’t be re-rendered."

https://jekyllrb.com/docs/templates/#post-url
is handy for linking to other posts

drafts are easy to work with, just make a file like _drafts/foo-bar.md and run jekyll serve
with the --drafts option

there's a gist tag built into jekyll, eg
{% gist parkr/931c1c8d465a04042403 %}
that's neat
(does github pages support this?)

oh shit, permalink styles in https://jekyllrb.com/docs/permalinks/
i can just say 'none' to not have the date in my urls
nice

ok now i'm just trying to understand the significance of the gh-pages gem and after that
i'll actually poke around and try to write this thing

=======

10/28/16

blog post is mostly written, just a few loose ends to tie up

reading through all the eve stuff now
eve looks neat
i don't have strong feelings on the pros/cons of literate programming but the rest of eve looks cool

ah, brief blog idea to ease my mind on what stuff'll look like on prod:
scp it up to jrheard.com/blog_staging/
and block off that directory via robots.txt

coooool, blog post is ready to go, i'll post it monday morning.
next up:
get generation branch in a shape where it's ready to merge back into master
just make it so that if you hit v in the regular voke game, the game is thrown away
and we draw the visualization tool instead
punt on menus/pause/etc for now
maybe a `mode` atom so that we don't mess up on figwheel reloads

http://www.squidi.net/three/entry.php?id=4
nice, makes sense. good illustrations

http://www.squidi.net/three/index.php lol jesus christ

http://www.squidi.net/three/entry.php?id=158
replicate teeth

http://www.squidi.net/three/entry.php?id=163
"I take the position that it is better to make a few smart decisions than lucking into success
through a billion dumb ones. Since memory is cheap, we can keep track of a lot of information
that will allow us to make smart decisions quickly. This procedural generation entry is about
taking an oddly shaped zone and filling it in with a workable set of multi-room regions without
guessing and testing."

useful strategy for plopping prefab rooms into a prefab zone layout

http://www.squidi.net/three/entry.php?id=164 neat for tile game zone generation

http://www.squidi.net/three/entry.php?id=201
issues with scaling low-resolution things

http://www.squidi.net/three/entry.php?id=202
****** come back to this guy's stuff if i ever want to think more about prefabs
"I'm largely against the idea of procedurally generated content being an effort of guess
and test. It drives me nuts that the current procedural generation environment is either
guess and test or literally trying to find mountains in white noise. I spend a lot of my
effort trying to devise ways in which you can get the results you want the first time. But
computers are fast enough that the old guess and test approach could end up being quicker,
conceptually simpler, and produce acceptable results with less code."

this guy really likes prefabs

"The benefit of using a stack instead of just starting over every time is that it ultimately
creates a search through the available spaces. It may be that there's only two or three configurations
that work, and you could randomly try to place the tree a thousand times without finding
those few solutions, and wasting untold effort for little result. However, the stack works
as sort of a controlled flood-fill, filling in the spaces as best as it can, and backing
up when it hits a wall to try again."

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.703.368&rep=rep1&type=pdf
ha!
they have this to say about cellular automata:
"The small number of parameters, and the fact that they
are relatively intuitive is an asset of this approach. However,
this is also one of the downsides of the method: it is hard
to fully understand the impact that a single parameter has on
the generation process, since each parameter affects multiple
features of the generated maps. It is not possible to create a
map that has specific requirements, like a number of rooms
with a certain connectivity. Therefore, gameplay features are
somewhat disjoint from these control parameters. Any link
between this generation method and gameplay features would
have to be carried out through a process of trial and error."

i should link to this paper when i publish my visualization tool :)

======

10/29/16

played around with the blogpost a bit more - embedded the drunkard's portion of the vis tool.
i think it's fine now and i should stop messing with it.
back to this academic article.

it's talking about genetic algorithms now, that's interesting
strings and fitness functions
sounds a lot like just brute force / breadth-first-search, except with a little guiding function
that tries to get you to a satisfactory solution without having to exhaust the entire space
of checking every single possible permutation of the solutions available
a* is a lot like that too i think - it's about getting a good answer in a performant way
interesting

they describe a few favorite fitness functions:

"• F1 - maximize path length from entrance to exit;
 • F2 - maximize accessibility of checkpoints;
 • F3 - ”encourage paths to branch, run over checkpoints,
 and then meet up again later”."

"The genetic algorithm parameters mostly control how well
 (and how fast) the solution reaches an acceptable result based
 on the fitness, including the possibility of reaching local optima.
 The main problem with these genetic algorithm parameters
 is their apparent mismatch with backtracking: if a certain
 result is obtained and needs to be adjusted, it is unclear which
 parameters need to be altered."

 "Sentient Sketchbook is a tool proposed by Liapis et al. [25],
  aiming at supporting designers during the creation of game
  levels. Game designers sketch low resolution maps, where
  tiles represent passable or impassable sections, player bases
  and resources. Sentient Sketchbook is able to add detail to the
  coarse map sketch and test maps for playability, navigable
  paths, game pace and player balance. Dungeons are one of the
  available possible results of automatically detailing coarse map
  sketches into final level maps. Tiles are converted into rooms,
  dead ends and corridors."

interesting idea - middle ground between handmade levels and completely generated levels

design the stuff you really care about by hand, automate all the other stuff away
neato

"However, it is still unclear how low-resolution sketching and genetic-based
 generation (steered by this sketching) would scale to larger
 and more detailed maps."

on constraints:
"It is still up to the designer to not only create all the prefabs for level geometry sections
 and objects, but also to express a meaningful set of constraints
 for the generator. It is not straightforward for a designer to
 translate gameplay concepts (like pacing or difficulty) into
 topology, adjacency, etc."

toward the end of the paper there's a TABLE I section that's really great

"Cellular automata and constraintbased
 approaches use a straightforward control mechanism
 over their algorithm’s low level parameters, thus requiring a
 full understanding of the generation process. For designers
 to control them in a meaningfully way, they always need to
 explicitly map that understanding to gameplay-related goals
 (e.g. how does room adjacency better support the designed
 mission)."
 ****** QUOTE THIS

end of article.
the grammars idea is interesting - not relevant for voke, but good idea for room-based RPGs
wonder how fun it would actually be though
interesting stuff

ok now i think i'm going to read every blog post bob nystrom has ever written

http://journal.stuffwithstuff.com/2010/11/26/the-biology-of-sloppy-code/
reminiscent of programmer-archaeologists in vernor vinge books

http://journal.stuffwithstuff.com/2013/01/13/iteration-inside-and-out/
discusses call stack

http://journal.stuffwithstuff.com/2013/04/17/well-done/
i like how this guy writes
describes CSP here

http://journal.stuffwithstuff.com/2013/08/26/what-is-open-recursion/
really great writing in this one
"The problem is that the definitions of the functions come one after the other. What you
really want is to define them all in one lump where they can all see each other simultaneously.
 In functional languages, the name for that “lump” is a “mutually recursive definition”. "

http://journal.stuffwithstuff.com/2013/12/08/babys-first-garbage-collector/
******* i love this article

http://journal.stuffwithstuff.com/2014/04/22/zero-to-95688-how-i-wrote-game-programming-patterns/
deferring editing for later rounds of revision is definitely a good idea and something
i think i should focus more on

"I read the entire chapter out loud. I can’t stress enough how helpful it is. You can read
something ten times and think it’s fine but the first time you run it through your lips you’ll
find all of the wrinkles. This fixes awkward repetition and bad cadence. If the prose reads
naturally and easily, that’s not because it was easy and natural to write. It’s because I
edited the hell out of it."
******* this is a good idea

"Now, if this was a movie, this is when the eighties instrumental rock would start and the
montage would kick in. Before you know it, the book would be done
 But, I tell you what, I lived that montage, and it did not pass quickly. Working on this
 damned book was a pain in the ass every single day. "

yeah i don't ever want to write a book

http://journal.stuffwithstuff.com/2014/07/05/dropping-loot/

"Instead of sequences of items, I now have a hierarchy of them. So, for example, a stilleto is:
equipment/weapon/dagger/Stilleto
I’m not generally a fan of hierarchies but I found it surprisingly easy to lump almost every
item into one. Items also have a “level”, which describes their relative value. Higher level stuff is better."

interesting
will have to remember this idea

http://journal.stuffwithstuff.com/2014/07/15/a-turn-based-game-loop/
interesting that he has a bunch of actors rather than going with strict entity/component/system
he seems to be super into OOP so i guess i shouldn't be surprised

interesting bit about actions succeeding/failing
more interesting bit about proposing an alternate action on failure
i like that a lot ********

good stuff in this post

http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/
is this about inheritance?
or IO/impurity in haskell?
ah, async

http://journal.stuffwithstuff.com/2015/09/08/the-hardest-program-ive-ever-written/
i continue to be really impressed by this guy's writing style

http://journal.stuffwithstuff.com/2016/06/16/long-names-are-long/
simple guidelines on naming (no redunandcy, etc)

=====

10/30/16

http://journal.stuffwithstuff.com/2015/09/07/what-the-hero-sees/
post on fov
interesting bit about octants / triangles / etc
the examples in this article are all fucked up :/
meh

http://journal.stuffwithstuff.com/2014/12/21/rooms-and-mazes/
"People get into procedural generation because it seems easier."
places rooms randomly, certain number of attempts before giving up
talks about sparseness / eliminating dead ends
"Doing that is actually pretty easy. A dead end is just a tile that has walls on three sides.
When you find one of those, you fill that tile back in. That may in turn make the tile it
connects to a dead end. Keep doing this until you run out of dead ends and you’ll end up
with lots of solid area where rooms can be placed."

"a maze generator is a randomized flood fill algorithm."

"If we use all of the connectors, our dungeon would be way too densely connected. Instead,
we carve through just the connectors we need to get each region connected to the whole once.
In fancy terms, we’re finding a spanning tree."

interesting that it becomes really really easy to remove all of the dead ends in the maze
once the rest of the work is done in his algorithm

i'm kinda tempted to implement his algorithm just for funsies, it looks like a good time
wouldn't be relevant for my game tho, makes more sense for 2d grid roguelikes

http://ctrl500.com/tech/handcrafted-feel-dungeon-generation-unexplored-explores-cyclic-dungeon-generation/
ok this ctrl500 website/magazine just totally 100% blows
the content is bad and poorly written
oh well

well, http://ctrl500.com/tech/teaching-the-ai-to-find-a-path-in-awesomenauts/ isn't as bad
interesting re: local solver + global solver
" For finding the global route towards the goal we used path finding nodes and standard A*
to figure out which route to take over them. The nodes are spaced relatively far from each
other and the local solver figures out how to get to the next node."
also interesting that they can use a* - their game takes place in continuous space, not discrete
i guess they just artificially split it up into discrete space for pathfinding purposes
makes sense, i'll probably do the same

oh uh
"How do we generate the nodes and edges that A* needs to find a route from A to B? The answer
is quite simple: our designers place them by hand. Awesomenauts has only five levels and
a level needs well below one hundred path finding nodes, so this is quite doable."

wellllll
i thought they generated these but i guess they do it by hand
i'll generate it though

ok cool anyway
i think i should really get around to merging this generation branch into master
let's take a look at that

cool, ezpz

http://pcgbook.com/

"A content generation problem might be to generate new grass with
 a low level of detail which does not look completely weird within 50 milliseconds."

http://pcgbook.com/wp-content/uploads/chapter02.pdf

"In search-based procedural
 content generation, an evolutionary algorithm or some other stochastic search/optimisation
 algorithm is used to search for content with the desired qualities. The
 basic metaphor is that of design as a search process: a good enough solution to the
 design problem exists within some space of solutions, and if we keep iterating and
 tweaking one or many possible solutions, keeping those changes which make the
 solution(s) better and discarding those that are harmful, we will eventually arrive
 at the desired solution."

"Crafting an evaluation function that reliably measures the aspect of game quality that it is
 meant to measure is often among the hardest tasks in developing a search-based
 PCG method."

the guys in that short paper from yesterday said something very similar about fitness
functions in genetic algorithms

oh hey lol it looks like they're talking about the exact same thing, just calling it search
at least in the evolutionary search section

god this is boring

the writing is pretty clear though

"It could be argued that an evolutionary algorithm is “overkill” for some content generation
 problems. If your search space is very small and/or you have lots of time at
 hand to produce your content, you could try an exhaustive search algorithm that
 simply iterates through all possible configurations. In other cases, when it is easy to
 find good solutions and it is more important to maintain high diversity in the generated
 content, random search—simply sampling random points in the search space—
 could work well. Even when using exhaustive or random search the content needs
 to be represented in such a way that the space can be effectively searched/sampled
 and an evaluation function is necessary to tell the bad content from the good."

on starcraft:
" Given the competitive nature of the game, it is
 very important that the maps are fair. Therefore, evaluation functions were designed
 to measure the fairness of the maps as well as their affordances for interesting and
 diverse strategies."

that's actually really interesting

=====

10/31/16

http://pcgbook.com/wp-content/uploads/chapter03.pdf

"In this chapter, we will study a variety of methods for procedurally creating dungeons
 and platform game levels. Although these methods may be very disparate,
 they have one feature in common: they are all constructive, producing only one output
 instance per run, in contrast with e.g. search-based methods. They also have in
 common that they are fast; some are even successful in creating levels at runtime. In
 general, these methods provide (rather) limited control over the output and its properties."

i wish this book had a lot more pictures! would make BSP discussion much more clear
i think BSP would be a good technique for room placement in nystrom's algorithm
trying random room placement seems to work fine for him, so i guess it's not actually _necessary_

"create a room within the cell by randomly
 choosing two points (top left and bottom right)
 within its boundaries"

makes sense
ok cool there are actually a lot of pictures here

on tunnelers:
" The appearance
 of the dungeon largely depends on the behaviour of the agent: an agent with a high
 degree of stochasticity will result in very chaotic dungeons while an agent with
 some “look-ahead” may avoid intersecting corridors or rooms."

look-ahead idea is interesting

good explanation of tunnelers
great diagrams in this section

interlude: dnolen on slack on externs:
if you’re writing an app and you’re not publishing something who cares how complete your externs are
all this time trying to avoid writing externs is just a huge waste of time - IMHO
eventually we will automate what we can - but it’s really not
that hard to write a couple of line for whatever you are using
from some random library if that’s all you need

back to the book
this is all pretty familiar from that earlier paper
i wonder if these are the same guys
yyyyyyyyyyyyup
gonna start skimming, i don't wanna spend the rest of my life reading this book
yeah the rest of it didn't seem very relevant

http://pcgbook.com/wp-content/uploads/interviews.pdf

"I think PCG changes how you think about the world-writing for a game.
 One of the surprises for us in writing Rogue is how little PCG it took to create a
 game which people could play for hundreds of hours. We really barely got working
 what we thought was the base game, and suddenly it was popular and everywhere,
 before we got to what we had previously thought was going to be the part which
 made it interesting."

advice from the dwarf fortress dev:

"I also think it is good to try your hand at your own algorithms when possible,
since the output will have more character than something recognizable as Perlin
noise or a Voronoi diagram etc., though just having anything you can iterate on is
probably good enough, and of course existing algorithms form an important part
of your PCG skills to build on. Sometimes you can get better results faster just by
plowing ahead, though, rather than fishing around for something online. Most things
haven’t been tried yet, and there’s a wide frontier of PCG in games to explore.
If you are simulating something that can be related to a real-world process, keep
that process in mind when you are trying to correct unacceptable defects in your
output—the answer is often in some missing variable or relationship that the realworld
analogy makes clear."

https://groups.google.com/forum/#!msg/clojure/JU6EmjtbRiQ/WSrueFvsBQAJ
on why spec's instrument doesn't check ret values

"* clojure.spec/instrument helps check that your functions are _called_ correctly
 * clojure.spec.test/check helps check that your functions are _implemented_ correctly"

i _guess_ that makes sense

https://codewords.recurse.com/issues/two/git-from-the-inside-out
**********
this is just really really really good
also this website is beautiful
i really really like everything about this

https://maryrosecook.com/blog/post/a-practical-introduction-to-functional-programming

"Functional code is characterised by one thing: the absence of side effects. It doesn’t rely
on data outside the current function, and it doesn’t change data that exists outside the
current function. Every other “functional” thing can be derived from this property."

"An immutable piece of data is one that cannot be changed. Some languages, like Clojure,
make all values immutable by default. Any “mutating” operations copy the value, change it
and pass back the changed copy. This eliminates bugs that arise from a programmer’s incomplete
model of the possible states their program may enter."

https://codewords.recurse.com/issues/two/how-i-learned-to-stop-worrying-and-love-http
good intro article to send people who are starting on this stuff for the first time

https://codewords.recurse.com/issues/one/type-systems-and-logic
what the fuck?

https://codewords.recurse.com/issues/one/why-are-objects-so-hard-to-debug
this guy's really trying to use all of his vocabulary words
i mean, jeez
stop it!
god
this would be a good article but it's way too pretentious
ugh

https://codewords.recurse.com/issues/three/unpacking-git-packfiles

https://codewords.recurse.com/issues/three/making-modular-videogames
"In my experience, the process of engineering a game usually involves writing increasingly
disorienting spaghetti code in response to increasingly obscure technical problems. Even
when it doesn’t, I’ve rarely felt that the code I’ve written has had real worth beyond the
game it was written for. The code for an individual game can be highly specialized, and finding
and extracting the bits that have wider applications can be non-trivial."
he talks about entity/component here
he calls it object/component though for some reason
and all of his entities have an x/y position built in, which i don't think i agree with

"I wanted to focus exclusively on 2D games; building a 3D framework seemed beyond the scope
of the project and my grasp on mathematics"
heh amen

interesting bit about object graph, children, etc

https://codewords.recurse.com/issues/five/why-do-neural-networks-think-a-panda-is-a-vulture
panda-ostrich space

https://codewords.recurse.com/issues/six/this-just-isnt-functional
clojure protocols in js

http://jvns.ca/blog/2015/11/22/how-i-got-better-at-debugging/

http://jvns.ca/blog/2015/11/21/why-you-should-understand-a-little-about-tcp/

https://github.com/MysteryMachine/kushana

ok, my current plan for tomorrow is:
finish processing tabs (only a couple left!)
start on cellular automata blog post

at some point this week, i think i might take a look at implementing nystrom's algorithm for fun
i'll have to learn about maze algorithms first though
so maybe start with mazes, then nystrom's

=======

11/1/16

https://www.youtube.com/watch?v=VZePNGQojfA
just good general human-but-also-dev-but-also-ops advice
a bit general on the advice though, wish he was more specific about what he means and why
"why was this point-to-point? no reason. it should have been broadcast."
what does he mean by broadcast?

interesting story about the tv installation+delivery store situation
scheduling service suddenly becomes _much_ more popular, has very few resources, shuts
down the whole system

good explanation of circuit breakers

what the hell is spacemacs, anyway?
http://jr0cket.co.uk/2015/08/spacemacs-first-impressions-from-an-emacs-driven-developer.html
emacs config of some sort, targeted at vim users?
prob not relevant to me, i've gotten used to cursive and like it
https://www.reddit.com/r/emacs/comments/42rp0l/why_spacemacs/

http://highscalability.com/blog/2016/10/12/lessons-learned-from-scaling-uber-to-2000-engineers-1000-ser.html
good piece of writing - i agree with their take on the speaker, really well-phrased
****** GREAT article

let's take a look at this:
https://github.com/viebel/klipse/pull/131/files/8d747475bdc227a4d7d6e5cc746217fad4205981..1e01f50e2813e96252a82aadb86b811b19631a0e
looks pretty sick! looks like solving the infinite-loop problem in klipse is actually possible and will happen!
pretty sweet stuff

http://howtorts.github.io/2013/12/22/following-a-path.html

stumbled across https://jsperf.com/jsarray-shrink/2 just now
i should use jsperf.com! this looks great!

http://howtorts.github.io/2013/12/31/generating-a-path-dijkstra.html
apparently djikstra's useful for a situation where obstacles can be added to the level online
the idea is that you can generate a djikstra grid for the entire level, rather than one a* path per creep

http://howtorts.github.io/2014/01/02/steering-introduction.html

brainfm sux

http://howtorts.github.io/2014/01/03/steering-flocking.html

http://gdcvault.com/play/1018262/The-Next-Vector-Improvements-in
****** GOOD TALK ON PATHFINDING/FLOCKING AI
one agent has eg 4 different steering behaviors, each of which comes up with a force it wants
to apply; and you've got an arbitration function whose job is to combine those behaviors
mentions a "prioritized weighted sum of each of the force vectors"
i think he's going to give some really good info on flocking behavior here
flow fields - reminds me of djikstra grid
this stuff makes sense for tower defense games, but i dunno if it makes sense for situations
where your goal spot is moving around a lot (eg monsters chasing the player, player moves)

three flocking behaviors: separation, alignment, cohesion
"generation of the neighbor list can be optimized by space partitioning approaches
such as KD trees or octrees"
makes sense
"changes infrequently - we can do things like cache this every five ticks or something"

cohesion - points us at the average position of all of our neighbors
interesting

and alignment is like cohesion, but for "heading"

"like any dynamic physics simulation, debugging steering can be a little tricky"
"visual debugging information is absolutely mandatory!"
"you should strive to show as much information as you can visually"
makes sense

flow fields are good for when you've got a lot of agents and a "reasonably static" game world

second guy comes on, talking about more examples of steering behaviors:
chase behavior (chase player / his allies)
avoid behavior (avoid obstacles)
balanced vector problem

good speakers

"merge contexts, not decisions"
context behavior system
"interest map" and "danger map"
pyramid of interest
separation of concerns, etc

talks about how you can have virtual slots, so you don't need to have a million slots in your map

"create a projection from decision space to a 1d context map"
"behaviors write world view into danger, interest maps"
"evaluate maps for best decision" (danger maps used as a mask)

gotta keep in mind his background - working on a racing game
so he's mainly talking about this in the context of a game where the player is _inside_ a flock

wow, the demo on http://howtorts.github.io/2014/01/03/steering-flocking.html -
http://howtorts.github.io/examples/3-2-steering-behaviours-flock/index.html -
works really well and performantly!
i wonder if it'd work well for voke?
does it use flow maps?
no, just regular seeking for now

http://www.slac.stanford.edu/cgi-wrap/getdoc/slac-r-186.pdf wow this is old

https://en.wikipedia.org/wiki/Spatial_database#Spatial_index

http://howtorts.github.io/2014/01/04/basic-flow-fields.html
ok now we're talking about flow fields

"Flow Fields are a technique for efficient crowd pathfinding. They are most suitable for
situations where you want to move a large group of agents to a common destination, something
very common in RTS games."

the example isn't at all perfect, i see lots of guys going right through solid walls

"Sometimes they’ll overlap the inpassable areas (we have no physics to prevent this) and
they’ll also move through each other (no physics and no flocking behaviours to prevent this).
We’ll add these in in a future article!"

ok that's fair
he reuses djikstra's code for this
"We then go through each grid square, look at all its neighbours (including diagonals), choose
the one with the lowest distance-to-destination and set our grid square to have a vector
in this direction. We do not set Vectors for impassable grid squares."
makes sense!

"To smooth this vector we will use Bilinear Interpolation so we get influenced by the 4 grid
squares we are nearest to, with the closest providing the most influence."

http://howtorts.github.io/2014/01/05/flow-field-improvements.html

"Your flowfield grid should be at least twice the resolution of your smallest obstacle"
for tiebreaking

"If your smallest unit is larger than a grid cell, there will be paths that should be traversable
that will not be."

http://howtorts.github.io/2014/01/09/continuum-crowds.html this is really cool to play with

http://howtorts.github.io/2014/01/06/pathing-literature-review.html

http://gdcvault.com/play/1014514/AI-Navigation-It-s-Not
sc2 pathfinding
also dragon age

sc2 pathfinding:
plan, steer, collide
i think this is going to be way over my head

"steering probably required the most work throughout the project"
they have:
following, flocking, grouping, separation, avoidance, arrival
arrival is not standard

on avoidance: you need to figure out who you can ignore
all units moving in your same general direction, you can ignore
all idle units that you can push out of the way, you can ignore
(sc2 has pushing)
plot a "sight horizon", put obstacles on the horizon, aim for the gaps
read the minds of units moving toward us, see if they've already decided to avoid us
in a particular direction; if so, respect that choice

nearest neighbor searches - slowest part of the whole thing

around 25 minute mark, good discussion of heirarchical/region-based pathfinding
"we just always solved two path segments in advance"
varies from game to game
around 28 minute mark, talks about how to figure out where to cross between two regions
"simple string pulling"

dragon age origin guy
overlays sectors on top of the grid-based world
and sectors contain regions
this looks familiar from rimworld!

straight-line checks are good first step

all three of these guys have mentioned that it's super important to have debug displays
really interesting bit where he talks about how his character starts facing in a random direction
fix is to end one step early and then go to goal
**********
this is a problem with continuous world vs discrete grid/mesh!!!!!

traps - area of higher cost rather than an actual obstacle

he talks about "unrolling" the map
i'm thinking about spanning trees for some reason
not sure if they're relevant

"differential heuristics / alt" - lays the map out on a 1d projection

http://howtorts.github.io/2014/01/14/avoidance-behaviours.html
he does the same mind-reading thing the starcraft2 guy talks about
i love the demos here!

"I think we could do some fudging of the physics which would allow our agents to slide past
each other better. Currently when two agents collide head on, they are both pushed backwards
(in the opposite direction than they want to go), we could instead push them sideways (the
right angle), which would let them slide past each other much easier! This is probably a
cheaper way for a game to go, even if the physics aren’t quite real :) "

makes sense

http://howtorts.github.io/2014/01/30/Flow-Fields-LOS.html

makes sense - you can do bfs to calc line of sight

http://leifnode.com/2013/12/flow-field-pathfinding/
***********
"If the graph is dense, then allow a pathfinder to calculate paths in a non-blocking manner
such that each unit sends a request to the pathfinder and idles until the pathfinder completes
the request."
this is interesting

https://slack.engineering/building-hybrid-applications-with-electron-dc67686de5fb#.oy3x7repc
a lot more stuff about security on here than i expected
i think i'll stick with making web pages

oh http://tinykeep.com/dungen/ is sick

http://gamedev.stackexchange.com/questions/61424/delaunay-triangulation-where-to-start
ok i am just going to not thinking about pathfinding at all for like a *while*

as soon as i finish these tabs

https://github.com/vonWolfehaus/flow-field
cool flock / flow-field js demo
https://github.com/vonWolfehaus/flow-field/blob/master/scripts/components/behaviors/Flock.js flock js code
***********

http://gamedev.stackexchange.com/questions/1327/how-does-navigation-mesh-path-finding-work

http://aigamedev.com/open/reviews/alienswarm-node-graph/
"Yet, waypoint graphs are still regularly used in the games industry. I personally often
recommend them — especially to independent developers — since they're a simple and effective
approach to navigation, and if you're going to implement something yourself for a game, you
might as well use waypoints and save yourself the torment of writing a robust navigation
mesh that you may never make the most of!"

this is probably really really good advice.

http://gitlet.maryrosecook.com/docs/gitlet.html

this is cool but i'm kind of bored, her prose explanation was great
gonna close tab

http://www.gamasutra.com/blogs/ItayKeren/20150511/243083/Scroll_Back_The_Theory_and_Practice_of_Cameras_in_SideScrollers.php
*******
really good article on cameras
loooooong article wow
i'm gonna ignore this for now

so i'm not clear on exactly how the camera system will work
i guess it listens for :movement events on the player's entity
and... does what?
does it call eg (render/set-camera x y)?
i guess that could work...

http://gamedev.stackexchange.com/questions/32693/implementing-features-in-an-entity-system
these guys say make it an entity or a component
https://www.reddit.com/r/gamedev/comments/2vf90e/how_to_manage_a_camera_in_ecs_based_game/
these guys say don't make it do that

http://www.html5gamedevs.com/topic/556-using-virtual-cameras/
" The best way to support cameras at the moment is to put everything in a container and move
that around. So if the camera position is 10, 100 the container position would be set to -10, -100. "
"I will look into adding an actual camera feature to pixi.js once I have finished the bits
I'm working on at the moment, but hopefully this will do the trick as a temporary solution.."

that's dated may 2013

http://www.html5gamedevs.com/topic/23725-camera-for-pixijs/

http://www.html5gamedevs.com/topic/6691-how-does-pixi-deal-with-items-positioned-off-the-screen/
"Yes, there is no automagic culling in PIXI.js. You can implement culling on your own using `.visible` properties."

"Additionally you can divide you world into something that I call the cameras. Cameras are
display object containers that you move when you player moves.
If a camera is outside the view (which is usually a simple logic to check) you remove it
fro your stage. For additional performance you can perform checks from time to time  inside
the camera and remove or add the element that should not be there.
the cool thing about it is that you don`t have to do it every frame just every  15-20 frames."

the terminology here is a little messy but i think this is an interesting strategy for culling

this guy confirms that setting a-thing.visible to false short-circuits a lot of pixi logic
and basically makes your app faster since it doesn't draw extraneous doodads

https://github.com/fponticelli/ledge/issues/4

"You create one Container for the camera (with a width and height that will match the size
of the canvas) and a second Container for the world, which should have width and height >=
the width and height of the camera. The camera never actually moves, instead you offset the
world Container so that different sections move into and out of view."

"Most positioned things in the game are attached to the "world" Container, but HUD-related
things (mini-map, timeline, other fixed controls) are attached directly to the "camera" Container
so that they don't move when the world Container's offset is changed."

OK SO TODO FOR TOMORROW:
i think i'm going to have a camera system that listens to movement events, and if they're
from the player, notifies the rendering system that it should update its camera center position.

per the above (pretty solid) summary, i'll need to have the rendering system use two containers,
one for the whole game world and one for the UI/viewport.

=====

1/2/16

been reading this series of posts https://limpet.net/mbrubeck/2014/08/23/toy-layout-engine-4-style.html

https://doc.rust-lang.org/book/ownership.html
" Ownership is how Rust achieves its largest goal, memory safety"
it's not often that clear what a language's "largest goal" is, interesting that they can
clearly state this one, and that this is the one they picked. makes sense tho

"Rust has a focus on safety and speed. It accomplishes these goals through many ‘zero-cost
abstractions’, which means that in Rust, abstractions cost as little as possible in order
to make them work. The ownership system is a prime example of a zero-cost abstraction. All
of the analysis we’ll talk about in this guide is done at compile time. You do not pay any
run-time cost for any of these features."

"Rust ensures that there is exactly one binding to any given resource"
if you set v to vec![1, 2, 3] and set v2 to v, you can't use v any more
huh

i like the writing in this document:
"When we transfer ownership to something else, we say that we’ve ‘moved’ the thing we refer
to. You don’t need some sort of special annotation here, it’s the default thing that Rust does."

all this is very clear so far

https://doc.rust-lang.org/book/references-and-borrowing.html

you can have as many immutable references as you want, but only one mutable reference at a time
this makes sense
the compiler can enforce this as an invariant at compile time
pretty neat+smart!

"The same problem occurs when the reference is declared before
the variable it refers to. This is because resources within
the same scope are freed in the opposite order they were declared"
because stack

https://doc.rust-lang.org/book/lifetimes.html
never really seen anything like this before
"Named lifetimes are a way of giving these scopes a name. Giving
something a name is the first step towards being able to talk about it."

oh wow, i hadn't noticed - all these code samples are runnable!
not in-page, but they link to a tool that lets you run rust code
nice!
"When talking about lifetime elision, we use the terms input
lifetime and output lifetime. An input lifetime is a lifetime
associated with a parameter of a function, and an output lifetime
is a lifetime associated with the return value of a function."

dude that is a _great_ pair of sentences
god this writing is top-notch

https://doc.rust-lang.org/book/mutability.html
"Mutability, the ability to change something, works a bit differently
in Rust than in other languages. The first aspect of mutabilityis its non-default status"
/swoon

ok, the camera exists and follows the player!
this surfaces one ugly thing, though - the fact that i've put obstacles .01 px away from each other
you can see the gaps now that you can move around!
i see two ways forward:
1. see if rbush throws a collision if two rectangels share the exact same start+end pixel
2. if it does throw a collision, put things .0001 px away from each other and live in shame

yeah, if they overlap they collide:

foo = rbush(16);
rbush {_maxEntries: 16, _minEntries: 7, data: Object}
foo.insert([0, 0, 5, 5])
rbush {_maxEntries: 16, _minEntries: 7, data: Object}
foo.search([4, 4, 9, 9])
[Array[4]]
foo.search([5, 5, 9, 9])
[Array[4]]
foo.search([5.00001, 5, 9, 9])
[]
foo.search([5.0000000001, 5, 9, 9])
[]

well, i think it's actually fine if obstacles overlap. right?
a) we can mark them as "can't collide with each other" in the collision system if we want, but
b) i don't think the collision system's logic ever gets invokved on anything that isn't moving,
and obstacles never move.

random pixi quote from forums:
"Try to draw all the boxes with 1 Graphics object, that way they are batched together in webgl and draw very quickly."

https://github.com/pixijs/pixi.js/issues/2524
these guys say that canvas renderer is bad and i should use webgl renderer
trying to figure out how to move drawn shapes around in webgl renderer land

asking in the pixi gitter channel

ugh, i think i'm blocked on this until i get a response - i've poked through the source and documentation,
and i can't figure out how to move rectangles around in a way that works in webgl.
it seems like everyone else uses pixi to draw sprites (backed by images) and move those around,
and it seems that my rectangles-only usecase is very rare.
i wonder if i shouldn't be using pixi after all?

anyway whatever i'll just wait for a response
this would probably be a good time to start on the next blog post

https://toddmotto.com/cache-busting-jekyll-github-pages
he just appends the unix timestamp, that seems too heavy-handed for me actually

http://ixti.net/software/2013/01/28/using-jekyll-plugins-on-github-pages.html

trying to just use a bunch of Graphicses

ran into this comment:
 // ** FREE TIP **! If an object is not interacttive or has no buttons in it (such as a game scene!) set interactiveChildren to false for that displayObject.
// This will allow pixi to completly ignore and bypass checking the displayObjects children.
TODO: investigate

ok, looks like that's just for mouse/touch events and is set to false by default, ignore
so, next up i think should be: generating a level and plopping the player into the level
i see several steps here:
1. generate a 2d grid level (done)
2. find a good spot to put the player
3. turn the 2d grid into a list of e/wall entities, add the player, start the game

actually you know what i'll just call this branch done and spin up
https://github.com/jrheard/voke/issues/43
to track letting the player actually play in levels

heyyy i knew i remembered writing something like this: https://github.com/pixijs/pixi.js/issues/1777

ooookay, i'm seeing a sawtooth pattern on memory, and it looks like i'm leaking it to boot
i think i should make a graphics object pool

hm, i added an object pool for it but it doesn't seem to have helped anything, i still have sawteeth
i guess it's probably the graphicsData objects that're being acquired/allocated
jeez man i dunno
is all this worth it?
what if i just drew to the canvas directly?
i mean i guess pixi gives me webgl support, and that prevents the gap problem i had earlier
and presumably is fast
okok let's continue trying to fix the sawtooth

buh.
let's check out master and see if it has the same sawtooth problem

lol ok yeah it totally does
so i don't think this is a pixi issue, nice