I have finally gotten around to finishing the title screens for the 1.1 version of Modern Melee Combat. As I mentioned in an earlier post, this updated version of the game supports keyboard shortcuts, has much faster game play due to the re-worked animation subsystem, and it has a proper title screen. Now that the title screen is finished, I am able to post the new code to the repository. Of course, this is only the original arenas. A new set of arenas (and a separate title screen so you can tell which version you are playing) will be released this Friday. The difficulty has been ramped up quite a bit. I am sure that there will still be a number of people who complain that it is still too easy, but I am not a glutton for punishment.
Speaking of game difficulty, I keep hearing people insist that older video games are so much harder than the modern games. While I do remember that some games were hard, I didn't think that there was that huge of a difference and most of the difficulty claims were probably due to the fact that after playing games for years the player has simply gotten better at playing games. A few weeks ago I decided to try some of the more difficult retro games that were available on my Wii virtual console. My conclusion is that the older games are harder, but not because they are more difficult. They are harder because they do not have proper save systems so you end up playing the same sequence over and over again. This is probably a requirement of the game as without this false difficulty, players would quickly discover that the game they paid a lot of money for was over in only a couple of hours.
Showing posts with label Modern Melee Combat. Show all posts
Showing posts with label Modern Melee Combat. Show all posts
Tuesday, June 5, 2007
Saturday, June 2, 2007
The Battle has just Began
I have just finished adding some new features to Modern Melee Combat, which I will post to the ultimate retro project repository as soon as I finish the title screen artwork. The animation subsystem has been overhauled, so the game can be played significantly faster as you no longer will have to wait until the monster animation is finished before making your next move. This was the biggest complaint I have received for both Melee Combat and for Dungeon Romp. There are now keyboard shortcuts for all of the commands in the game. Finally, the game will have a title screen. The other complaint I have got about Melee Combat was that it was too easy. This is more of a configuration file issue than a programming issue, but I plan on creating a second configuration file that would have a much more challenging set of arenas in it. This will probably be released on the 8th.
Dungeon Romp fans will also be treated to an overhauled version. Work on this will not be started until I have put at least 10 hours into Coffee Quest Revenge. Once I have a version with the faster gameplay implemented, it will replace the existing version on the site. A more difficult dungeon is planned, though that will not be released until there is a free week in my release schedule. Depending on how quickly CQR development is, this could be this month, but may not be until July.
The last couple of posts I talked about DRM free music through iTunes. With DRM free music now available, I immediately purchased a copy of Smashing Pumpkins: Mellon Collie and the Infinite Sadness on May 30th. Last night (okay, technically early this morning before I went to bed) when I looked at the other Smashing Pumpkin titles available, I noticed that they were no longer available as iTunes Plus albums. This included the album that I purchased the other day. The copy I got was definitely DRM free 256 bit, which leads me to wonder what is going on? My fear is that some bands want to treat their paying customers like criminals. I wrote Apple to find out, but I doubt I will even get a reply from them. If I do find out that it was the band's choice to not allow DRM Free versions, I will simply have to quit supporting the band. In fact, I think from now on, the only bands that I will support are bands that have DRM Free music available.
Dungeon Romp fans will also be treated to an overhauled version. Work on this will not be started until I have put at least 10 hours into Coffee Quest Revenge. Once I have a version with the faster gameplay implemented, it will replace the existing version on the site. A more difficult dungeon is planned, though that will not be released until there is a free week in my release schedule. Depending on how quickly CQR development is, this could be this month, but may not be until July.
The last couple of posts I talked about DRM free music through iTunes. With DRM free music now available, I immediately purchased a copy of Smashing Pumpkins: Mellon Collie and the Infinite Sadness on May 30th. Last night (okay, technically early this morning before I went to bed) when I looked at the other Smashing Pumpkin titles available, I noticed that they were no longer available as iTunes Plus albums. This included the album that I purchased the other day. The copy I got was definitely DRM free 256 bit, which leads me to wonder what is going on? My fear is that some bands want to treat their paying customers like criminals. I wrote Apple to find out, but I doubt I will even get a reply from them. If I do find out that it was the band's choice to not allow DRM Free versions, I will simply have to quit supporting the band. In fact, I think from now on, the only bands that I will support are bands that have DRM Free music available.
Tuesday, May 1, 2007
Making One of those Weeks episode 14, part 3
More of Melee Combat has been posted. I have uncovered a few minor bugs, but nothing major yet so the chance of release this week is really good still. This means that the few people who follow this blog will be getting the next chapter of Making One of those Weeks at least a week early. Lets finish off the chapter.
Rendering a forest is the same as rendering other three-dimensional views, except the walls are trees. This actually makes the rendering easier. The trees I use are symmetrical. This means that unlike a wall, all the different views (left, right and center) of the tree are the same image. This makes a three dimensional forest very easy to draw.
To help with the variety of the forest, I tried to have three slightly different kinds of trees. The first tree is the normal tree. The other two are a taller version and a fatter version. While some people may have noticed the different trees, most people didn't notice any difference. In other words, a better approach at getting variety in the trees would have been to use three distinctly different looking trees.
One thing that I never even considered doing would be to grow the trees algorithmically. This is largely because the short amount of time that I have allocated to the creation of these episodes. Randomly generated trees could easily be seeded based on their location within the map, so every time the level is played, the trees would look the same. The quality of the trees could also be based on how fast the computer is, so faster computers could have more tree generation iterations, though I have never actually written an algorithm to generate a conifer (though I have written generators for deciduous trees and ferns) but I have seen such generators.
Because the renderer is the same one used in the earlier game, just with a different tile set for the "walls", there is no real need to go into the code of the game. The only real difference is that I added an additional depth level allowing the player to see deeper into the forest.
Rendering a forest is the same as rendering other three-dimensional views, except the walls are trees. This actually makes the rendering easier. The trees I use are symmetrical. This means that unlike a wall, all the different views (left, right and center) of the tree are the same image. This makes a three dimensional forest very easy to draw.
To help with the variety of the forest, I tried to have three slightly different kinds of trees. The first tree is the normal tree. The other two are a taller version and a fatter version. While some people may have noticed the different trees, most people didn't notice any difference. In other words, a better approach at getting variety in the trees would have been to use three distinctly different looking trees.
One thing that I never even considered doing would be to grow the trees algorithmically. This is largely because the short amount of time that I have allocated to the creation of these episodes. Randomly generated trees could easily be seeded based on their location within the map, so every time the level is played, the trees would look the same. The quality of the trees could also be based on how fast the computer is, so faster computers could have more tree generation iterations, though I have never actually written an algorithm to generate a conifer (though I have written generators for deciduous trees and ferns) but I have seen such generators.
Because the renderer is the same one used in the earlier game, just with a different tile set for the "walls", there is no real need to go into the code of the game. The only real difference is that I added an additional depth level allowing the player to see deeper into the forest.
Monday, April 30, 2007
Making One of those Weeks episode 14, part 2
More of Modern Melee Combat has been posted to the repository. The game is playable, but not fully tested. Still, unless I discover a major bug in the next few days, the game will be released this Friday. Being burned in the past when I didn't have an alternative ready, I am going to continue working on my Making of One of those Weeks chapter in this and in tomorrows posts. So, lets get on with the chapter.
As this episode takes place in a forest, we obviously need a way to create a forest. There are at least three ways that this can be done. My three methods are build the forest by hand, import an existing forest, or randomly generate a forest.
Building a forest by hand is time consuming, but not overly difficult. My 3D sequences are actually two dimensional maps extruded into the third dimension. As such, the forest is a simple tile map with three different tiles used to represent different shapes of trees, one tile to represent ground, one tile to represent sand, one tile for the river, one tile for Charles, and one tile for the cave. My Coffee Quest Construction Set was used to quickly build the tile map. That being said, even if the map was truly three dimensional, the task would not have been that much more difficult. The 3D map editor would probably allow tree objects to be placed anywhere. Some ground would have had to be created, but then the placing of trees would work out pretty much the same way as it did for the tile based construction set.
Importing an existing forest is certainly possible. You would have to find a map of the forest that you wanted to use for the game. You would also need to be able to either convert the map into a file format that your game could use or write your game to be able to handle the format that the map data is in. For a game like this, the time saved using an existing map is probably more than offset by the time converting the map. That being said, if your game was set in a real world location and you had legal access to map data, this could be a real time saving way of getting level data for the game.
The final method that I was thinking about was a randomly generated forest. I have done maze generators in the past (see the Ultimate Retro Project Maze and Dungeon Romp games) so I know that this is not that difficult of a task. A random map may add a small amount of replay ability to the game, but it does remove the consistency of the episode. Hand crafting a map gives the designer a bit more control over the flow of the map than any generated map does, but randomness is an option that as a game designer you may want to consider.
As this episode takes place in a forest, we obviously need a way to create a forest. There are at least three ways that this can be done. My three methods are build the forest by hand, import an existing forest, or randomly generate a forest.
Building a forest by hand is time consuming, but not overly difficult. My 3D sequences are actually two dimensional maps extruded into the third dimension. As such, the forest is a simple tile map with three different tiles used to represent different shapes of trees, one tile to represent ground, one tile to represent sand, one tile for the river, one tile for Charles, and one tile for the cave. My Coffee Quest Construction Set was used to quickly build the tile map. That being said, even if the map was truly three dimensional, the task would not have been that much more difficult. The 3D map editor would probably allow tree objects to be placed anywhere. Some ground would have had to be created, but then the placing of trees would work out pretty much the same way as it did for the tile based construction set.
Importing an existing forest is certainly possible. You would have to find a map of the forest that you wanted to use for the game. You would also need to be able to either convert the map into a file format that your game could use or write your game to be able to handle the format that the map data is in. For a game like this, the time saved using an existing map is probably more than offset by the time converting the map. That being said, if your game was set in a real world location and you had legal access to map data, this could be a real time saving way of getting level data for the game.
The final method that I was thinking about was a randomly generated forest. I have done maze generators in the past (see the Ultimate Retro Project Maze and Dungeon Romp games) so I know that this is not that difficult of a task. A random map may add a small amount of replay ability to the game, but it does remove the consistency of the episode. Hand crafting a map gives the designer a bit more control over the flow of the map than any generated map does, but randomness is an option that as a game designer you may want to consider.
Sunday, April 29, 2007
Making One of those Weeks 14, part 1
While Modern Melee Combat is now starting to come together into a playable game, there are no guarantees that the game will be finished by Thursday evening. Still, I am now at the point where the code that I have developed can start to be posted to the ultimateretroproject.dev.java.net repository. I don't want to dump a huge chunk of code all at once, so am going to be releasing the code to the repository in a series of logical chunks. I took so long getting to this point because I had a bunch of different parts of the game partially done. I don't like releasing non-functioning code and don't like bothering with branches unless there is a pressing need to do so. While at the moment it looks like there is a really high chance of meeting the Thursday deadline, I am not going to take chances so over the next few days will be writing the next chapter of Making of One of those Weeks Chapter 14. The rough draft will appear in this blog, so the few of you who care about this eBook will get to read it early. This assumes that the people who care about books on game development would read a blog about game development, but my guess is that covers a number of the eBook's readers.
Episode 14 revolves around navigating through a forest. The auto-map feature was not ready at this time, so the player has to deal with mapping themselves. To aid with self-made maps, there is a coordinate displayed on the top of the display. For those of you who do not want to make a map, below is a copy of the map with a path to the ending location in red.
There are actually two separate goals in this episode. The required goal is to reach a point where you can cross the river. The optional goal is to find the cave. The path in the map above only shows the route to the river crossing. The cave is the grey square. It is not too hard to find on your own. Going to the cave adds to the final score for the episode. This cave is very important in future episodes of the game, though is only acknowledged in this episode.
Episode 14 revolves around navigating through a forest. The auto-map feature was not ready at this time, so the player has to deal with mapping themselves. To aid with self-made maps, there is a coordinate displayed on the top of the display. For those of you who do not want to make a map, below is a copy of the map with a path to the ending location in red.
There are actually two separate goals in this episode. The required goal is to reach a point where you can cross the river. The optional goal is to find the cave. The path in the map above only shows the route to the river crossing. The cave is the grey square. It is not too hard to find on your own. Going to the cave adds to the final score for the episode. This cave is very important in future episodes of the game, though is only acknowledged in this episode.
Thursday, April 19, 2007
Adobe Hates Me
As visitors to BlazingGames.com have already found out, I am not quite ready to post Modern Melee Combat. What I did not tell the visitors to the site, even if I finish it in time to release it next week, it will not be next week's game. My current plans for next week is to post the next episode of One of those Weeks if I get it finished in time. What I was hoping to have happen is that I would get CS3 by the end of this week and then be able to have the next episode be the first episode that uses ActionScript3. Considering that the last time I checked, Adobe hasn't even mailed my copy of CS3 (which I pre-ordered on the day it was announced). The suite I ordered has been out for 4 days now, so I really don't understand why this would be the case but once I finish all the games I have planned for Flash, which will probably take a couple of years, I will seriously consider switching to a company that actually cares about it's customers. Perhaps if I am really lucky, there will be open standards that are actually implemented in a majority of the browsers by then. In the past, VRML looked like a potential contender, but it never really took off. A real contender needs to be something that will work in the majority of browsers.
So what is going to happen with One of those Weeks? I have decided that if I don't have a copy of Flash CS3 by the end of Friday (after all, it is possible that my copy of CS3 was shipped but the order status was not updated) then I will create the final three episodes of Day 4 in Flash 8. I will not do any other non-paying Flash work until I get Flash CS3. Day 4 will also be the last day of One of those Weeks that I will work on outside of the 20 hours a week allocated to the Blazing Games site. Day 5 through 7 will be voted on, meaning that the series may be released more frequently than once a month but could be less frequent if voters decide they prefer something else.
So what is going to happen with One of those Weeks? I have decided that if I don't have a copy of Flash CS3 by the end of Friday (after all, it is possible that my copy of CS3 was shipped but the order status was not updated) then I will create the final three episodes of Day 4 in Flash 8. I will not do any other non-paying Flash work until I get Flash CS3. Day 4 will also be the last day of One of those Weeks that I will work on outside of the 20 hours a week allocated to the Blazing Games site. Day 5 through 7 will be voted on, meaning that the series may be released more frequently than once a month but could be less frequent if voters decide they prefer something else.
Subscribe to:
Posts (Atom)
