Here stands the hero of our journey, Frobot. He is a disco-dancing cyborg, endowed with an afro and armed with major groove. As a small boy, he was experimented on and converted into half man, half machine. As a result, he has not been able to fully grasp the concept of feelings and emotions, although he does have the capability of human thought. His creator, a scientist shrouded in enigma, abandoned him for unknown reasons. Frobot's goal is to find his creator and discover the meaning of love. But first, he must fight his way through hordes of robotic killing machines, and find friends along the way to help him on journey.

Read More

This week I dedicated most of my time to developing the next level in our game, one that introduces the new aviary enemy type Alex designed and animated last week. After some minor tweaks to the EnemyEntity class that allowed for the Robodactyl to not be pulled downwards by gravity, I was able to render the enemy in the next level of the game. While not yet completed or uploaded to the site, I can disclose the central theme of the next level. It will be mostly tied to the Robodactyl enemy, and using this new enemy type as a means of traversing obstacles otherwise impossible to be traversed, like wide pits. The player will do this in a form of platforming that involves using enemies as platforms by jumping on them, which then kills them and propels the player upwards again, giving them more height or length to their jump, depending on how the enemy is moving (vertically or horizontally). This not only allows us to design levels in new and unique ways, but also adds a new layer of difficulty to the game, since the platforms the player is jumping upon will now disappear after being landed upon. We look forward to uploading the level once it's complete!

PS: Alex and I also went to Cal Day at Berkeley today! It was really fun. Seriously considering going here :)

Read More

This week was pretty productive. We were able to make the attack function work exactly as we wanted it to. When we started the week, we had an attack function that would never stop. Essentially, the player character could constantly attack by holding "x", which was extremely broken as the character would never take damage when he was attacking, and he could move and such while he was attacking. This was not good. Ideally, we wanted to make the attack so if the player held the attack key, the attack would end and not re-start. This would force the player to only attack when he needed to and to rely on his or her reflexes to lead him to victory rather than an unbalanced combat system.

We made a series of "if" statements to make it so the same thing wasn't happening at every second the player was pressing the "x" key. We had to do this because apparently JavaScript treats button presses as statuses rather than events. This actually really didn't work in our favor. If JavaScript treated button presses as events, we literally wouldn't have to do any work, because we only want the attack to happen once-per-press. To do this, we made three "if" statements that (we think) cover every possibility for a button-press. One: if the time between attacks had elapsed and the button was not pressed in the millisecond before; two: if the button was still being pressed during an attack and the button was pressed in the millisecond before; three: if the button was being pressed after the attack ended but had also been pressed the millisecond before. The first two conditions would lead to the attack animation being played, but the third would not. This fixed it. YAY

Read More

This week was our first week after our spring break week, and we made a lot of progress! We mostly focused this week on implementing the combat system so the player could damage his enemies through other means than simply jumping on them. First we had to come up with an attack animation that would show when the player presses the attack button (we decided on the 'x' button on the keyboard) to indicate that the player was in a state to do damage. At first we wanted to have Frobot doing a disco dance move, with his finger pointed upwards and forwards, but we couldn't get it to look right due to the limited number of pixels we have for the sprite. His hand just looked really messed up. So we went with a similar stance, only with two fingers extended upwards, like a peace sign or a "V" for victory. It just made the hand look better. Interestingly enough, it's similar to what Mario does upon completing a level in the early Super Mario Brothers games.

Then we had to modify the code to allow for the character to attack. After creating a statement that caused the animation to show when 'x' was pressed on the player's keyboard, we had to tackle the more difficult portion of the coding: making it so the player would actually do damage. We had to go into the enemyEntity class and give it a set of cases for different types of collisions, just like for the player character's class. Upon doing this, we could cause the enemies to take damage, but they would die too quickly. We had to give them a few invincibility frames so their health wouldn't drain all at once. This wasn't too bad though. We had to remove some lines of code in a section that wasn't really related at all though, which was weird and we still don't understand it. Oh well, at least it works. ¯\_(ツ)_/¯

Next week we'll be working on how to make it so the player doesn't simply win the game the entire time he's pressing 'x'. :)

Read More

Week 5

This week, Alex and I continued to work out some more game mechanics not included in the base MelonJS engine. My biggest task was to figure out how to make tiles like spikes and acid hurt the player character. After searching the base engine for where different Entity objects were added to the pool, I couldn't find anything other than some mentions in the comments. Discouraged, I looked to the comments as a sort of last hope. It was so strange to me, there were multiple references to a code snippet that was not present anywhere in the MelonJS.js file, where the engine is contained. I figured that the code snippet would have to be somewhere, so I searched other files within the game folder. Eventually, I found such a snippet in the game.js file. I was ecstatic. It would work now. And it did! The game stopped crashing when I walked next to the spikes. Now the game only crashed when I walked on the spikes.

I went back to the portion of the code where I referenced the collision between the tile and the player character. It just wasn't working at all, so I did some research on the internet. Turns out I needed to create a COLLISION_TYPE for the newly-created tile class. I did that, but it still wouldn't work. Apparently the one I just created wasn't enough, it wasn't a "valid collision type". Turns out I had to register the collision type just like I had to register the class itself. Fortunately, the location to register collision types in the engine was more conveniently-located, so I wasted a lot less time with this. After registering the type, everything went smoothly. I extended the level I had been working on previously some more, and that pretty much wraps up my fifth week.

http://frobotgame.com/

Read More

Week 4

Hello all! As most of you know, my blog and Alex's got blog of the week last week, which is super exciting! Hopefully I can keep it up in the weeks to follow! This week began with a decision to extend the previously-completed level one by adding an underground portion. As I began to work on the design specifics of the lower level, Alex began working on a game over condition, where if the player died, some game over screen would be shown (as of right now, it only shows the title screen, as we have not designed the game over screen. However, as we began testing this, we noticed that our player character would simply fall into the newly-created lower level of the first level instead of dying when falling through our pit hazards. I determined I could fix this problem by simply adding other hazards that don't involve falling, like spikes. However, this opened up an entire new can of worms.

In order to make the spikes hurt the player character, I figured I would need to make them into EnemyEntities, and simply eschew using an image other than the spikes in the tileset. However, this did not work, since the EnemyEntity class called for an image, and wouldn't work without one. I attempted making a new class that extended the EnemyEntity class with modifications, but it wouldn't work with the object pooling function in the MelonJS engine. Next week, I intend to delve deeper than I ever have before: inside the MelonJS engine source code itself, to attempt to determine what's making the existing entity classes pool and my new ones not pool.

Until next week, keep playing our game! :D

http://frobotgame.com/

Read More

Week 3

This week was all about making our own level 1 and putting it into the game, with original art for the character sprites. By this point in our project, Alex and I have reached the place where we can work independently of one another on our own aspects of the game and combine our work once we have completed. So this week, Alex worked on creating animations for the protagonist, an enemy character, and a collectible sequin which the protagonist will pick up and use to purchase upgrades (we think). My task was designing the first level.

In order to do this, I first needed a tileset. After finding one online that suited our purposes, I had to compile it into a tilesheet, since for some reason our engine (MelonJS) didn't want to work with the series of images I had downloaded from the internet. So, I began hunting for applications that could do that. I went through many that probably did work, but I just couldn't figure out. Finally, I came across a YouTube video literally illustrating, step by step, how to create one of these. The only problem was that it used a program which cost $9. A small price to pay, I thought, for the completion of such a worthy and promising video game.

After tediously creating the tilesheet, I was finally able to create a level using our own tileset. I was pretty stoked. Now came the task of determining how to structure the first level. I figured that since we needed to teach the player the basic mechanics of the game, I would segment the level (with pillars) in an attempt to slowly introduce the player to different controls. Initially, I would have a platform to jump on, followed by a pillar to jump over, and another one. This would slowly introduce the player to jumping, allowing them to face the next challenge: enemies. If the player was not comfortable jumping, he or she could definitely not jump while fighting enemies, so I wait until the player has been jumping for a while. I introduce enemies slowly as well, familiarizing the player with them in increments. However, it would probably be best if you just played it yourself! We'll post it on our game's domain soon!

http://frobotgame.com/

Read More