Monday, November 30

The Game: Case 10 - The End



Well, here we are! The last of these entertaining rapport-posts. It's seven thirthy in the morning and after a good night's no-sleep-at-all I have loads of energy to write this last post in the nick of time. Time to inject that last red bull in my arm and get to it.
Case 10 - Make a pretty menu with flowers(optional) for your game. Also make win and lose screens, with retry-buttons.
If you read this blog at all you would already have seen the fruits of my labour, in the form of the Blindfighter Beta Version, which is now updated to the final version.

In other news, can not recall any lab-sessions or group-meetings detailing ways to make this menu-magic happen. What I did, though, was that I just began drawing and making text in flash, and finished the menu screen in a few hours. Then creating the other screens was no biggie. I spent a lot of time organizing my freakishly long script into bite-size chunks, or functions, which I could then call at the appropriate time or mouseclick-event. I also made sure to clean up after myself when something in the script is no longer used, so all chance of clutter-induced lag is eliminated.

As a last detail I have added a Rank-system to the game, ranging from 10(worst) to 1(best) which gives you an appropriate rank based on your completion time. All right, that concludes the obligated blog-posts. If you would like me to keep posting flash work and other possibly awesomely cool stuff on this blog in the future, please say so, or else I probably won't.
...And then my blog will become just like this blog

Merry christmas, you filthy animals!

Thursday, November 26

Blindfighter Beta out now!

The Blindfighter beta has already been out for a day on DeviantArt! Check it out and leave comments and bugs you find either here, or in the DeviantArt comment section. The game will hopefully be updated about once a day until monday, so remember to check back often to help me eliminate bugs!

Monday, November 23

The Game: Case 9 - The Sound of Music

I guess it's time for a new update
Case 9 - You will now add sound and music to your game. All the sounds have to be triggered by scripted events. You can not use copyrighted music.

Admittedly, this case text has not been my focus during the last weeks at ALL. Mostly I've been working on my combat system, interface, and menu screens, and the game is starting to really come together. Only recently have i dabbled in the sound department. I have scoured the web for music to use, and also a friend has joined in on the sideline and has been experimenting in fruityloops with soundtracks for my game. Awesome. If there's time, I may try to make something on my own, but I kind of doubt it as the finished game deadline is next monday at 14:00.

For sound effects, I went straight to a good old favorite freewaregame of mine, Little Fighter 2. That is a great game right there. You can check out the website here. This game sports wicked cool arcade-beat'em'up-style sounds, which would also not be copyright infringement to use, as long as I don't claim copyright over them or put out my game for sale, which I am totally going to do.



Anyway, I have started to implement them into my game by importing them to flash, declaring them as variables, and then feeding them through the SoundChannel class in ActionScript. The only problems I have encountered are that the sounds will be started and played up to 30 times a second if the triggering event is not initiated only ONCE. This might sound "simple" but is sometimes really hard to debug and solve, since flash has no .playOnlyOnce(GodDammit) method. So more experimenting is needed to solve some of these hickups.

In the group meetings and lab sessions we were walked through how to use the already mentioned SoundChannel and Sound classes to play sounds through script. Almost everyone in our group has come as far as needed and everyone, including me, are helpful when asked. I also help a lot outside the group, and get tips and tricks from others when I need it. Experience has taught me that much can be solved rather quickly by two minds where one mind does not cut it.

That just about sums things up, and since I hate people that don't have any pictures in their gameblogs, I'll leave you with a snapshot of my menu screen. And also some questions. 

Q: What do you think of the menu?
Q: Since this game production is nearing it's end, what would you like to see in the future on my blog?

Comment with an answer to these questions and win a free cookie!


Monday, November 9

The Game: Case 8 - Items, Arrays and Counters

Allright, things are looking better, and I'm catching up to myself, so to speak. I sat up last night till three o'clock and finished up case 8.
Case 8 - In this case you have to create objects for your hero to pick up and get some kind of "points" for. The points are to be added to a counter and shown on-screen consecutively. You will also create objects that your hero should avoid. The hitting of such an object should somehow also be made apparent on-screen.
Firstly, I have begun redoing the previous level design to be more in touch with the game's "story", which can be read in its entirety on my group's Wiki Site. You now play in a desert town/city. Although I really liked the cave level design, the desert is also starting to look pretty neat. I may also revisit the cave theme if I decide to make another level in my game, either before or after this project is officially over.

Secondly, Case 7 is now also completed, and the brute follows the hero around nicely when he gets too close. When in touch, he stops and punches at him with his ginourmous fist. This still leaves a lot to be desired for my game though, and I have promises to keep, and miles to go before i sleep. Combat system is up next, and I need to make proper hit-detection, damage calculations, death animations and more fight animations for the hero.

In other news, Case 8 seemed to be easy in theory, but was harder to implement than I thought. After having been introduced to the Case on Monday, not much was done on my part to complete it, as I had my hands full with the previous case. Adding to the trouble is the fact that my game is now a side-scroller, which complicates the movement of objects A LOT. Finally, after looking over Anders' script on thursday, I understood how to easily communicate between ActionScript-files, and got stuff handled. This also helped me create the Item class, and helped me along in Case 8. The lab on thursday was also a great asset to understanding Arrays and Timers, and how to use them in your script.

What I've done:
First, I created a symbol containing a small "bobbing" animation of a water pouch. Adding this to the stage through the script in multiple instances, I pushed it into an array and defined the points where the items should appear. This makes it easy to add or remove more items later. Then I made the hero able to pick the items up by touching them. The act of doing so adds water to the newly designed User Interface's "water-bar". The bar depletes as time goes on, and complete depletion of the bar means the screen will rapidly go black and you will lose. Also, there is a counter whichs counts how much water you have.

   Not pictured: The counter for my game
What I've learned:
1. As I've already experimented with timers for my combat system in-the-making, I mostly learned about Arrays and For loops this week. They are extremely useful if you can understand the small amount of slightly more intricate code, and will save tons of space in your script files.
2. Generally, I've learned that practice makes perfect. Scripting is hard, but if I stick it out, I can make things happen. It takes time, but the effort is worth it in the end.

If things go after plan, I might upload an early beta version of the game in the following week. If not, I might just withhold it until the game's actual "release", to make it more exciting. I could use a couple beta testers though. Is that something you might be interested in? If so, leave a comment.
Toonsta out!

Monday, November 2

The Game: Case 7 - Enemies


Case 7: Create and design an enemy for your hero, which has basic AI and will follow your character around on his own without relying on button presses.
In this case I focused more on the design than the actual scripting, and when i got to the scripting I had a lot of trouble in making the new "enemy" class and AS-file work together with the Main.AS-file. I actually got to a point where the enemy would follow the character, stopping when in touch and punching at him. Then, something happened that just f***ed everything up. I don't know what I did to ruin it, but suddenly everything would freeze up and i had to delete some of my script. Now I can't even get the brute to follow the hero properly. GOD DAMN IT. Pardon my french. I need some help with this.

Anyway: Here's a screencap of the "Brute".


















After I get this problem handled, Case 8 is up, in which I will make the collectible water canteens and "blind"-system for my game. Also try to make it able for the characters to actually damage each other. That would be a nice feature for a fighting game.

The Game: Case 6 - Design and Plot

I'm getting to a point where I'm pretty much frustrated by everything I can't get to work out the way I intended. I thought I was done with my background theme, I thought I had some kind of doable plot planned out, but more and more I get frustrated and think about how nothing is "good" enough. Seems I expect myself to make the greatest game ever or something. ...Maybe I just need to cut myself some slack.
Case 6: In this case, review and revise your game's plot/story and create backgrounds/environments for your character to move around in. 
Game Plot (so far): You play an acrobatic thief in an arabian setting (think Aladdin/Prince of Persia), who has been caught stealing from the temple dedicated to the new, self-proclaimed spiritual leader/high priest/dictator of the land. This leader imposes a strict and violent law on the people, and the thief is to be made an example of. They gouge out his eyes in public and leave him out to dry in the sun, only to be hanged three days later. During those three days his hearing is fine-tuned, allowing him to virtually "see" using his other senses. On the day of his execution, he decides enough is enough, and breaks free to get his revenge. On the way he has to fight the evil dictator's army of brutes, and also collect flasks of water on the way, as he is severely dehydrated and if he doesn't rehydrate in the blazing sun he will inevitably lose his keen sense-focus and eventually die.

Hopefully I will have time to create a cutscene or two to tie the plot more into the gameplay. Also with this plotline i have managed to exploit the fact that he is blind to make the game feel more urgent (collect water or lose your "sight"). I hope I will be able to implement this in a satisfactory way, blurring/blacking out the screen gradually if you are lacking in water.This might be fun to experiment with.

If you played the current version of the game I posted before, it's pretty clear that he is in a cave, which doesn't work to well with the new story. I will therefore redesign the environment to a more desert-y "Agraba" feel.

Friday, October 30

The Game: Case 5 - Ground and Gravity

I know I haven't been very regular with these blog posts lately due to various circumstances, but we've already come to Case 7 and now I'm gonna have to really step up my game. Literally.

Case 5: "Creating a more advanced groundline to move along, and gravity physics for jumping".

Since I was totally put out of play by my appendix surgery during the "Case 5 week" there's not really much I can say about what went on at school and with the others, but I did complete the case nonetheless. In the process of creating a new, more curvy ground that my fighter could move along, I also created some background art to go along with it (which you can see here). It just seemed like the right thing to do. I got some tips from Svein, and by using a while loop checking when the ground and the fighter touched, I could keep him on the ground by pushing against gravity, which was pushing down on the y-axis. During the previous cases I had already implemented simple gravity physics, as is demonstrated in my Case 4 post.

Additionally I can share my solution to a problem i have run into a lot in my code in general, which is getting the right animations to play in the right situation. Like getting the idle animation to only play while my character is on the ground and not doing anything else. What I have done is just use a lot of if(!jumping && !attacking && !drooling) conditionals, that check if "activity variables" I have created are false. So in this case if my character is NOT jumping, attacking or ...drooling, he will be idle. Hope that helps someone out there. Stay tuned for more rapport-ish posts this weekend.