mandag 30. november 2009
Case 10 report
Okay, finished with the project now. This entry is a bit late, but no worries. Okay, so different screens were made for win, loss, start and instructions in this case. They got their own buttons to communicate between each other. There are a few problems with the restart function, but nobody knows what to do with it. But the game is done for now. I will pick it up from time to time and finish it up completely, in time. I will also update this blog with my process.
søndag 15. november 2009
Case 9 Report
Case 9 is now done. This time, the task was adding sound to the game. This included both making background music, and sound effects. All sounds were to be triggered through actionscript.
This case was fun and a bit different, as it required us to work with sound. It was forbidden to use copyrighted music, so either it had to be made, or it had to be a file without copyrights. For my game, all background music was made by myself in Fruity Loops 8. Sound effects are mostly freeware from www.flashkit.com.
Sadly, I missed the group meeting on Monday. There really is no good excuse for it, and I wish I could have been there, mostly because of what was mentioned about the group meetings in my previous report. There might also have been something important that I might have missed.
It was mentioned in my previous report that I had already learned a way of implementing sounds through actionscript. Thus, a lot of the things the instructors went through this Thursday were familiar. However, as the method I had already learned is really quite simple, there was also a lot to be learned, and a few of the explained methods were quite useful, particularly how to load music from external sources. However, as the method I had previously learned does the job very well; changing it seems pointless. It would also be a lot of trouble, as there are now several classes in the game. Then it would simply be too time-consuming, and perhaps, stupid to change all of these classes just to fix something that already works.
This case was, on my part, already done before it was officially started. Experiments in Fruity Loops were started way back between case 2 and 3, and thus, there has been a lot of time to improve. The music is by no means final, but the current results are satisfying. Unfortunately, this also means there has not been done very much on my part this week. As for actionscript, using the afore-mentioned method, 5 different background music files were coded into the game. A function was also made to make the music turn on and off, using number keys 1-5 to turn the corresponding music file on, and the m key to mute whatever is already playing.
This means there is no music at the start of the game, because it has to be turned on manually. This was done to avoid players not wanting to play the game because of potentially annoying music, until the music is final. The sound effects, however, are mostly final.
In the end, this case has been relatively easy, fun, and different from the rest. I enjoyed this case, even though most of it was finished earlier. I feel I have definitely learned something, even though initially thinking there was really nothing to be learned. This project is nearing its end now, so I am very much looking forward to starting the final case, and finishing up the game.
This case was fun and a bit different, as it required us to work with sound. It was forbidden to use copyrighted music, so either it had to be made, or it had to be a file without copyrights. For my game, all background music was made by myself in Fruity Loops 8. Sound effects are mostly freeware from www.flashkit.com.
Sadly, I missed the group meeting on Monday. There really is no good excuse for it, and I wish I could have been there, mostly because of what was mentioned about the group meetings in my previous report. There might also have been something important that I might have missed.
It was mentioned in my previous report that I had already learned a way of implementing sounds through actionscript. Thus, a lot of the things the instructors went through this Thursday were familiar. However, as the method I had already learned is really quite simple, there was also a lot to be learned, and a few of the explained methods were quite useful, particularly how to load music from external sources. However, as the method I had previously learned does the job very well; changing it seems pointless. It would also be a lot of trouble, as there are now several classes in the game. Then it would simply be too time-consuming, and perhaps, stupid to change all of these classes just to fix something that already works.
This case was, on my part, already done before it was officially started. Experiments in Fruity Loops were started way back between case 2 and 3, and thus, there has been a lot of time to improve. The music is by no means final, but the current results are satisfying. Unfortunately, this also means there has not been done very much on my part this week. As for actionscript, using the afore-mentioned method, 5 different background music files were coded into the game. A function was also made to make the music turn on and off, using number keys 1-5 to turn the corresponding music file on, and the m key to mute whatever is already playing.
This means there is no music at the start of the game, because it has to be turned on manually. This was done to avoid players not wanting to play the game because of potentially annoying music, until the music is final. The sound effects, however, are mostly final.
In the end, this case has been relatively easy, fun, and different from the rest. I enjoyed this case, even though most of it was finished earlier. I feel I have definitely learned something, even though initially thinking there was really nothing to be learned. This project is nearing its end now, so I am very much looking forward to starting the final case, and finishing up the game.
søndag 8. november 2009
Case 8 Report
Case 8 has now come to an end. The problem this time was adding objects to the game that the main character can pick up, as well as objects to avoid. Making a timer, as well as a point system, was also part of the case.
The main new things introduced in this case were arrays, and the "for" loop.
This week started off like the previous one, with the exception that everyone in the group showed what they had done to the others on Monday (this might have been done for case 7 too, though I can't remember it). Still, everyone sort of did their own thing after the initial meeting, instead of looking more at each other's work, and trying to help those who find this hard out. In my opinion, there could be at least a few changes here, as people in the group, myself included, seems a bit self-centered, and afraid to ask the others for help. It is generally very quiet every Monday. If this is because everyone understands everything they need to, then everything is fine. However, this is undoubtedly not the case for everyone. Of course, it is hard to know exactly what to do at the start of each case, but even just throwing some ideas out there for each other on what to do, and how to do it, would probably be of great help to anyone who does not have any idea where to start. In addition, it could be a great thing for the ones who already know where to begin to get some alternative input.
In the end, nothing was done this Monday on my part. In the lab that Thursday, the instructors had a very good presentation and introduction to Arrays and the for loop. These things probably made a lot more sense to many after this lab, at least it helped clear things up for me. However, there was still nothing done on my part to complete the case, even after that great lab session.
That Friday, however, there was finally some progress made on the case. After having briefly examined one of the examples uploaded to Fronter, the case was completed with relative ease. Most of it was done in about ten minutes, which really goes to prove that, once it makes sense, the Arrays and the for loop are among the easiest, and perhaps most logical things to do in ActionScript 3.0 that we have learned yet. It was not neccesary to read any tutorials or even the Beginner's Guide after reading the example, as it all made perfect sense after the lab on Thursday.
As for the case itself, there was made two different arrays for the objects that are to be picked up, so that there would be possible to implement two different types of objects to pick up. One for the point system, and one for the health system that was developed during the case. As for the objects to avoid, the enemy has been coded to work in conjunction with the health system, basically taking one hitpoint each time the main character hits it. The health object then refills one hitpoint as long as the hitpoint gauge is not full. If the gauge is full, the object is simply picked up and removed from the stage without doing anything. Even though it is technically a part of case 9, some sounds have already been coded in, as I learned a way of doing it from my dad a while ago. After careful consideration, a timer was not implemented. In its place, my dad helped me make a function for displaying a constantly updating framerate, which shows the framerate the game is running in at all times. This helps quite a lot in testing lag in the game.
On a side note, the graphics were almost totally remade for this case. See previous post for a link to the current version of the game.
Upon completion of the case, I realized that, for me, this has probably been the easiest case yet. This is undoubtedly closely related to a growing understanding for coding in ActionScript 3.0, and an above average amount of interest for the subject. The final two cases are highly anticipated.
The main new things introduced in this case were arrays, and the "for" loop.
This week started off like the previous one, with the exception that everyone in the group showed what they had done to the others on Monday (this might have been done for case 7 too, though I can't remember it). Still, everyone sort of did their own thing after the initial meeting, instead of looking more at each other's work, and trying to help those who find this hard out. In my opinion, there could be at least a few changes here, as people in the group, myself included, seems a bit self-centered, and afraid to ask the others for help. It is generally very quiet every Monday. If this is because everyone understands everything they need to, then everything is fine. However, this is undoubtedly not the case for everyone. Of course, it is hard to know exactly what to do at the start of each case, but even just throwing some ideas out there for each other on what to do, and how to do it, would probably be of great help to anyone who does not have any idea where to start. In addition, it could be a great thing for the ones who already know where to begin to get some alternative input.
In the end, nothing was done this Monday on my part. In the lab that Thursday, the instructors had a very good presentation and introduction to Arrays and the for loop. These things probably made a lot more sense to many after this lab, at least it helped clear things up for me. However, there was still nothing done on my part to complete the case, even after that great lab session.
That Friday, however, there was finally some progress made on the case. After having briefly examined one of the examples uploaded to Fronter, the case was completed with relative ease. Most of it was done in about ten minutes, which really goes to prove that, once it makes sense, the Arrays and the for loop are among the easiest, and perhaps most logical things to do in ActionScript 3.0 that we have learned yet. It was not neccesary to read any tutorials or even the Beginner's Guide after reading the example, as it all made perfect sense after the lab on Thursday.
As for the case itself, there was made two different arrays for the objects that are to be picked up, so that there would be possible to implement two different types of objects to pick up. One for the point system, and one for the health system that was developed during the case. As for the objects to avoid, the enemy has been coded to work in conjunction with the health system, basically taking one hitpoint each time the main character hits it. The health object then refills one hitpoint as long as the hitpoint gauge is not full. If the gauge is full, the object is simply picked up and removed from the stage without doing anything. Even though it is technically a part of case 9, some sounds have already been coded in, as I learned a way of doing it from my dad a while ago. After careful consideration, a timer was not implemented. In its place, my dad helped me make a function for displaying a constantly updating framerate, which shows the framerate the game is running in at all times. This helps quite a lot in testing lag in the game.
On a side note, the graphics were almost totally remade for this case. See previous post for a link to the current version of the game.
Upon completion of the case, I realized that, for me, this has probably been the easiest case yet. This is undoubtedly closely related to a growing understanding for coding in ActionScript 3.0, and an above average amount of interest for the subject. The final two cases are highly anticipated.
lørdag 7. november 2009
Game REMAKE
Allright! I totally remade my game! It now sports new graphics, pickups (2 kinds, one for points, and one for health), and a new code for the enemy. It also has a point system, a working life system, sounds, and music you can turn on and off. The format is a bit too big for the browser, so press F11 until I re-upload it in a smaller one. It shows the framerate in the upper left corner too. Soo, give it a try! There is still no restart button though.. And if you're a fan of buggy music, try pressing a music button(1-5) and then switch the levels(page up/page down, the second level is more of a placeholder..). For some reason, it starts playing the same music again on the second level, without stopping the previous one..
Oh well, here's the link anyway:
Sidescroller Revamp by ~Andbja on deviantART
Oh well, here's the link anyway:
Sidescroller Revamp by ~Andbja on deviantART
mandag 2. november 2009
Case 6+7 report
Case 6
This case revolved about designing new backgrounds and characters. Another thing we had to do was to think about our concept based on how much programming was needed and difficulty. I have now realized I have a lot to do, even if I am only working on a demo version, but I am by no means intimidated by the amount of work. If anything, it inspires me to work harder, if only to see how it will work, or if it even works at all. Another aspect of the case was to "sell" the concept here on the blog, which I feel I have already done in earlier posts.
In starting with this case, I considered this to be a break from the harder programming cases, as I had already created a lot of characters and backgrounds back in case 1. I also thought that this case is more individual, so I did not really sit down with the group to exchange ideas, or discuss already conceived ideas. In hindsight, this might have been a poor choice, since it could have contributed a lot to both my, and others' work. Then again, no-one really took any initiative to do this, and I think most probably thought like me. However, except for mondays, I don't see members of my group very often, so I cannot say that nobody did later.
Case 7
The main objective of the case was making semi-intelligent enemies. I say semi-intelligent because they are only supposed to follow the hero, and that is it. Possibly the hardest programming case yet for many, although I did not really think so. The only really new problem was that we were supposed to make a new class for it, and getting said class to communicate with the main class. Thus, we had to learn what a parameter is, and how to use it. The instructors in the lab on Thursday did a very good job at explaining it, and I had no real problems after that.
This monday's group meeting was uninteresting, really. I cannot even remember most of what we talked about, so there clearly were no good ideas or possible solutions to the case, and after starting up, it seemed like everyone just did their own thing, and nobody asked anyone for help or anything. Maybe that was just me doing that, but nevertheless, this meeting was, for me, just sitting around and doing something in Flash. I am not one to say that everybody did so, but I feel that I didn't get anything out of the meeting.
Anyway, I managed to finish the case, and I now have a sheep following the Hero.
/end report
Okay, we have been told to be more formal and "report-like" in our reports, but I honestly have no idea how to go about doing that. This report was an attempt to do just that, and I probably failed miserably, but I try.. Oh well, I'll get it right someday.
Oh, and here's the results, the life system is a bit f'***ed up, but once you hit the sheep, it should be okay. You've got 3 lives.
Side-scroller game WIP by ~Andbja on deviantART
This case revolved about designing new backgrounds and characters. Another thing we had to do was to think about our concept based on how much programming was needed and difficulty. I have now realized I have a lot to do, even if I am only working on a demo version, but I am by no means intimidated by the amount of work. If anything, it inspires me to work harder, if only to see how it will work, or if it even works at all. Another aspect of the case was to "sell" the concept here on the blog, which I feel I have already done in earlier posts.
In starting with this case, I considered this to be a break from the harder programming cases, as I had already created a lot of characters and backgrounds back in case 1. I also thought that this case is more individual, so I did not really sit down with the group to exchange ideas, or discuss already conceived ideas. In hindsight, this might have been a poor choice, since it could have contributed a lot to both my, and others' work. Then again, no-one really took any initiative to do this, and I think most probably thought like me. However, except for mondays, I don't see members of my group very often, so I cannot say that nobody did later.
Case 7
The main objective of the case was making semi-intelligent enemies. I say semi-intelligent because they are only supposed to follow the hero, and that is it. Possibly the hardest programming case yet for many, although I did not really think so. The only really new problem was that we were supposed to make a new class for it, and getting said class to communicate with the main class. Thus, we had to learn what a parameter is, and how to use it. The instructors in the lab on Thursday did a very good job at explaining it, and I had no real problems after that.
This monday's group meeting was uninteresting, really. I cannot even remember most of what we talked about, so there clearly were no good ideas or possible solutions to the case, and after starting up, it seemed like everyone just did their own thing, and nobody asked anyone for help or anything. Maybe that was just me doing that, but nevertheless, this meeting was, for me, just sitting around and doing something in Flash. I am not one to say that everybody did so, but I feel that I didn't get anything out of the meeting.
Anyway, I managed to finish the case, and I now have a sheep following the Hero.
/end report
Okay, we have been told to be more formal and "report-like" in our reports, but I honestly have no idea how to go about doing that. This report was an attempt to do just that, and I probably failed miserably, but I try.. Oh well, I'll get it right someday.
Oh, and here's the results, the life system is a bit f'***ed up, but once you hit the sheep, it should be okay. You've got 3 lives.
Side-scroller game WIP by ~Andbja on deviantART
Abonner på:
Innlegg (Atom)
