explosive games

4/22

Well, we were having some trouble getting our BETA version to work on all Windows machines. For some reason, it appears that it works better on older machines/less capable ones than high-end/newer machines… To be determined…haha. Try to run it yourself and see if the game works, hopefully it does and you can enjoy!
https://jshare.johnshopkins.edu:443/ttantil1/public_html/DIORAMA-GOOD.zip

4/19

The BETA is due in a couple of days and we decided to start implementing some of the puzzles (yes they are basic…) that the player must complete in order to progress through the game. We are going to implement a maze in one of the early rooms that the player must complete in order to get his/her first weapon, the magical red bullets! Only when the player gets this can he/she go back and kill the TieMonster, which then grants access to the next area of the world. Also, the next room provides a door that apperas locked. In order to get through this door, we have placed a special key in the next room that the player must find in order to gain access.

In order to implement these “special items,” we have set up special areas that are indicated in the text documents that are used to create each room. If a room should have a item/power-up in it that the player can pick up, an object is drawn here and then the room will know that if the player steps into this area, to “do” the action, whether it is giving the character a new weapon or rejuvenating life. We need to fine tune this concept a little bit, but for now its working good enough.

-Tom

4/17
With the BETA just around the corner, we figured that it would probably be nice to kill something or at least seem as though the player can win. So we implemented a health system for the player and the enemy NPCs. We aren’t too sure of a default value of health (maybe 5 or 10), but we decided to go with 5 for the time being. Using the shooting system and collision detection that we set up, we were able to detect when the player shot a projectile and when it hit the NPC. When this happened, we set up a function that would be called in order to lower the enemies health. When the NPC’s health hits 0, it is deleted from the room and we have successfully “killed” something. Quite exciting…

We haven’t implemented the player being able to die yet, but we are very close and it will absolutely be done for the final version of the game. As of now, we can’t wait to load in other enemies that we will be able to explode, no pun intended.

Our process of making textures involved Stephen making a collage or pattern with construction paper or tissue paper, using his scanner to scan it in, making small edits in Paint or Photoshop, and handing it to Tom and Gustavo along with written desriptions of each room.  (for example, north wall, TissueSky1.jpg, west wall, CardsTexture.jpg West Door, greendoor.jpg, floor: grass1.jpg).

The “outside” room textures are layers of tissue paper over a layer of white printer paper, with pieces of cotton balls double-stick taped up for clouds.
Objects are created in similar ways.  For example, for the trees, Stephen cut out the trunk in cardboard, and then cut out the shape of the leaves first in green construction paper, and then green tissue paper, and layered them together.  He then taped it all together with double-stick tape and scanned it in.  In photoshop, he isolated it and exported it as a PNG, and handed it to Tom and Gustavo to texture an object in the room.

The Tie Monster is exactly what it looks and sounds like.  A yellow tie was photographed in two snake-like positions (using a button as an eye), isolated in photoshop, and then made into an animating set of textures for an enemy.

Some room textures are actually just photographs, or derived from them.  The floor of the first room is a snapshop of Stephen’s desktop at home. In paint, he layered on scanned-in images of yellow paper, red paper, and a notecard.  The second room’s floor is simply a photograph of the red paper and tic-tac-toe postits on the desk, as is and unedited.

Thus, all of our textures are real found or made objects, most of which are now either in Stephen’s desk or hanging on his walls for decoration.  He’s never letting go of that title screen - he spent too damn long making it.

4/10

We’ve taken a break from programming to concentrate on the new art style that we’ve decided to come up with (see Stephen’s  post). At first, we were skeptical, but after seeing the first couple of floor and room textures, we were hooked. I’m sure that the class and the TAs will be pleased with the unique art style that the group with no artist has brought to the table. Now, with character (stick figure) sprites on the way, we’ve decided to focus on animation for both the player and enemy NPC characters in the game.

Actually, getting the player to animate frames has been one of the smoothest things to program thus far. We were able to load up all the textures and have OpenGL cycle through each of the animation frames smootly based on a frame rate that was set up as the walking speed/running speed. The animation cycle looks pretty good and convincing and the token enemy TieMonster looks ferocious! =)

3/34

So after our next meeting with our mentor, we began exploring how to create projectile objects in the room to fly in the specified direction, and then to have the bullets collide (using our collision detection) with walls and other objects in the room. We figured out how to have a limited number of bullets in the room at one time and to destroy (delete) bullets if they were still in flight when the player changed rooms.

Due to some feedback from the alpha, we also decided to change the targeting system a bit. The player can now shoot in the y-direction as well as the x and z. Of course, we do not allow the player to shoot in the negative y-direction (As the bullets would go through the floor). This should allow the player to have a more realistic feel when playing the game. The bullets correctly collide with walls, enemies, and other objects in the room.

Retroactive blog post regarding the arts style:
So, we decided to take the judo approach to approaching our art design problem.  That is, to turn our weakness (our relative lack of conventional visual artistic ability) into our strength. It sort of meant a scrapping of the original storyline premise with the whole Stowaway on a spaceship thing, but all of our gameplay mechanics remain intact.

Our hero is a stick figure, each frame of animation lovingly drawn with Sharpie on a pad of yellow paper.  He steps off the yellow page to find himself in a world made of construction paper, tissue paper, carboard, desktops, and monsters made out of neckties.  Each room of our world looks and feels like a diorama, which is the new name of our game.

3/30
We actually ended up taking a break from the game for the week after spring break. We then met with our mentor to talk about how to start putting in collision detection with objects in the room. Initially, we wanted to do circular collision detection with objects in the room in order to give the game a more realistic look. However, the circular math started to become very hard, especially since most of the sprites/objects in the game are upright billboards with no real z-depth. We ended up deciding to just use rectangular collision detection with a fixed width in the z-axis for each object. After a couple attempts, the code worked

-Tom

3/10 

Alright we got the .PNG files working. There was some weird error going on which I still don’t know why it was happening. Turns out I didn’t need the libpng or zlib (I think they may have already been on my computer). Actually, we loaded up Photoshop on the computers on our campus and changed the .PNG files we had from 32-bit to 8-bit, and they loaded up fine using the GL_BLEND and ALPHA functions.

Moving along, we almost have our complete engine. We have a text file for the world/rooms, a room class, an object class, a camera class, and a player class. We are just working on linking two rooms together by the door objects now. And of course, shooting. Interestingly enough, I loaded a billboard w/ sprite on it that wasn’t the player (AKA the line wasn’t drawn from it), and it looked as though the line actually stuck to it when the mouse was on it!?!? We are going to be doing more testing with this, but this could make mouse picking much easier? Anyway, we’re going to be setting up our presentation tonight for tomorrow!!

-Tom

So side node from shooting, I downloaded SOIL to handle .png images for the transparent character sprites. I got SOIL to compile and work, and it loads in .bmps, .jpgs, etc. correctly. However, I can’t load in .pngs and I think its because i need to install libpng/zlib for the program to use. But, I’ve been having a very hard time doing this. All the things online I see use makefiles and I wish one of these stupid sites would explain how to do it manually without using some command prompt.

BTW, we got the text editor working to load in rooms/doors. AKA object orienting the world. Only have the player to object orient now.

-Tom