Full Games List
Featured Games
Reviews
Images
Game Updates
Engines
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engine Bulletins
Links
What is Makerscore?
Store
RMN Music Pack
Event History
Achievements
Forums
Post History
Status History
The Latest
RMN TV
#rpgmaker.net IRC
New to RMN?
RMN v4.5 (and beyond) Feature Idea List
2 reviews
Review
Subscribe
Nominate
Submit Media
RSS
Miscellaneous
A RRReview/PRRReview!?
SatedI was browsing around the RRR (RPGRevolution) homepage earlier and I noticed that the latest review section had Sore Losers: Riot Grrrl - Review/Preview at the very top. This came as quite a shock because:
a) The site-section of RRR is poorly designed, making it really hard to find games.
b) All the links I've posted around the internet lead back to RMN as this is the "main" site I visit and as this site has the best gamepage hosting (by a fucking mile).
c) On all three of my gamepages at RRR I have a total of 4 comments, one of which is by me and one of which is by Kentona!
If it wasn't for quite a large chunk of luck I would've never known the review existed since that site has absolutely no system for informing you when someone reviews your game and I long ago stopped checking my gamepages there (after someone rated Sore Losers down to 0.5 stars within minutes of me uploading it there. I know it isn't amazing but 0.5? Seriously? And in such a short timeframe this person clearly hadn't even played the freakin' thing! /nerdrage). I can only assume that the review was posted by someone who saw my Sore Losers: Riot Grrrl thread on the RRR forums and decided they were going to review it, even if it meant interacting with the clunky RRR interface.
Anyway, enough about RRR. The review itself is generally positive and mentions quite a few things I am trying to achieve by developing this game (i.e. making an RM2K3 game look and play a lot less like an RM2K3 game). I think this is good because it shows my efforts aren't going un-noticed. That such efforts are being praised is even better. As for a score, the reviewer gave the tech-demo a score of 7.5 (out of 10) which I think it pretty good for abuggy tech-demo, especially as I know that the section of the game showcase in the tech-demo has improved greatly since it was released (thanks to all your lovely comments!)
If you're interested you can read the review here: Click Me (Link Goes To RRR)
Sidenote: I would actually prefer if people didn't submit formal reviews for this yet since it is just a tech-demo. Comments are appreciated, obviously, I'd just prefer them to stay as comments for now!
a) The site-section of RRR is poorly designed, making it really hard to find games.
b) All the links I've posted around the internet lead back to RMN as this is the "main" site I visit and as this site has the best gamepage hosting (by a fucking mile).
c) On all three of my gamepages at RRR I have a total of 4 comments, one of which is by me and one of which is by Kentona!
If it wasn't for quite a large chunk of luck I would've never known the review existed since that site has absolutely no system for informing you when someone reviews your game and I long ago stopped checking my gamepages there (after someone rated Sore Losers down to 0.5 stars within minutes of me uploading it there. I know it isn't amazing but 0.5? Seriously? And in such a short timeframe this person clearly hadn't even played the freakin' thing! /nerdrage). I can only assume that the review was posted by someone who saw my Sore Losers: Riot Grrrl thread on the RRR forums and decided they were going to review it, even if it meant interacting with the clunky RRR interface.
Anyway, enough about RRR. The review itself is generally positive and mentions quite a few things I am trying to achieve by developing this game (i.e. making an RM2K3 game look and play a lot less like an RM2K3 game). I think this is good because it shows my efforts aren't going un-noticed. That such efforts are being praised is even better. As for a score, the reviewer gave the tech-demo a score of 7.5 (out of 10) which I think it pretty good for a
If you're interested you can read the review here: Click Me (Link Goes To RRR)
Sidenote: I would actually prefer if people didn't submit formal reviews for this yet since it is just a tech-demo. Comments are appreciated, obviously, I'd just prefer them to stay as comments for now!
Miscellaneous
Item System Bug!
What is the bug?
Items used in battle are not removed from their item slots. This means that the game will think you have more items than you actually have if you use items in battle. This is problematic when your pack is full before using an item in battle as the game will continue thinking that your pack is full (even though it no longer is!). If you were then to try and pick up a new item you would be told that your item slots are full (even though they aren't) and will be forced to drop an item in order to pick up a new one.
Fortunately, in the tech-demo you cannot find more than 6 items and so you will not come across an occasion where you need to swap one item for another. As a result, although your pack might show an item being there that is not there, you won't run into any actual gameplay problems. Your pack will just be broken graphically.
Understand all that?
So, you idiot, why are these bugs present?
Testing is important in any game and it looks like I didn't properly test the item-system before releasing the tech-demo.
My original testing involved me using items via the main menu on a specifically designed test-map. Doing it this way, the item-system seemed to keep track of when you used items quite well: It removed the item from the backpack, set that slot of the backpack to empty and didn't take any duplicate items out of the pack. So far, so good.
However, in an extreme oversight, I didn't test what happened if you used an item in battle. This is where the main brunt of the bug comes from as the system is unable to consistently track when you use an item in battle. I say inconsistent because it works sometimes, although more often than not it will not work at all.
What are you doing about it?
First off, the problems have been fixed now. I am telling people about them since these problems are still present in the tech-demo release and I want people to both be aware they are there and to be aware that I already know about them.
Second, I will not be releasing a fixed version of the tech-demo. I don't see any point in releasing a fixed download for something that barely effects the gameplay considering this is only a tech-demo. I will repeat: You cannot find enough items in the tech-demo that you'd ever need to swap one for another so the problem isn't all that prominent - you might become aware of it graphically but it will not effect the gameplay.
Summary
There is a bug present but it shouldn't effect the gameplay in your tech-demo playthrough (I hope).
:)
Items used in battle are not removed from their item slots. This means that the game will think you have more items than you actually have if you use items in battle. This is problematic when your pack is full before using an item in battle as the game will continue thinking that your pack is full (even though it no longer is!). If you were then to try and pick up a new item you would be told that your item slots are full (even though they aren't) and will be forced to drop an item in order to pick up a new one.
Fortunately, in the tech-demo you cannot find more than 6 items and so you will not come across an occasion where you need to swap one item for another. As a result, although your pack might show an item being there that is not there, you won't run into any actual gameplay problems. Your pack will just be broken graphically.
Understand all that?
So, you idiot, why are these bugs present?
Testing is important in any game and it looks like I didn't properly test the item-system before releasing the tech-demo.
My original testing involved me using items via the main menu on a specifically designed test-map. Doing it this way, the item-system seemed to keep track of when you used items quite well: It removed the item from the backpack, set that slot of the backpack to empty and didn't take any duplicate items out of the pack. So far, so good.
However, in an extreme oversight, I didn't test what happened if you used an item in battle. This is where the main brunt of the bug comes from as the system is unable to consistently track when you use an item in battle. I say inconsistent because it works sometimes, although more often than not it will not work at all.
What are you doing about it?
First off, the problems have been fixed now. I am telling people about them since these problems are still present in the tech-demo release and I want people to both be aware they are there and to be aware that I already know about them.
Second, I will not be releasing a fixed version of the tech-demo. I don't see any point in releasing a fixed download for something that barely effects the gameplay considering this is only a tech-demo. I will repeat: You cannot find enough items in the tech-demo that you'd ever need to swap one for another so the problem isn't all that prominent - you might become aware of it graphically but it will not effect the gameplay.
Summary
There is a bug present but it shouldn't effect the gameplay in your tech-demo playthrough (I hope).
:)
Miscellaneous
Skill System and Retries
Skill System
As I mentioned in the last blog, I have started thinking about the best way I can implement the skill system I am going to use in this game. The system itself loosely resembles the skill-trees from Diablo II and there are going to be two branches that Cheska can follow, these being the passive branch and the active branch. Passive skills tend to boost her own stats or lower enemy stats whereas the active branch has her direct-damage skills and status-effect dealing skills.
In and of itself, this is a really simple system to implement. You can use a map-based CMS to map out how the skill-trees look and then use "currency" to purchase new skills on the tree (this is why "currency" is called AP in this game). After checking if the player has enough AP, all I need to do is use a few conditional branches to check if the character has the right pre-requisites. Simples.
How I event the system isn't what I am umm-ing and arr-ing about, though. What I am thinking about is how best to let the player access this system. As I see it, there are three real options I can go for:
- The player can enter the skill-system at all times.
- The player can enter the skill-system at save points.
- The player can enter the skill-system only at the end of a level (this game is level-based).
I don't really want the player to be able to access the skill-system at all times because that will play havok with the way my area-map gameplay works. This means this option is out the window right away, leaving only the other two options...
Doing at the end of a level offers obvious eventing advantages (as it is all self-contained). However, increasing the scope of save-rooms to include the skill-system wouldn't be difficult either. Therefore, from an eventing point of view I have no objection to either system. From a gameplay point of view I believe that there are pro's and con's of both systems and at the end of the day I think they come out fairly equal...
So... What do you guys think? I thought I would ask here to get a bit more of a rounded opinion.
Retries
Another thing I have been thinking about is allowing people to retry battles. This is obviously due to the forum thread discussing this very topic, where popular opinion seemed to fall in the favour of having some sort of retry system.
As I am trying to make all the battles in this game challenging enough that it's possible for them to kill you (this is why HP and SP are fully healed between battles - each battle is meant to be a challenge!) I don't want to turn away players who find the fighting side of things difficult. Offering retries when a player is killed seems to be one way around this.
So far, my idea works like this:
- If the player gets killed by an enemy group they are offered a chance to restart the battle with their HP and SP restored.
- However, as punishment, items they used in the battle are not returned to them (there has to be some sort of penalty for losing a battle - this is better than forcing the player to always reload).
- Alternatively, they can reload the game and keep their items, with the obvious penalty being that they lose their progress.
Good idea? Bad idea?
Progress
Only three more maps of the hotel to go (and one more battle to code in!)
As I mentioned in the last blog, I have started thinking about the best way I can implement the skill system I am going to use in this game. The system itself loosely resembles the skill-trees from Diablo II and there are going to be two branches that Cheska can follow, these being the passive branch and the active branch. Passive skills tend to boost her own stats or lower enemy stats whereas the active branch has her direct-damage skills and status-effect dealing skills.
In and of itself, this is a really simple system to implement. You can use a map-based CMS to map out how the skill-trees look and then use "currency" to purchase new skills on the tree (this is why "currency" is called AP in this game). After checking if the player has enough AP, all I need to do is use a few conditional branches to check if the character has the right pre-requisites. Simples.
How I event the system isn't what I am umm-ing and arr-ing about, though. What I am thinking about is how best to let the player access this system. As I see it, there are three real options I can go for:
- The player can enter the skill-system at all times.
- The player can enter the skill-system at save points.
- The player can enter the skill-system only at the end of a level (this game is level-based).
I don't really want the player to be able to access the skill-system at all times because that will play havok with the way my area-map gameplay works. This means this option is out the window right away, leaving only the other two options...
Doing at the end of a level offers obvious eventing advantages (as it is all self-contained). However, increasing the scope of save-rooms to include the skill-system wouldn't be difficult either. Therefore, from an eventing point of view I have no objection to either system. From a gameplay point of view I believe that there are pro's and con's of both systems and at the end of the day I think they come out fairly equal...
So... What do you guys think? I thought I would ask here to get a bit more of a rounded opinion.
Retries
Another thing I have been thinking about is allowing people to retry battles. This is obviously due to the forum thread discussing this very topic, where popular opinion seemed to fall in the favour of having some sort of retry system.
As I am trying to make all the battles in this game challenging enough that it's possible for them to kill you (this is why HP and SP are fully healed between battles - each battle is meant to be a challenge!) I don't want to turn away players who find the fighting side of things difficult. Offering retries when a player is killed seems to be one way around this.
So far, my idea works like this:
- If the player gets killed by an enemy group they are offered a chance to restart the battle with their HP and SP restored.
- However, as punishment, items they used in the battle are not returned to them (there has to be some sort of penalty for losing a battle - this is better than forcing the player to always reload).
- Alternatively, they can reload the game and keep their items, with the obvious penalty being that they lose their progress.
Good idea? Bad idea?
Progress
Only three more maps of the hotel to go (and one more battle to code in!)
Miscellaneous
Some New Images Etc.
I've added some new images (and replaced some of the older ones) to reflect how things look in the game these days. The new additions basically show off how doors are now shown at the right/left of the screen so you don't have to confirm your movements every time you want to enter or leave a building. This annoyed a couple of people in the demo so this was my solution.
Here are a couple of examples:
As for progress, I am moving slowly through the hotel section and I hope to have it finished over the next couple of weeks (time permitting). After that there are only a couple more maps to put in before the first level is finished. I might use the whole of the first level as the "real" demo before I start working on the other levels, although the skill-system would need to be worked on before any more levels were even considered...
Anyway, it is all looking good. It is just turning out to be a longer task than I had expected. Not that it bothers me! Sore Losers was re-started so many times it basically took me 5 years to make (the actual version I ended up with only took 9 months, but it was far less ambitious than some of the others!)
:)
Here are a couple of examples:
As for progress, I am moving slowly through the hotel section and I hope to have it finished over the next couple of weeks (time permitting). After that there are only a couple more maps to put in before the first level is finished. I might use the whole of the first level as the "real" demo before I start working on the other levels, although the skill-system would need to be worked on before any more levels were even considered...
Anyway, it is all looking good. It is just turning out to be a longer task than I had expected. Not that it bothers me! Sore Losers was re-started so many times it basically took me 5 years to make (the actual version I ended up with only took 9 months, but it was far less ambitious than some of the others!)
:)
Miscellaneous
deviantART Account
http://fallengriever.deviantart.com/
I decided to start posting screenshots etc. for Riot Grrrl on deviantART. You know, to at least try and branch out to a new userbase. I don't know how many people on here actually use deviantART but, if you do, feel free to post your profile below so I can take a look.
I don't expect much to come of this endeavour, if I am honest, but if I spend some time commenting on the "Game Development" pieces on dA then I might manage to get some people to look at my stuff and - in turn - get some people turned on to RMN.
Unlikely, but worth a shot. I guess having a game with a lot of custom resources gives me a better shot than a game with >99% SNES rips, at least!
:)
I decided to start posting screenshots etc. for Riot Grrrl on deviantART. You know, to at least try and branch out to a new userbase. I don't know how many people on here actually use deviantART but, if you do, feel free to post your profile below so I can take a look.
I don't expect much to come of this endeavour, if I am honest, but if I spend some time commenting on the "Game Development" pieces on dA then I might manage to get some people to look at my stuff and - in turn - get some people turned on to RMN.
Unlikely, but worth a shot. I guess having a game with a lot of custom resources gives me a better shot than a game with >99% SNES rips, at least!
:)
Miscellaneous
Comments and Planning
Thanks to everyone who commented on the tech-demo. I've gotten a lot of helpful feedback and I've already implemented some of the ideas that were given to me and fixed some of the problems that were brought up. Players commenting on demo releases is so important if developers are going to get better and release their games in the best state possible so please make sure you all comment on any other games you play too! Everyone knows how I feel about the general lack of feedback around this community (I think) so I won't go on about it too much; I'm just glad I got enough comments to know what needed to be done.
Anyway:
One of the main things brought up was that the indoor levels lacked a little bit of "busy-ness" about them, that they didn't have enough detail, so I've been re-working the panoramas I have used for some of those levels. There are a couple of examples in the screenshot section that you can look at but those need to be updated again because of what I have done to fix another problem that was brought up.
This second problem was that having to confirm your movements all the time was tedious/could get tedious. To remedy this I am adding doors onto all the indoor levels at the sides of the screen that indicate whether or not you are staying in the building/are leaving the building/are going to walk into a wall. How this will look is hard to explain without posting an image so I will do that once they are all complete, but I think it works quite well. And it achieves the aim - the player no longer needs to confirm all their movements. The only confirmation you need to do now is if you have multiple choices.
Another possible problem was a percieved lack of save-points. Everytime you solve a section of a puzzle I am going to have a save-room nearby so you can always save after you have achieved something. This means that if you do get a gameover you shouldn't lose too much progress. I was thinking of implementing a ribbon-style system (ala. the puzzle-based Resident Evil games) but I don't think it would work considering the item-system I am using so I'm not going to bother.
I'm also looking through the areas with instructions so I can make them skippable. I believe at least one person brought that up. That isn't any hassle whatsoever.
As for progress:
I plan on paper first as drawing the levels themselves takes a lot of time and trying to plan things out level-by-level doesn't work too well. I basically plan an area around a solution - something you need to get to. I then work out the puzzles I need to make that solution difficult and base the rooms I use around this. Once I have this I can start planning how levels will link to give an appropriate amount of backtracking and an appropriate amount of minigame-based interaction. Then I can open up MS Paint and start drawing the levels.
Anyway, the battles and areas for the next section are planned and I am going to start implementing them as soon as I have fixed the problems the tech-demo had. The next area could probably do with a couple more minigames considering how many are in the first area but I might not bother - why put them in if not entirely needed? Lockpicking does need to be introduced soon, though, so I will look into that possibility (although I am no longer entirely sure I want to include it, despite it being the favourite minigame in Sore Losers. I probably will end up doing so). The first real puzzle-enemy is also going to be present in this next area, an enemy where you actually have to use interactions in order to stand a chance, so that should be fun (I hope).
:)
Anyway:
One of the main things brought up was that the indoor levels lacked a little bit of "busy-ness" about them, that they didn't have enough detail, so I've been re-working the panoramas I have used for some of those levels. There are a couple of examples in the screenshot section that you can look at but those need to be updated again because of what I have done to fix another problem that was brought up.
This second problem was that having to confirm your movements all the time was tedious/could get tedious. To remedy this I am adding doors onto all the indoor levels at the sides of the screen that indicate whether or not you are staying in the building/are leaving the building/are going to walk into a wall. How this will look is hard to explain without posting an image so I will do that once they are all complete, but I think it works quite well. And it achieves the aim - the player no longer needs to confirm all their movements. The only confirmation you need to do now is if you have multiple choices.
Another possible problem was a percieved lack of save-points. Everytime you solve a section of a puzzle I am going to have a save-room nearby so you can always save after you have achieved something. This means that if you do get a gameover you shouldn't lose too much progress. I was thinking of implementing a ribbon-style system (ala. the puzzle-based Resident Evil games) but I don't think it would work considering the item-system I am using so I'm not going to bother.
I'm also looking through the areas with instructions so I can make them skippable. I believe at least one person brought that up. That isn't any hassle whatsoever.
As for progress:
I plan on paper first as drawing the levels themselves takes a lot of time and trying to plan things out level-by-level doesn't work too well. I basically plan an area around a solution - something you need to get to. I then work out the puzzles I need to make that solution difficult and base the rooms I use around this. Once I have this I can start planning how levels will link to give an appropriate amount of backtracking and an appropriate amount of minigame-based interaction. Then I can open up MS Paint and start drawing the levels.
Anyway, the battles and areas for the next section are planned and I am going to start implementing them as soon as I have fixed the problems the tech-demo had. The next area could probably do with a couple more minigames considering how many are in the first area but I might not bother - why put them in if not entirely needed? Lockpicking does need to be introduced soon, though, so I will look into that possibility (although I am no longer entirely sure I want to include it, despite it being the favourite minigame in Sore Losers. I probably will end up doing so). The first real puzzle-enemy is also going to be present in this next area, an enemy where you actually have to use interactions in order to stand a chance, so that should be fun (I hope).
:)
Miscellaneous
Tech-Demo
I've uploaded the tech-demo. It has around 30 minutes of gameplay depending on your skill, the options you choose to take etc. so it is by no means the longest demo in the world. Nor does it have a load of storyline development since you don't play enough of the game to get into that kind of thing (although this isn't really going to be the most story-heavy game in the world).
However, what it does do is it showcases most of the systems I plan to include in the full version of the game and since my aim is to get feedback on those systems rather than to generate a load of hype then I don't think the length is a problem.
Anyway, if you download it then I hope you enjoy it - and comment lots!
EDIT: I just downloaded the demo and everything seems to be working fine with it. Since it is only a tech-demo I didn't bother uploading an "installation" file like I normally would, I just uploaded a .rar file containing the game folder instead.
However, what it does do is it showcases most of the systems I plan to include in the full version of the game and since my aim is to get feedback on those systems rather than to generate a load of hype then I don't think the length is a problem.
Anyway, if you download it then I hope you enjoy it - and comment lots!
EDIT: I just downloaded the demo and everything seems to be working fine with it. Since it is only a tech-demo I didn't bother uploading an "installation" file like I normally would, I just uploaded a .rar file containing the game folder instead.
Miscellaneous
One Last Cutscene
I basically have to add one last cutscene to the demo before I am ready to release it!
Unfortunately, I don't actually have the will to open up Paint and start drawing it right now. Time-willing I will try and get something done before the weekend and then try and get it finished in the early hours of Saturday night/Sunday morning. At worst I should have it done by the middle of next week and then I just need to add the credits (which will basically be a bunch of message-boxes. I'm not going to stick in flashy credits for a tech-demo).
If I am honest, I haven't actually touched this much since the last blog update and not once in the last three days. I've instead been working on improving the early-demo I released for Headfirst For Halos (my far less innovative project) and playing through Speak No Evil (an awesome game, you should check it out!)
So, next week I will have a tech-demo (hopefully)...
Unfortunately, I don't actually have the will to open up Paint and start drawing it right now. Time-willing I will try and get something done before the weekend and then try and get it finished in the early hours of Saturday night/Sunday morning. At worst I should have it done by the middle of next week and then I just need to add the credits (which will basically be a bunch of message-boxes. I'm not going to stick in flashy credits for a tech-demo).
If I am honest, I haven't actually touched this much since the last blog update and not once in the last three days. I've instead been working on improving the early-demo I released for Headfirst For Halos (my far less innovative project) and playing through Speak No Evil (an awesome game, you should check it out!)
So, next week I will have a tech-demo (hopefully)...
Miscellaneous
Tech-Demo Progress
The tech-demo is pretty much finished, if I am honest, as you can currently play all the way through to where I want the demo to end. However, although the gameplay side of things is pretty much complete, I am still touching up the aesthetic side of things, adding something resembling credits to the end and producing a cutscene that needs to go in the middle of the demo. These things need to be sorted out before I can release the demo.
Technically, none of this should take too long, so if I worked on it flat-out I could probably get the demo out by the end of today. I'm not expecting that to happen, although it very easily could, but I will say that the tech-demo should be out relatively soon (I hope I can keep that "promise"; my record for things like this isn't hopeless but it is inconsistent!)
In the meantime, why don't you take a look at my much-less-serious release, Headfirst For Halos. It is basically a project I am undertaking to learn a little more about balancing (something I know I am weak at) and to give me something to do when I don't want to look at the many complex custom-systems this project has! Give it a chance because, although it isn't going to blow your mind, it is fairly solid.. and if it isn't then you can tell me why and help me get better at my statistic balancing!
Technically, none of this should take too long, so if I worked on it flat-out I could probably get the demo out by the end of today. I'm not expecting that to happen, although it very easily could, but I will say that the tech-demo should be out relatively soon (I hope I can keep that "promise"; my record for things like this isn't hopeless but it is inconsistent!)
In the meantime, why don't you take a look at my much-less-serious release, Headfirst For Halos. It is basically a project I am undertaking to learn a little more about balancing (something I know I am weak at) and to give me something to do when I don't want to look at the many complex custom-systems this project has! Give it a chance because, although it isn't going to blow your mind, it is fairly solid.. and if it isn't then you can tell me why and help me get better at my statistic balancing!
Miscellaneous
Smashing Minigame (Again)
I took Drakonais' advice from the previous blog and decided to work on a minigame that would more accurately represent what you'd have to do when smashing down a door or wall.
The system I came up with is basically a mish-mash of the ideas being thrown around on that blog, the basic idea being that a power-bar fills up and the player has to stop this power bar in the correct region in order to smash down the door. Of course, If let the bar charge too much or stop the bar too early then you fail the minigame and you need to try it again.
As for what happens when you fail, I am slightly undecided. This is as several of these doors are going to be critical to the player progressing through the game and forcing a player to reload just because they failed a single minigame would be pointless; it certainly wouldn't be any fun for the player if they had to reload all the time because of a silly minigame mistake. I guess the best idea is to make it so that storyline-critical doors cannot be permanently failed and non-critical doors can; the player might miss out on a few shiny items if they mess up some doors but they won't end up having to reload if they mess up a storyline-critical door.
On the other hand, this would probably mean having to make it so that the player knows what is going to be permanently destroyed if they fail and what is not, right? Maybe not...
As for the fate of the typing-based minigame mentioned in the previous blog? Simple, it is going to be used for hacking. It certainly won't generate as many negative feelings as the maths-based hacking minigame in Sore Losers did (I'd hope!) and it is already coded in so I wouldn't want it to go to waste!
Anyway, on with making this little demo. I'm actually getting more stuff packed in than I thought I would and it should serve as a good demonstration of what the game is going to be like.
The system I came up with is basically a mish-mash of the ideas being thrown around on that blog, the basic idea being that a power-bar fills up and the player has to stop this power bar in the correct region in order to smash down the door. Of course, If let the bar charge too much or stop the bar too early then you fail the minigame and you need to try it again.
As for what happens when you fail, I am slightly undecided. This is as several of these doors are going to be critical to the player progressing through the game and forcing a player to reload just because they failed a single minigame would be pointless; it certainly wouldn't be any fun for the player if they had to reload all the time because of a silly minigame mistake. I guess the best idea is to make it so that storyline-critical doors cannot be permanently failed and non-critical doors can; the player might miss out on a few shiny items if they mess up some doors but they won't end up having to reload if they mess up a storyline-critical door.
On the other hand, this would probably mean having to make it so that the player knows what is going to be permanently destroyed if they fail and what is not, right? Maybe not...
As for the fate of the typing-based minigame mentioned in the previous blog? Simple, it is going to be used for hacking. It certainly won't generate as many negative feelings as the maths-based hacking minigame in Sore Losers did (I'd hope!) and it is already coded in so I wouldn't want it to go to waste!
Anyway, on with making this little demo. I'm actually getting more stuff packed in than I thought I would and it should serve as a good demonstration of what the game is going to be like.
