What went well: I really shouldn't be surprised when I do a lot of something and it gets easier, but that's exactly what happened. I had a much better idea of how game components fit together and how to implement the stuff I wanted to implement this time around, and I think generally better and more streamlined style. Also, once the mechanics were in place, I had a lot of fun coming up with quirky, interesting, non-trivial levels. Given more time, I bet I could come up with even more! Also, images and sounds!
What went wrong: well it turns out that there's a glitch somewhere in my game that makes you occasionally fall off the map. Huh. And it took a while to come up with a solution to collision that worked--tried a few different tacks before I found one that I was happy with, and even then it required slightly different solutions for horizontal and vertical collisions so that the character didn't get caught on the collision points on top of a tile while moving horizontally across the floor... But really, everything worked out in the end except for that damn misc. bug with the falling off the map. Oh, and I wish I had better sfx for the gravity shifting.
Biggest Surprises: how different this was from my last game. I know that sounds silly, but I'm getting the idea of just how much diversity of programming is possible and it's crazy awesome. Also, how handy the whole tile-based game turned out to be--once I got tiles working, I could pretty much not touch it again and work within that framework, and it was great.
Development time breakdown:
Day 1: grid, walls filled in from a string array, rudimentary horizontal motion (no acceleration), started collision detection (this method of collision detection later got scrapped)
Day 2: continued barking up the wrong tree with crappy collision detection; implemented crappy versions of gravity and jumping
Day 3: started working on a better method of collision detection (checking points on the tile-edge for intersection with the character)
Day 4: figured out collision for real, implemented goal, spikes, and character death
Day 5: made all existing elements readable from 'maps' (arrays of strings representing levels); made up-grav and down-grav tiles and started locks and keys
Day 6: finished locks and keys (corresponding locks & keys, locks fading, etc.), smoothed out switching between levels
Day 7: kill key, smoothed out the kinks in death, changed board size, implemented shift counter, started making levels
Day 8: added sfx, made more levels
Day 9: finished making levels, added victory screen, cleaned up my code
What I would have done differently: be better about planning each day of programming, and actually maintaing an up-to-date implementation plan so I could keep my eye on the bigger picture; not have tried all of those nonworking collision detection things; made more levels.
Had such a blast in this class, and learned a ton. Thanks for everything!!!
Thursday, January 30, 2014
Post-Mortem: Once Upon A Time
Hi everyone,
I'd just like to say how much fun this entire experience was. After long hours of catching up on code that I got behind on I ended up with a really great game. There are a few little score glitches that I will fix, but all of the pictures came together quite well. Also, the only other thing I wish I had had time to implement would be sounds that match the shows. That would be something really easy to do though once I had time to do it.
Anyway this game jam I think went a bit more smoothly coding wise because I used a lot of the techniques that I learned in the previous game jam. For example, I used the benefits of objects a lot more for things that I needed to be selected onClick. Also, it became very useful to have all the dialog in arrays so that I could just go through the array with some counters than having individual strings.
If I could have done things a bit more differently and had a bit more time I would have added a few more minigames to each level. Also, I would have made the text be more reader friendly and I probably would have tried to make the timers on how long the text is on the screen a bit shorter. Implementing a "skip over explanation" feature would have been useful too.
However, other than the days that I missed due to car issues I felt as if my time management was really nice. If I hadn't had to catch up, I might have been able to add some more of the features I wanted.
If I were to do another game jam I would likely make sure that I had a better idea of "necessary" features versus "perfectionistic" features. My time management could have been improved after being set back due to car issues if I had just altered my priorities a bit of what features absolutely needed to be implemented versus the ones I was determined to put in due to my own perfectionistic needs.
Anyway, I had a great time and here are some pictures I used for my game. :)
I'd just like to say how much fun this entire experience was. After long hours of catching up on code that I got behind on I ended up with a really great game. There are a few little score glitches that I will fix, but all of the pictures came together quite well. Also, the only other thing I wish I had had time to implement would be sounds that match the shows. That would be something really easy to do though once I had time to do it.
Anyway this game jam I think went a bit more smoothly coding wise because I used a lot of the techniques that I learned in the previous game jam. For example, I used the benefits of objects a lot more for things that I needed to be selected onClick. Also, it became very useful to have all the dialog in arrays so that I could just go through the array with some counters than having individual strings.
If I could have done things a bit more differently and had a bit more time I would have added a few more minigames to each level. Also, I would have made the text be more reader friendly and I probably would have tried to make the timers on how long the text is on the screen a bit shorter. Implementing a "skip over explanation" feature would have been useful too.
However, other than the days that I missed due to car issues I felt as if my time management was really nice. If I hadn't had to catch up, I might have been able to add some more of the features I wanted.
If I were to do another game jam I would likely make sure that I had a better idea of "necessary" features versus "perfectionistic" features. My time management could have been improved after being set back due to car issues if I had just altered my priorities a bit of what features absolutely needed to be implemented versus the ones I was determined to put in due to my own perfectionistic needs.
Anyway, I had a great time and here are some pictures I used for my game. :)
Post-Mortem -- Dating 101
Hello!
I am here to talk about my experience with the game.
This idea had been in my mind for a while, and I decided to finally make it a reality. Writing the game turned out to be a lot more difficult than I expected, but I managed to pull it through.
My original idea was to have three characters, you could pick where you are going and you would randomly find someone there. That was not how it ended, but it was quite close.
What I am most proud of, is that the game works, and that I have two people. For a while I thought I wouldn't even be able to get one person to work.
What was most difficult was getting the screens to come after each other in the correct moment. There were times where whole screens were skipped, others where you were stuck in the same screen. Not to mention all the random bugs that would appear all over the place for no apparent reason.
The easiest part was doing all the graphics. It surprised me a great deal, since graphics isn't something I am particularly good at. However, the background and images all worked properly, and I didn't have any issues with printing the text.
My daily schedule was the following:
Day 01: Find images and backgrounds
Day 02: Create functions to draw images and print text
Day 03: Write Script and Decision Tree
Day 04: Continue Writing Script and Decision Tree
Day 05: Write all the code for Rinna scenes
Day 06: Write all the code for Mia scenes
Day 07: Nothing works, rewrite all the code for both Mia and Rinna to make debugging easier
Day 08: Debugging and Testing
Overall the game was a success. It isn't the most efficient code in the world; for instance, it would be difficult to add more things to the game without a lot of effort, but it gave me a great amount of experience. Next time I make a dating Sim, I am using a file just as data and then writing very general functions that do everything.
Overall I had a lot of fun and I am very excited for future gamejams. I felt like I learned a lot from this class and I also had a lot of fun.
Best Winter Study so far.
I am here to talk about my experience with the game.
This idea had been in my mind for a while, and I decided to finally make it a reality. Writing the game turned out to be a lot more difficult than I expected, but I managed to pull it through.
My original idea was to have three characters, you could pick where you are going and you would randomly find someone there. That was not how it ended, but it was quite close.
What I am most proud of, is that the game works, and that I have two people. For a while I thought I wouldn't even be able to get one person to work.
What was most difficult was getting the screens to come after each other in the correct moment. There were times where whole screens were skipped, others where you were stuck in the same screen. Not to mention all the random bugs that would appear all over the place for no apparent reason.
The easiest part was doing all the graphics. It surprised me a great deal, since graphics isn't something I am particularly good at. However, the background and images all worked properly, and I didn't have any issues with printing the text.
My daily schedule was the following:
Day 01: Find images and backgrounds
Day 02: Create functions to draw images and print text
Day 03: Write Script and Decision Tree
Day 04: Continue Writing Script and Decision Tree
Day 05: Write all the code for Rinna scenes
Day 06: Write all the code for Mia scenes
Day 07: Nothing works, rewrite all the code for both Mia and Rinna to make debugging easier
Day 08: Debugging and Testing
Overall the game was a success. It isn't the most efficient code in the world; for instance, it would be difficult to add more things to the game without a lot of effort, but it gave me a great amount of experience. Next time I make a dating Sim, I am using a file just as data and then writing very general functions that do everything.
Overall I had a lot of fun and I am very excited for future gamejams. I felt like I learned a lot from this class and I also had a lot of fun.
Best Winter Study so far.
Game Jam Post Mortem
Post Mortem:
Figuring out the animations for the boss ended up taking alot longer than expected. The sprite sheet for the boss was not clearly laid out, which meant that I had to manually discover the pixel dimensions for each animation. Animating the minor enemies went much more smoothly than expected. The biggest surprise was probably how my game was not as complete as I wanted it to be, because I thought I would have been able to accomplish much more. However the game itself looks pretty cool, and I thoroughly enjoyed making it. If I were to go back and do it again, I think I would completely change the gameplay design. The game as it is right now does not feel as fun as I thought it would be because the gameplay is pretty repetitive. I would also more carefully plan out the artwork I used so that the theme of the game would be more uniform. The artwork and the gameplay had no real focus, and certainly did not match my original theme of an alcoholic superhero.
I spent my time in the second half of the Game Jam first replacing the rectangles with animated enemy sprites. I then created the checkpoint platform and got the camera to freeze at the checkpoint and lock the player in. I then found the boss sprite and animated the three moves he cycled between. I then implemented the gameplay interactions of his three moves. Finally I added death animations for the enemies and implemented more power ups and their corresponding images.
Nick Wolf out.
Figuring out the animations for the boss ended up taking alot longer than expected. The sprite sheet for the boss was not clearly laid out, which meant that I had to manually discover the pixel dimensions for each animation. Animating the minor enemies went much more smoothly than expected. The biggest surprise was probably how my game was not as complete as I wanted it to be, because I thought I would have been able to accomplish much more. However the game itself looks pretty cool, and I thoroughly enjoyed making it. If I were to go back and do it again, I think I would completely change the gameplay design. The game as it is right now does not feel as fun as I thought it would be because the gameplay is pretty repetitive. I would also more carefully plan out the artwork I used so that the theme of the game would be more uniform. The artwork and the gameplay had no real focus, and certainly did not match my original theme of an alcoholic superhero.
I spent my time in the second half of the Game Jam first replacing the rectangles with animated enemy sprites. I then created the checkpoint platform and got the camera to freeze at the checkpoint and lock the player in. I then found the boss sprite and animated the three moves he cycled between. I then implemented the gameplay interactions of his three moves. Finally I added death animations for the enemies and implemented more power ups and their corresponding images.
Nick Wolf out.
Post Mortem 2
So, like last game jam, I think that this one went very well, if not entirely to plan.
Idea : Fire Emblem X Pokemon
Result: Fire Emblem engine
Though in past game jams, I have made very ugly games that were 100% about the mechanics before, this game I decided to bring in some pretty elements, including a non-zero number of assets (tiles and sprites, yeah). This prevented me from being able to add any game play features above the base Fire Emblem level (like the pokemon-esque leveling / capturing I had envisioned), but resulted in what I think was a very reasonable product, and something that is able to look more finished than it perhaps is due to that layer of "looking right".
The only major issue is that this game jam became an "engine jam", which very little game play put onto a fully functional engine. I am entirely content with this though, as I know have something that I can build on either in my free time or, because I am unlikely to have terribly much of that next semester, in another game jam. And my idea was really too big at the beginning to become a terribly fun game if I focused on gaminess, so a fully functional engine is very satisfying. There are plenty of game features left to be added, but I have enough infrastructure now that it could become much more fun very quickly by writing very few lines of code, but instead designing maps and such.
What this game jam taught me was probably that assets are not evil, and it's probably worth the effort to pretty up a game somewhat...though my game does have some performance issues brought on by it's prettiness that I should try to at some point fix.
Both of the game jams for this class were both quite fun and educational, and I think rather successful. Everyone won the game jam (winning is defined as completion of a game), so that is very good, and hopefully my games will become more game-like with a bit more work. Also, after these game jams, I have gotten pretty familiar with Javascript and Codeheart, so, despite their flaws, I have the skills necessary to be able to work efficiently with them on future game jams. Unless I decide to do the next one in Dart and WebGL, because why not?
Idea : Fire Emblem X Pokemon
Result: Fire Emblem engine
Though in past game jams, I have made very ugly games that were 100% about the mechanics before, this game I decided to bring in some pretty elements, including a non-zero number of assets (tiles and sprites, yeah). This prevented me from being able to add any game play features above the base Fire Emblem level (like the pokemon-esque leveling / capturing I had envisioned), but resulted in what I think was a very reasonable product, and something that is able to look more finished than it perhaps is due to that layer of "looking right".
The only major issue is that this game jam became an "engine jam", which very little game play put onto a fully functional engine. I am entirely content with this though, as I know have something that I can build on either in my free time or, because I am unlikely to have terribly much of that next semester, in another game jam. And my idea was really too big at the beginning to become a terribly fun game if I focused on gaminess, so a fully functional engine is very satisfying. There are plenty of game features left to be added, but I have enough infrastructure now that it could become much more fun very quickly by writing very few lines of code, but instead designing maps and such.
What this game jam taught me was probably that assets are not evil, and it's probably worth the effort to pretty up a game somewhat...though my game does have some performance issues brought on by it's prettiness that I should try to at some point fix.
Both of the game jams for this class were both quite fun and educational, and I think rather successful. Everyone won the game jam (winning is defined as completion of a game), so that is very good, and hopefully my games will become more game-like with a bit more work. Also, after these game jams, I have gotten pretty familiar with Javascript and Codeheart, so, despite their flaws, I have the skills necessary to be able to work efficiently with them on future game jams. Unless I decide to do the next one in Dart and WebGL, because why not?
Post Mortem 2 Kyle
Post Mortem II
I feel that this second game jam was significantly more productive since I had finished transferring over from BlueJ and the Objectdraw library. The two major problems I ran into were making the polygon cutting to work in a glitch free manner and switching from the pixel units I was using into meter units. Other than that, most of my time was spent moving forward and implementing the different spell types that I was able to showcase today. Most of the development time I spent on this aspect of the game had to do with NullPointer issues and broken polygons that resulted from minor glitches in my spell code. Another issue I ran into when coding the spells was simply thinking about how I would restructure my code. My code is somewhat rigid, and new features I add typically break the order and rules I set down for structure and organization. A good deal of my productivity during the second game jam is due to the fact that I never ran into a really major error like the Polygon cutting.
At this point, I have the basic framework for the game I want to make. Most of the necessary spells are in, and while I still have two to three more spells in mind, the only really hard one I want to implement is to have some kind of control spell that queries all nearby shapes and allows you to throw me at a given location. The query function for this spell could be hard, as I don't want the player to throw polygons that are lodged in places he can't even reach.
From a code point of view, I still need to do some clean up work. One problem is with the long collision detection system. What I need is an interface for collidable objects. The contactListener will just call the collision method of any object that collides, allowing for much faster collision registering.
Some errors still lurk. A somewhat rare error is the lost polygon exception. Occasionally a polygon will be barely self intersecting, leading to a triangulation error. I currently dump the polygon...
Another error is with self containment. If an object is spawned in another object, it tends to slow the game down. If it cuts the polygon that it is contained in, the game glitches and instead spawns another object with the explosion shape, leading to further slowdown.
Really excited about working on this project though. I think I have a good framework to work off of for these coming months. A future problem right now is with implementing the graphics side of the game. I don't have a specific art style in mind, and the art effects for spells will be tricky to get right.
I feel that this second game jam was significantly more productive since I had finished transferring over from BlueJ and the Objectdraw library. The two major problems I ran into were making the polygon cutting to work in a glitch free manner and switching from the pixel units I was using into meter units. Other than that, most of my time was spent moving forward and implementing the different spell types that I was able to showcase today. Most of the development time I spent on this aspect of the game had to do with NullPointer issues and broken polygons that resulted from minor glitches in my spell code. Another issue I ran into when coding the spells was simply thinking about how I would restructure my code. My code is somewhat rigid, and new features I add typically break the order and rules I set down for structure and organization. A good deal of my productivity during the second game jam is due to the fact that I never ran into a really major error like the Polygon cutting.
At this point, I have the basic framework for the game I want to make. Most of the necessary spells are in, and while I still have two to three more spells in mind, the only really hard one I want to implement is to have some kind of control spell that queries all nearby shapes and allows you to throw me at a given location. The query function for this spell could be hard, as I don't want the player to throw polygons that are lodged in places he can't even reach.
From a code point of view, I still need to do some clean up work. One problem is with the long collision detection system. What I need is an interface for collidable objects. The contactListener will just call the collision method of any object that collides, allowing for much faster collision registering.
Some errors still lurk. A somewhat rare error is the lost polygon exception. Occasionally a polygon will be barely self intersecting, leading to a triangulation error. I currently dump the polygon...
Another error is with self containment. If an object is spawned in another object, it tends to slow the game down. If it cuts the polygon that it is contained in, the game glitches and instead spawns another object with the explosion shape, leading to further slowdown.
Really excited about working on this project though. I think I have a good framework to work off of for these coming months. A future problem right now is with implementing the graphics side of the game. I don't have a specific art style in mind, and the art effects for spells will be tricky to get right.
Post Mortem
Overall, I found the game jam to be fun and valuable
I learned javascript
I made a couple of games
What went well:
Creating a camera definitely made keeping track of the coordinate system easier than last time. With that sorted out I was able to simply center the camera "object" on the user and not think about it for the rest of the game jam
Not worrying about art made the game considerably less stressful. I see why art is usually the last element to be added.
Items and item acquisition with the camera/coordinate system was a relatively easy thing to implement, although they are not pretty to see.
The game itself was all right. I was able to implement a trait system which works, as well as three AI types. The gameplay, however, is very poor.
What did not:
The gameplay needs work. By this I am referring to the speed with which the characters move, the amount of time it takes to kill a character and the movements of the characters throughout the world.
The speed. With the trait system I need a variable speed which would scale fairly based on how many trait points were allocated to the speed stat. This worked for the most part, but because there are no boundaries to the game characters would take off across the map never to be seen again. In theory they would return, but because the attack was too weak it took a very long time. The final of my game has a tenuously balanced speed/attack ratio.
What I would do differently:
Planning. I found myself completing my original plan early. A more rigorous plan would have pushed and aided me towards a more complicated and tune result.
I also might make my next game turn-based.
What I took away from the experience:
It was a good experience. And a great way to spend winter study. I am sure that I will continue making games.
Thanks Mike.
I learned javascript
I made a couple of games
What went well:
Creating a camera definitely made keeping track of the coordinate system easier than last time. With that sorted out I was able to simply center the camera "object" on the user and not think about it for the rest of the game jam
Not worrying about art made the game considerably less stressful. I see why art is usually the last element to be added.
Items and item acquisition with the camera/coordinate system was a relatively easy thing to implement, although they are not pretty to see.
The game itself was all right. I was able to implement a trait system which works, as well as three AI types. The gameplay, however, is very poor.
What did not:
The gameplay needs work. By this I am referring to the speed with which the characters move, the amount of time it takes to kill a character and the movements of the characters throughout the world.
The speed. With the trait system I need a variable speed which would scale fairly based on how many trait points were allocated to the speed stat. This worked for the most part, but because there are no boundaries to the game characters would take off across the map never to be seen again. In theory they would return, but because the attack was too weak it took a very long time. The final of my game has a tenuously balanced speed/attack ratio.
What I would do differently:
Planning. I found myself completing my original plan early. A more rigorous plan would have pushed and aided me towards a more complicated and tune result.
I also might make my next game turn-based.
What I took away from the experience:
It was a good experience. And a great way to spend winter study. I am sure that I will continue making games.
Thanks Mike.
Subscribe to:
Comments (Atom)