I really don’t have enough time or care to do something bunny related more involved than this right now.

Bad Dream:

I mentioned how sometimes my subconscious starts beating myself up for liking certain things in fantasy that are illegal and unrealistic in the real world right? Ended up waking up this morning from a dream where I was pulled into some kind of interrogation or something over something never-specified-in-the-dream that I had done, and then was given a fatal injection after they had concluded guilt. But for some reason it didn’t kill me instantly, and I was flailing and thrashing and fighting in pain over it.

Woke up relatively painlessly from the dream, but a little startled and fearful. Because again, there’s not exactly any real way to know if trying to get help for thoughtcrimes and worrisome metal processes and whatnot isn’t just gonna get flipped around and used as a weapon. Had an hour or two where I realized that while on some level I have accepted that I will die and that I am OK with that fact, I always assumed that my death would be instantaneous or peaceful and painful. And that as much as I always insist that ‘it’s better to try to survive, because with survival comes the potential for change (hopefully for the better)’ it directly contrasts with my mental assumption of a peaceful death and my belief that ‘the dead don’t feel’. (Though while I believe the dead don’t feel, I sometimes question that given some ghost stories I’ve heard.)

My point being. I’ve still got some issues. I’ve still got some guilt for having those issues. And I still don’t think there’s any way I’ll ever be getting rid of the baggage. The hard part is knowing that I’m wrong and that may very well one day end me. Or I could try to get help now and face the immediate risk of being ended.  I think I’ll go with the longterm survival plan thankyou.

My eyes are tired, so I’m gonna go to sleep soon

Copypasta:

Normally I don’t share assignments I’ve completed with the internet so that there can be no claims of academic dishonesty, but I think this time in particular, there’s enough specifics that it would be difficult for anyone to steal this work, and easy for me to prove it is me should it ever be contested:

The following is what one of my weekly reports  for Games Programming II looks like (with some lost formatting):

CPSC 4112 – Game Programming II – Spring 2014 – Weekly Report

Week from 31 Mar. 2014 to 6 Apr. 2014

Name: Carlis Moore

Game Studio: Blue Husky Studios

Game Title: The Seas Have Eyes

What I worked on this past week:  Added an enemy that damages the player when the player looks at it.

What issues were the most salient:

There is no cone primitive in Unity. So when I went to try to make the trigger for detecting if the player needed to be hurt, I couldn’t just have a child cone. I had to create and import a cone to use as a child mesh collider from Blender, and I had to manually reshape and reposition it multiple times to try to match with the projection of the flashlight. It’s still not perfect, but it’s progress.

What I plan to work on this week:  Make the other two enemy types work. Add the weapons and other powerups.

Special Topic for this week:

Referring to our discussion on Wednesday, do Exercises 2 and 5 in Chapter 9 of the textbook (pg. 211) and submit your answers.

Exercise 9.2

Pause Ahead <http://askiisoft.com/games/pause-ahead/> seems to take heavily after Super Meat Boy and Eversion. It’s a bit ambiguous, as the 2D platformer is something of a genre that was pushed to popularity due to successful 80s and 90s titles like Donkey Kong, Mario Bros., and Super Mario Bros and there have been several games explore variations within the genre since.

Similar to Super Mario Bros 3, the character navigates their way around lethal obstacles by running and jumping. The player may pause the game at any time. There’s a timer that counts down to zero and will remove a life if the player doesn’t reach an exit in time. There are large angry-looking rock creatures that stay stationary until the player gets close and then slams down.

Unlike Mario, Eversion, or Braid, Pauein cannot defeat enemies by jumping on them. The number of seemingly-living creatures is limited and moving obstacles are placed with such care that it takes a lot of forethought and precision to overcome them. The slightest touch of any obstacle means an instant explosion of Pauein and restart of the level. And just like Super Meat Boy, clearing a level shows a replay where all of the previous lives simultaneously run through the course as the player had before.

Unlike Super Meat Boy, Pauein cannot jump, and they have no damsel to save. The player’s only other ability is to pause the game, which freezes all obstacles in place and locks Pauein into moving with the same velocity they had at the instant the game paused. While paused, Pauien is impervious to damage and the timer will not count down. Using this mechanic is a requirement, as by level 5 there is a level with a jump that is impossible to cross without using the pause to fly the distance. (Failing repeatedly on this stage will point out the mechanic up to 10 times before giving an achievement for ignoring the primary mechanic of the game.)

The above mechanic was present from the start of the game’s design, as can be gleaned from the Molyjam prototype <http://archive.molyjam.com/display.php?GameID=141> where the prompt was ‘”What if the pause button was a weapon? Until developers think outside the box we’re going downhill.”‘ Were that mechanic removed (and the game playable without the mechanic up until the above mentioned fifth level) it would be like a simpler, easier Super Meat Boy with different theme.

Exercise 9.5

In Metroid for the NES, player’s relationship to the enemies is not balanced towards fairness, but balanced in favor of the player. Typical enemies are weak and dispatched with very few attacks, while boss monsters tend to have a variety of abilities and powers that the player cannot ever obtain. Regardless of the enemy type, however, almost all of them are designed with such patterns that they can be beaten by a player after their methods are learned. There are many power ups that allow the player to become stronger and stronger until they deal far more damage than any lower tier enemy can deal with, and the player has the ability to regain health from pickups while enemies cannot. Metroid wants the player to win, but they have to spend a lot of time carefully exploring if they want the powerups to excel. While some powerups are mandatory for progression (Like the Screw Attack) it is possible to clear the game without getting them all, as a number of them are for convenience and completion’s sake and are well hidden bonuses.

Metroid feels fair for the most part during play, as the game doesn’t hurt the player in ways they can’t identify what’s damaging them, and the game doesn’t trap the player into scenarios that they cannot win or that the outcome depends more on luck than the player’s ability to respond to a given scenario.

Log Entries:

• 2 April 2014

  • 3 PM – 5:30 PM: Flailing about trying to create at least a placeholder enemy. Did eventually implement a basic form of damage and stuff though.

  • Defects:

    • Had a lot of smaller issues dealing with referencing the correct objects from the collider and dealing the damage at a regular rate. The first were easy to deal with. The latter, I use a cooldown timer to handle.

• 5 April 2014

  • 1:30 PM – 5:50 PM:

    • Tweaked player movement so that there are three different movement control schemes the player can use. Currently there’s no way to toggle this in-game without using the Unity inspector. Tweaked the enemies and players so that they can check if they see each other via a Raycast.

    • Enemy can now smooth-follow the player once it starts looking at it. Once the player leaves enemy range, it stops tracking the player.

    • Defects:

      • Had a TON of trouble for about a half hour trying to figure out why my raycasts weren’t finding anything. Turns out I was passing a ‘0’ at the end when I should not have, making the object check only for things on a layer that I wasn’t using.

• 6 April 2014

  • 1:30 PM – 5:50 PM

    • Added the three different enemy types as placeholders. Slabs do not move from their position, but can look at the player. Boogers will chase the player when very close by, and deal the most damage per unit time. Stalks will follow the player for a much wider range and deal the most damage per attack, but have a smaller attack rate.

    • Made the screen flash red when the player is taking damage so that it’s more clear to the player when they’re being hurt. If the player’s HP drops to 0 or less the timescale is set to 0, effectively giving a Game Over state. It’d be nice to also display a Game Over screen and have a high scores list and menu cycle here.

      • Defect: I had a silly amount of trouble with this one. Originally I tried setting values in GUI.color and GUI.backgroundcolor on a GUI.label and eventually GUI.box to cover the screen. But setting those values did not affect the theme that the box or label was using. I looked up information online on how to work around it, and the best solution I found was to create a 1×1 pixel texture, set the pixel color dynamically, set that texture to repeat over the length of a surface, and then use Gui.DrawTexture to put that texture onto the screen. While it arguably takes fewer lines of code than doing the same in HTML5 with Canvas, I do miss having tools to directly draw figures and shapes to the screen filled with a color rather than having to create a texture with said color and then filling with that texture.  I imagine this practice has something to do with the rendering pipeline, but didn’t look much deeper into it.

    • Updated the Readme with the controls, added a button to toggle between the three different movement-styles,  and tried to add code to hurt the player on collision with the enemies…

      • Defect: My collision detection wasn’t working at all. No matter what tweaks I tried, the enemies were not acknowledging that the player had ever entered their collider

        • Possible Solution A: I could have the player check for collision with the enemy and then let the enemy know that the player has collided, and then do damage that way. But that’s something of an OOP violation, as the player class shouldn’t know the enemies are hostile. The enemies know that they are hostile.

        • Possible Solution B: Iterate through all contact points on a collision for ALL that correspond to the player or the player’s child. Messy, slow, and a little bit of a pain to code, but this might be the one that ends up being used.

        • Temporary Workaround Solution: Simply check if the player is within a secondary much-smaller damage radius, and then assume that it is in contact and deal damage. That’s what I did in the last hour of working on the project today, but it’s not very convincing and doesn’t scale well at all with enemy size, but trying it did make me realize a small coding error.

    • The enemies now FLEE the player! Also, I moved a lot of the utility methods I found myself using in multiple games into a separate class, that I’ll now be importing most of my existing Unity projects. I might keep a separate repository just for managing changes to it, too. Not sure on that, yet.

      • Defects:

        • Moving my usual methods into its own library was a little tricky, as I had to re-write almost all of the methods so that instead of assuming they were being called in an object that was a GameObject or owned a gameObject, they were all static methods that would be called and given a ‘performer’ gameObject as a reference with which to do all other behaviors.

        • I wasn’t sure if the enemies were supposed to be stationary or moving. Slabs, for example, were marked as stationary in the HLD, but only deal damage if the player is looking directly at them AND in physical contact with them. Which is odd. because if the player sees a Slab ahead of time, why would they ever touch one? I contacted Leggiero for more info on this one. They told me to look at the HLD again. Then I noticed Stalks and Boogers had a vague description of speed, but no explanation of in what fashion, direction, or quantified speed they moved.

        • Once I got them moving, I found they didn’t move in the way I expected. Yes, they did wait until they got in proper range before attempting to move, but once they moved, they often flew very far away from the player, with or without a rigid body. They’re supposed to be chasing the player, not fleeing it!