is presently its sole maintainer,
You can support him:
Recap and plan for the day ahead
handmade.h: Add EntityType_Familiar and EntityType_Monster
handmade.cpp: Introduce AddMonster and update AddLowEntity
Add a monster
Run the game and see the monster
Reiterate the fact that it is the SetCamera call that brings everything into the HighEntity set
handmade.cpp: Write cases for drawing each EntityType
Run the game and see our Monstar for the first time
handmade.cpp: Add a familiar
Run the game and see our Familiar for the first time
handmade.cpp: Consider how to update the HighEntities
Consider the "jump code" and do some clean up
handmade.h: Introduce entity_visible_piece and entity_visible_piece_group
Change DrawBitmap calls to PushPiece
Consider doing the rendering directly, rather than deferring it
Finish implementing PushPiece
Run the game and note that we're doing the exact same thing we were doing
handmade.cpp: Add Update calls for the entities
Compute the ShadowAlpha incorrectly for now
Implement these Update calls and give the Familiar some logic
Change MovePlayer to MoveEntity
Give the Familiar some movement logic towards the Hero
Run the game and tweak the Familiar's logic
Moment of realisation: The player's speed is baked into MoveEntity
Make the Familiar move at half the speed of the Hero and check it out in-game
Q: Why "Monstar" and not "Monster"?
Q: If someone rewrites your code using OOP and it runs faster, what would you do?
Q: Why do you want to be able to outrun your familiar? Doesn't having to stop for him to catch up get annoying?
Q: Could you make the head bob up and down while following the player?
Q: Could you write Pong real fast, so I can see how to start?
Q: "Monstar" would be confused with "Mon*", a pointer to a Mon
Q: Are we going to eventually use a component-based entity system, instead of using an enum of entity types? If not, why?
Q: Would you think about doing some proportional integral derivative control for familiars to follow?
Q: I have a bad feeling about that switch on EntityType. Do you think it will probably go away as we get closer to the final architecture?
Q: Would collision be an XY-only thing, or would you take into account Z, as in jumping over another entity?
Q: I have a feeling your Low entities will be quite big if they have AI and stuff. Won't this be a problem for the huge world? Maybe it would have made sense if you had kept the tile data in chunks so you can deflate some entities just when needed
Q: The performance boost off the low / high shuffle: when will we see this come into play?
Q: Could we spawn a ton of these floating head things?
Q: How will the Z work exactly?
Q: Will there be a flock system for all the floating heads following the Hero?
Q: What kind of path finding will be implemented for High entities and how will they differ from faraway Low entities? And will Low entity NPCs who are always on the move really far away always resolve? It would be interesting to come across a very live world full of history, dead bodies, etc. due to constant AI acting, but would that be feasible?
Q: How easy would it be to chain multiple bobbly heads to follow each other?
Q: CameraTileY + OffsetY not OffsetX in AddFamiliar call
Q: I was very glad to hear that you deem classes to be basically garbage. I spent too much time with C# trying to learn object inter-jugglery between them
Q: About the chaining familiars, could each familiar check if the hero has a familiar already and, if it does, then try to follow the familiar instead?
We've come to the end of the questions