Cake Dream: Finishing Up

My prototype for the dungeon is complete as the character can go pick up a bow, kill a dragon, and eat cake. The hero can even die. What's left for me to do now is implement the state interface so that I can add it to the rest of the project. I should have done this part first, but I just received the interface just the other day.

The state interface is basically what each level is. When the overarching map tries to load a dungeon, it just has to call that dungeon's initState() and update using updateState() and the rest is done increasing modularity. The part that will give me the most problem is that in order to implement the interface, I have move most of my logic from DungeonTopDown to TopDownBackground (the class that regulates the GUI). This infuriates me because it is mixing logic and GUI which decreases on the modularity and the bugs that will sprout up when I do migrate it over. I suppose it has to be done if I want a grade on this and not look like an asshole (especially when another teammate just migrated all his code without bitching about it).

When I did add my code with the rest of files and ran it just to make sure it would work, the code threw some errors that has nothing to do with my code. Ui::MainWindow doesn't like the default constructor for some reason and it refused to run. This frustrates me because I can't test my code and complete this assignment.

Ze Deutschbag: First Cut

I had to do an all nighter to get the first cut of Ze Deutschbag done. It really showed in the product as Autotune's lines were off sync. Other than that flaw, the film was done very nicely and was the most complete out of all the other films there. I even have strong hopes that this film will even win Best of Machinimafest. 

During the all nighter, After Effects was being just plain evil to me. My copy on my laptop wouldn't load and was stuck on Initialize MediaCore, which I later found out was Quick Time's fault (I fixed the problem by reinstalling). Then the schools version was extremely slow and wouldn't let me go frame by frame at an acceptable rate to try and get the syncing down right. With the actual work, making force fields and energy balls was easy enough though time consuming. Since I didn't have to focus on realism I could get away with the particle tail looking unrealistic. I'm off the clean up the scenes and anticipate the revisions to the other scenes done. 

More Collision Detection

Collision detection for the Square rooms went well and the code work just as posted (some values were reversed). The next challenge was to apply collision detection to the boss chamber which is an octagon shape. The four side that were like the square rooms were easy to do, but the diagonal sides were tough at first. I could have used a QPen tool to detect collision, but I needed to anticipate if a collision would happen. This required me to pull out my algebra knowledge (which was almost lost to time).

My first instinct was to get the point of the hero and project that on the diagonal line which would be perpendicular to each other. This works perfectly well as the equation for a perpendicular line is y - y1 = -1/m (x - x1). Just find intersection and if the distance to intersection was shorter than total distance traveled by the hero, then you would have a collision. This seemed simple enough on paper, but implementing the code was hard and really frustrating. The final result semi worked and I had to work to fine tune it. I then talked to a friend who has his BS in Math. He suggested a different approach using his knowledge from Foundations of Analysis. Starting from the well known formula y = mx + b and using (a,b) (c,d) for points he was able to find the formula that would help me. I forgot his exact steps, but he was able to prove that slope = (d-b)/(c-a) and got the formula y = slope * x + b - slope * a for when the hero was moving in the y axis up. Simply rearrange the formula for x (x = (y - b + slope * a)/slope)) and you got when the hero would cross in the x - axis. To check diagonally, you would then check the y axis, then the x axis. Then by tweaking a,b,c, and d you could use it on any diagonal line. This proves that a good understanding in Math is extremely useful for programming challenges and it is always good to have a math major around.

All the collision detection is done in my level and I am working on basic enemy AI and the player being able to kill them.

CakeDream: Collision Detection

I finally got all the problems from sprint #1 fixed and am starting to do actual coding. I just had to completely rework the framework that I used. I started to use a hybrid of openGL and QGraphicsItem/Scene. I have the background, a player moving, and the code to change rooms when triggered. The problem that has my focus is collision detection along a wall.

I've done collision detection before, but this was for objects destroying each other and balls bouncing off of walls. That was easy. The problem I face is not the actual collision detection, but how to handle it when a player moves along a wall. By offsetting the player each time they hit the wall will create a "jiggle" effect that makes it look all ugly. I'm trying to find a way to anticipate the collision and if a collision is imminent, then move the player to the wall border. This is the pseudo code that I plan to implement (part of it).

void keyPressed()
{
      if up key is pressed
             moveUp = true;
      if down key is pressed
             moveDown = true
      if left key is pressed
             moveLeft = true
      if right key is pressed
             moveRight = true
}

void keyRelease()
{
      if up key is released
             moveUp = false
      if down key is released
             moveDown = false
      if left key is released
             moveLeft = false
     if right key is released
             moveRight = false
}

void animate()
{
     if(moveUp)
              if(!canCollide("up"))
                      move(velocity,0)
              else
                      setPos(getX(), topBorder)

      if(moveDown)
              if(!canCollide("down"))
                      move(-velocity,0)
              else
                      setPos(getX(), bottomBorder)

       if(moveRight)
              if(!canCollide("right"))
                      move(0,velocity)
              else
                      setPos(rightBorder, getY())

        if(moveLeft)
              if(!canCollide("left"))
                      move(0,-velocity)
              else
                      setPos(leftBorder, getY())
}

bool canCollide(string direction)
{
       switch(direction)
              case "up":
                    if(posY() - velocity < topBorder)
                          return true;
              case "down":
                    if(posY() + velocity > bottomBorder)
                          return true;
              case "right":
                    if(posX() + velocity > rightBorder)
                          return true;
               case "left":
                    if(posX() - velocity < leftBorder)
                          return true

       return false
}

Do you think this implementation can work, or is there a better way to anticipate if collision is imminent.

Sprint #2: Getting Something to Show

I am really behind on my project. For some reason OpenGL doesn't want to display jpg images which is screwing up my pacing. I decided to change my architecture to QGraphicsItem/Scene which incorporates OpenGL, but its not recognizing the OpenGL part of it and refuses to show my jpg. This is extremely frustrating as I have 2 more weeks to get this done and I am progressing more slowly than I predicted. As soon as I get the images to post correct I believe that I can progress on schedule and will have to put in some extra hours to get the product that I promised. This will be hard as I simultaneously have to edit the scenes for Ze Deutschbag when I get the scenes next week, starting on a final paper (which I can easily BS), and complete at 20 page game design report. Anyone of these I can do or combination of three, but all four will be tough. Hopefully for the next sprint, I can be back on task and have something to report.

Ze Deutcshbag Animatic

We just recorded and I lent my voices for Baron Von Autotune and Monsieur Dubstep. The recording process was fun and I had a great time just playing around with the mic in the recording room. Then I got down to piecing together the animatic from all the stills that my skillful team has given me. The views that were given was limiting so there were a few shots that I didn't particularly enjoy. Then some jokes that I decided to put in but didn't think would be in the final was suddenly liked by my team and decided to keep it. Some things that were to be kept was the picture of Hasselhoff (a suitable model hadn't been chosen yet) and cut out the mouth and place a human mouth that would be animated. I personally hate that choice because its too camp and just too plain stupid. Than all the meanwhile were decided to be kept.

What's coming up next is for my team to finish doing the scenes (especially the battle scene) so that I can get those assets into after effects and work some magic. I've been experimenting with energy balls and a force field. I've been trying to create a wave of energy that goes across the room, but it's just not coming out right.