Full Games List
Featured Games
New Games
Reviews
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Boulevard of Broken 2k3 Dreams has started!
Past Events
Achievements
Forums
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
2 reviews
Add Review
Subscribe
Nominate
Submit Media
RSS
Progress Report
Crawling Through Vents, Fighting With Words and Taking Stock
Sated
I haven't really done any work on this game since Fallout 4 came out back in November. Fallout 4 took up most of my free-time throughout November and December, with the rest being taken up by all the shopping and parties and dinners and general-get-togethers that Christmas brings with it. It's been a fun couple of months (some random bouts of nausea aside, but I'm taking medication for that now!) but it's really time that I start working on this project again. Not that I don't find working on this game fun, it's just that I've really saddled myself with a lot of tedious tasks to do. In any case, I really want to get this project finished by the end of this year. It's been going on for far too long now, it's actually kinda ridiculous!
Crawling Through Vents
People who actively follow the "Whatchu Workin' On?" thread will remember that I was working on the vent-crawling minigame back at the start of November. These sections are handled in a style similar to the dungeons in the first Phantasy Star game, in that you're shown a first-person view of what's immediately in front of you and then get to choose which direction you want to travel in. It's really easy to get lost in these areas, so it's really up to the player to keep careful track of where they're going so that they don't end up going in circles, and that's where the challenge in these sections comes from. Hopefully people aren't too put-off by what is a fairly old-school approach to labyrinthine puzzle design, but I've always liked dungeons that are set up in this kind of manner.
What I've basically done is update the graphics for the vent-crawling minigame so that it has an overlay like all the other minigames do. This means that I don't need a message-box based tutorial, since those are kinda boring and also feel pretty damn cheap. I also needed to tweak how the images were displayed because the wait-time between them was far too long, and I've also updated how the vents look since they were pretty ugly previously. It was never going to be something that would take a long time but I'm happy that it's done. Here's are some images that I hope is self-explanatory, with the second image showing an example of a new sewer-tunnel minigame that works in exactly the same manner:
Fighting With Words
Another thing that I've been doing is bringing the "convobattles" (which are basically rock-paper-scissors in how they work) in line with the aesthetic applied to all the other minigames. This actually entailed a lot of work, more than I was originally expecting when I set out to make these improvements. When the "convobattles" were first implemented, only dialogue from the opponent that continued the "convobattle" was shown as an image. All other text was shown using a normal message box, including all instances of Cheska's speech during these "convobattles". This meant that each "convobattle" only needed 3-5 images producing. When I started updating the graphics, I quickly decided that all the dialogue should be shown in speech bubbles so that the same aesthetic was maintained throughout the course of the whole "convobattle", which meant that loads of new images needed to be created. It ended up being pretty tedious work, but I'm happy with the results!
I'm also happy to say that all the "convobattles" in the game have now been updated, which was something I only just finished doing on New Year's Day. The ability to avoid combat by getting these minigames right is going to play a big role in how different players end up experiencing this game, because many battles can be avoided if you get the associated "convobattle" right. I'm not currently planning to have your success rate in "convobattles" have an affect on the ending, but it's something that has come to mind in the past. Definitely something for me to think about as I come to implement the closing scenes of the game!
Taking Stock
All the blog posts I've made since starting to work on development of this game again have been about updating things that were already implemented. Whether that meant replacing minigames with whole new minigames, updating graphics or simply adding more instances of under-utilised minigames, I've essentially done a lot of work without getting any closer to finishing this game. But that's okay! Why? Because this game is a hell of a lot better now than it was when I came back to developing it!
I'm pretty happy with where the project stands at the moment, but my next target is probably my most important since my next target is the battle-system. Frankly, the "interaction" system I've implemented needs to work a hell of a lot smoother and I'm sure that it can. It seems a long time ago that I was updating all the battle-animations, but I'm pretty damn happy with them and there's definitely nothing wrong with how the battle-system works from a traditional RPG stand-point. It's just that the "interaction" mechanic is the one mechanic that's meant to differentiate Sore Losers: Riot Grrrl from other RPGs with turn-based battle-systems. It's supposed to reward you for being inquisitive a lot more than it currently does. The mechanic is severely under-utilised and, if I'm being perfectly honest, it's implemented in a very cheap manner. Simply put...
MUST. DO. BETTER.
Crawling Through Vents
People who actively follow the "Whatchu Workin' On?" thread will remember that I was working on the vent-crawling minigame back at the start of November. These sections are handled in a style similar to the dungeons in the first Phantasy Star game, in that you're shown a first-person view of what's immediately in front of you and then get to choose which direction you want to travel in. It's really easy to get lost in these areas, so it's really up to the player to keep careful track of where they're going so that they don't end up going in circles, and that's where the challenge in these sections comes from. Hopefully people aren't too put-off by what is a fairly old-school approach to labyrinthine puzzle design, but I've always liked dungeons that are set up in this kind of manner.
What I've basically done is update the graphics for the vent-crawling minigame so that it has an overlay like all the other minigames do. This means that I don't need a message-box based tutorial, since those are kinda boring and also feel pretty damn cheap. I also needed to tweak how the images were displayed because the wait-time between them was far too long, and I've also updated how the vents look since they were pretty ugly previously. It was never going to be something that would take a long time but I'm happy that it's done. Here's are some images that I hope is self-explanatory, with the second image showing an example of a new sewer-tunnel minigame that works in exactly the same manner:
Fighting With Words
Another thing that I've been doing is bringing the "convobattles" (which are basically rock-paper-scissors in how they work) in line with the aesthetic applied to all the other minigames. This actually entailed a lot of work, more than I was originally expecting when I set out to make these improvements. When the "convobattles" were first implemented, only dialogue from the opponent that continued the "convobattle" was shown as an image. All other text was shown using a normal message box, including all instances of Cheska's speech during these "convobattles". This meant that each "convobattle" only needed 3-5 images producing. When I started updating the graphics, I quickly decided that all the dialogue should be shown in speech bubbles so that the same aesthetic was maintained throughout the course of the whole "convobattle", which meant that loads of new images needed to be created. It ended up being pretty tedious work, but I'm happy with the results!
I'm also happy to say that all the "convobattles" in the game have now been updated, which was something I only just finished doing on New Year's Day. The ability to avoid combat by getting these minigames right is going to play a big role in how different players end up experiencing this game, because many battles can be avoided if you get the associated "convobattle" right. I'm not currently planning to have your success rate in "convobattles" have an affect on the ending, but it's something that has come to mind in the past. Definitely something for me to think about as I come to implement the closing scenes of the game!
Taking Stock
All the blog posts I've made since starting to work on development of this game again have been about updating things that were already implemented. Whether that meant replacing minigames with whole new minigames, updating graphics or simply adding more instances of under-utilised minigames, I've essentially done a lot of work without getting any closer to finishing this game. But that's okay! Why? Because this game is a hell of a lot better now than it was when I came back to developing it!
I'm pretty happy with where the project stands at the moment, but my next target is probably my most important since my next target is the battle-system. Frankly, the "interaction" system I've implemented needs to work a hell of a lot smoother and I'm sure that it can. It seems a long time ago that I was updating all the battle-animations, but I'm pretty damn happy with them and there's definitely nothing wrong with how the battle-system works from a traditional RPG stand-point. It's just that the "interaction" mechanic is the one mechanic that's meant to differentiate Sore Losers: Riot Grrrl from other RPGs with turn-based battle-systems. It's supposed to reward you for being inquisitive a lot more than it currently does. The mechanic is severely under-utilised and, if I'm being perfectly honest, it's implemented in a very cheap manner. Simply put...
MUST. DO. BETTER.
Progress Report
Lockpicking and Hotwiring
Lockpicking
It wouldn't be a Sore Losers game without a lockpicking minigame... right? Well here it is, and I'm sure people who played the original Sore Losers will recognise most of the graphical assets used.
I originally only made the control overlay at the bottom, but it thought it looked kinda silly since it covered up parts of the puzzle being attempted. That's when I decided that intentionally cutting off a significant portion of the puzzle would probably look more aesthetically pleasing, whilst also making the minigame more difficult without me really having to change anything!
The chipset needs updating to fit the Riot Grrrl style a little more (it's still the same as it was in Sore Losers so it does need a change) and I'll probably do that next. Then I'll need to apply the changes to all the other lockpicking puzzles in the game, as well as adding more of them since the game definitely doesn't have enough of them.
... workworkwork.
Hotwiring
Some people said they didn't like the hotwiring minigame from the Sore Losers: Riot Grrrl demo so I decided to modify it. I didn't want to take a completely different direction with the minigame because I still wanted to keep the key element (picking "wires" from one side and matching them to another side) and so I went with something that should be a familiar concept to people:
I think it speaks for itself. The game lets you pick a tile from the left and then lets you try to match it with one on the right. The tiles on each side are completely randomised each time you attempt (or re-attempt!) the minigame in a given area, and the process repeats until you've either matched all the tiles or you've ran out of attempts (attempts only deplete if you give a wrong answer!). The game will give you 12 attempts initially, but this will be reduced as the game goes on. It's basically a memory test, I guess :)
*You have no idea how many lines of eventing it takes to randomise the bloody tiles. Holy fuck. I'm glad it's completely copy-pastable now it works else I might've had to shoot myself.
It wouldn't be a Sore Losers game without a lockpicking minigame... right? Well here it is, and I'm sure people who played the original Sore Losers will recognise most of the graphical assets used.
I originally only made the control overlay at the bottom, but it thought it looked kinda silly since it covered up parts of the puzzle being attempted. That's when I decided that intentionally cutting off a significant portion of the puzzle would probably look more aesthetically pleasing, whilst also making the minigame more difficult without me really having to change anything!
The chipset needs updating to fit the Riot Grrrl style a little more (it's still the same as it was in Sore Losers so it does need a change) and I'll probably do that next. Then I'll need to apply the changes to all the other lockpicking puzzles in the game, as well as adding more of them since the game definitely doesn't have enough of them.
... workworkwork.
Hotwiring
Some people said they didn't like the hotwiring minigame from the Sore Losers: Riot Grrrl demo so I decided to modify it. I didn't want to take a completely different direction with the minigame because I still wanted to keep the key element (picking "wires" from one side and matching them to another side) and so I went with something that should be a familiar concept to people:
I think it speaks for itself. The game lets you pick a tile from the left and then lets you try to match it with one on the right. The tiles on each side are completely randomised each time you attempt (or re-attempt!) the minigame in a given area, and the process repeats until you've either matched all the tiles or you've ran out of attempts (attempts only deplete if you give a wrong answer!). The game will give you 12 attempts initially, but this will be reduced as the game goes on. It's basically a memory test, I guess :)
*You have no idea how many lines of eventing it takes to randomise the bloody tiles. Holy fuck. I'm glad it's completely copy-pastable now it works else I might've had to shoot myself.
Progress Report
Progress Report
Six Hundred And Sixty Six Demo Downloads!
So the current demo has 666 downloads, which I think is pretty neat. It wasn't a landmark that I was looking out for, I just happened to load the page and there it was, but dumb luck is sometimes pretty cool.
This is also a heads up that I will be taking down the current demo in the near future. The current demo no longer reflects the current state of this project, what with all its graphical placeholders and all the recent gameplay updates I've been making, so it won't be around much longer. I'd estimate that it will be gone sometime over the weekend, so grab it while you can because there's no telling when (or even if) an updated demo will appear!
Progress Report
A Slew Of Updates... And What's Next!
There's been a lot going on with Sore Losers: Riot Grrrl over the last couple of months, so this is a bit of a cluster-fuck of updates sourced from a bunch of different posts I've made recently. Hopefully it will all make sense once I'm done!
Battle Animations
One of the big things that I've wanted to redo for the longest of times are the battle animations. The animations that were included in the demo were only ever intended to be place-holders, so they've become understandably limited in scope as development has progressed. This is largely because a lot more weapons have been added to the game since the demo was released; there are currently 25 different weapons in the game and each has 1-3 skills associated with it, so the need for new animations to represent all these skills properly was pretty high on my to-do list!
In any case, I'm happy to announce that I have now finished re-doing all the animations for Sore Losers: Riot Grrrl. I think I'll refrain from adding any more weapons purely because I don't want to have to make any more of these any time soon; I'm not that good of a spriter and so making even simple animations like this takes me way longer than it's probably worth. Anyway, here a few examples for you to look at!
*I should point out that I'm rebalancing enemy/skill stats and haven't gotten around to the enemy side yet; that's why enemies appear to do no damage and die so quickly. That won't happen normally!
Item Placement and the "Search Minigame"
Another thing I've been changing is the item placement around the levels. This is partly because I reorganised the database and so some old variables need pointing to new variables; partly because I didn't do it in a very structured or balanced way the first time around; partly because I have a lot more weapons now (see above) and so I'm replacing some of the item placements with weapons; and finally because I'm redesigning the "search minigame" and so doing the item placements at the same time makes a lot of sense.
The redesign I just mentioned is something that I recently posted a screenshot to show off, but I'll go into more detail here. I've basically been cleaning up the "search minigame" so that there's no longer a worded tutorial (there's now an on-screen command prompt) and so that the rest of the screen fades-to-black whilst you're playing the minigame. The latter is actually way more effort than it sounds because the minigame's "search bar" is a charset, which means that using the "tint screen" command would black-out the "search bar" as well as the background graphics! The idea behind these changes is to make the minigames flow better (the same logic is going to be applied to all the other minigames - and several of the minigames are going to be changed to new minigames because reasons!) and to make it so that the important parts of the minigames don't clash with the background graphics. For some of the small "search bars" it looks pretty simplistic, but it makes a lot of the more complex "search bars" far easier to tackle!
Here it is in motion. For clarity, there are two search attempts shown here. The first one misses and the second one hits. The .gif then loops back to the first attempt... and before anyone asks, of course I missed the first attempt on purpose!
I think it looks a lot cleaner!
What Next?
Well, one thing I intend to do next is the thing that I just mentioned. I will be updating all the minigames so that they have on-screen command prompts like the one shown above, as opposed to having written tutorials that take up too much of the player's time. I will also be replacing some of the minigames with new minigames, with the "hotwiring" minigame being one that is definitely in the firing line given how few people seem to actually enjoy it.
Another thing that I'm currently doing is drawing out additional sections for level three of the game. Having gone through the level a few times whilst updating the "search minigame" and moving around items (see above), I felt it was missing something. This is especially true when it's compared to the second level.
That tray of paper/folders in the background are also mostly game development notes...
BUT WAIT, THERE'S MORE!
Since someone was kind enough to feature this on the home page, I figure I might as well add the update I just posted in the screenshot thread. Y'know, because I'm kind like that. Or something:
CHESKA SMASH!
I'm continuing with cleaning up how minigames look in SL: Riot Grrrl and I've just finished cleaning up all the "battering ram" minigame. I've also added quite a few more of them to the project because there were far too many open doors about!
However, this isn't just a cleaner set of graphics: It's also a minigame reassignment! People who've played the demo will realise that this was originally the minigame used for "hacking", but I've moved it over to be the "battering ram" minigame because a) I've had a better idea for how to do the "hacking" minigame and b) the previous "battering ram" minigame was far too similar in its mechanics to the "searching" minigame.
Battle Animations
One of the big things that I've wanted to redo for the longest of times are the battle animations. The animations that were included in the demo were only ever intended to be place-holders, so they've become understandably limited in scope as development has progressed. This is largely because a lot more weapons have been added to the game since the demo was released; there are currently 25 different weapons in the game and each has 1-3 skills associated with it, so the need for new animations to represent all these skills properly was pretty high on my to-do list!
In any case, I'm happy to announce that I have now finished re-doing all the animations for Sore Losers: Riot Grrrl. I think I'll refrain from adding any more weapons purely because I don't want to have to make any more of these any time soon; I'm not that good of a spriter and so making even simple animations like this takes me way longer than it's probably worth. Anyway, here a few examples for you to look at!
*I should point out that I'm rebalancing enemy/skill stats and haven't gotten around to the enemy side yet; that's why enemies appear to do no damage and die so quickly. That won't happen normally!
Item Placement and the "Search Minigame"
Another thing I've been changing is the item placement around the levels. This is partly because I reorganised the database and so some old variables need pointing to new variables; partly because I didn't do it in a very structured or balanced way the first time around; partly because I have a lot more weapons now (see above) and so I'm replacing some of the item placements with weapons; and finally because I'm redesigning the "search minigame" and so doing the item placements at the same time makes a lot of sense.
The redesign I just mentioned is something that I recently posted a screenshot to show off, but I'll go into more detail here. I've basically been cleaning up the "search minigame" so that there's no longer a worded tutorial (there's now an on-screen command prompt) and so that the rest of the screen fades-to-black whilst you're playing the minigame. The latter is actually way more effort than it sounds because the minigame's "search bar" is a charset, which means that using the "tint screen" command would black-out the "search bar" as well as the background graphics! The idea behind these changes is to make the minigames flow better (the same logic is going to be applied to all the other minigames - and several of the minigames are going to be changed to new minigames because reasons!) and to make it so that the important parts of the minigames don't clash with the background graphics. For some of the small "search bars" it looks pretty simplistic, but it makes a lot of the more complex "search bars" far easier to tackle!
Here it is in motion. For clarity, there are two search attempts shown here. The first one misses and the second one hits. The .gif then loops back to the first attempt... and before anyone asks, of course I missed the first attempt on purpose!
I think it looks a lot cleaner!
What Next?
Well, one thing I intend to do next is the thing that I just mentioned. I will be updating all the minigames so that they have on-screen command prompts like the one shown above, as opposed to having written tutorials that take up too much of the player's time. I will also be replacing some of the minigames with new minigames, with the "hotwiring" minigame being one that is definitely in the firing line given how few people seem to actually enjoy it.
Another thing that I'm currently doing is drawing out additional sections for level three of the game. Having gone through the level a few times whilst updating the "search minigame" and moving around items (see above), I felt it was missing something. This is especially true when it's compared to the second level.
That tray of paper/folders in the background are also mostly game development notes...
BUT WAIT, THERE'S MORE!
Since someone was kind enough to feature this on the home page, I figure I might as well add the update I just posted in the screenshot thread. Y'know, because I'm kind like that. Or something:
CHESKA SMASH!
I'm continuing with cleaning up how minigames look in SL: Riot Grrrl and I've just finished cleaning up all the "battering ram" minigame. I've also added quite a few more of them to the project because there were far too many open doors about!
However, this isn't just a cleaner set of graphics: It's also a minigame reassignment! People who've played the demo will realise that this was originally the minigame used for "hacking", but I've moved it over to be the "battering ram" minigame because a) I've had a better idea for how to do the "hacking" minigame and b) the previous "battering ram" minigame was far too similar in its mechanics to the "searching" minigame.
Progress Report
Getting Back On The Horse
So I'm finally working on this game again. Unfortunately, the way that I see it, there is a lot to do to get the levels that have already been made up to scratch. On one hand, this is very frustrating since it means that I'm not really working on "new" stuff. But on the other hand, it's also satisfying in that I can visibly see things that I'd already deemed "complete" becoming a lot better than they were.
The Item System and "Key Items"
One of the first things on my target list was the item system. Previously, Cheska could only carry six items and two weapons at once, and this included key items/weapons that are near-constantly required such as the Screwdriver (in relation to the "hotwire" minigame) and the Sledgehammer (in relation to the "smashing" minigame). Over the course of the game, there are four such items/weapons that can be collected and this essentially meant that four out of the eight slots available (50%!) were being taken up by items that you had little choice but to keep with you. This was obviously not good design as it would only serve to frustrate players and limit their options.
To fix this, I've introduced the concept of "key items" to the game. Items such as the Screwdriver no longer take up item slots, can no longer be dropped and appear separate from "normal items" in the item system. In line with this, "key item" elements relating to weapons such as the Sledgehammer have been moved onto newly created items instead. In the case of the Sledgehammer, the item that has replaced it is the Battering Ram, which you can see in the screenshot below:
It took me longer than I would've liked to work these changes into the system since a large chunk of the item system eventing needed to be redone in order to accommodate, not to mention the fact that new item system overlays needed to be drawn up! By far the most tedious part was going through every single item drop in the game to make sure that they weren't dropping additional key items, since that would pretty badly break the system! However, I do think this was something worth doing (as boring as it was) and I'm glad that I was able to get it working. The game is much better off for it!
Cutscenes... Again!
Another thing I've been working on is updating the look of the cutscenes, which is something that I've mentioned working on before. I've updated several of the cutscene images on this gamepage to reflect the work that's being done and I personally think things are looking a lot better now. I won't link all of them here since you can find them under the "images" tab, but here is a taster:
I said this previously, but the best part about working on these is that I've been able to draw up a set of templates that allow me to streamline how I work on producing cutscenes, so doing this will help me to be much more consistent going forward.
Consistency
Speaking of consistency, I've noticed a lot of inconsistency with how I've gone about some things in the game, most likely related to how many large breaks I've taken in development. A very basic example is the way that option dialogues look. Sometimes, option dialogues will look like this and pressing escape whilst in them won't do a thing:
Whilst others will look like this, with cancellation being achieved by pressing escape:
It's a minor thing, but now that I've noticed it I'm going to try and fix it.
Another thing that I need to fix in relation to this kind of thing is my massive overuse of ellipses (...) in the text, something that I personally dislike people doing in RM* games and something that I hadn't even realised I'd been doing to such a massive extent.
Finally, I've also been rooting out the use of \| (which pauses text) in message boxes and replacing it with \! (which waits until the player presses something), again because the use of the former it is something that I personally dislike and something that I hadn't realised I'd been doing.
Again, these are all minor things, but they're things that should be consistent so that the game plays more smoothly than it does at the moment.
Conclusions?
It's good to be working on the game again. It's good to be making obvious improvements. It's good that I haven't forgotten so much about how the game works that I'm unable to mess with/fix/improve key eventing-based systems that the game 100% relies on being perfect. But there is a lot of work to do to get this game finished to the standard I want and that fact doesn't escape me. I've said before that, "I constantly worry that people are going to be incredibly underwhelmed when they realise this isn't all that different from most RPG games" and that hasn't changed. Hopefully I can prove myself wrong.
The Item System and "Key Items"
One of the first things on my target list was the item system. Previously, Cheska could only carry six items and two weapons at once, and this included key items/weapons that are near-constantly required such as the Screwdriver (in relation to the "hotwire" minigame) and the Sledgehammer (in relation to the "smashing" minigame). Over the course of the game, there are four such items/weapons that can be collected and this essentially meant that four out of the eight slots available (50%!) were being taken up by items that you had little choice but to keep with you. This was obviously not good design as it would only serve to frustrate players and limit their options.
To fix this, I've introduced the concept of "key items" to the game. Items such as the Screwdriver no longer take up item slots, can no longer be dropped and appear separate from "normal items" in the item system. In line with this, "key item" elements relating to weapons such as the Sledgehammer have been moved onto newly created items instead. In the case of the Sledgehammer, the item that has replaced it is the Battering Ram, which you can see in the screenshot below:
It took me longer than I would've liked to work these changes into the system since a large chunk of the item system eventing needed to be redone in order to accommodate, not to mention the fact that new item system overlays needed to be drawn up! By far the most tedious part was going through every single item drop in the game to make sure that they weren't dropping additional key items, since that would pretty badly break the system! However, I do think this was something worth doing (as boring as it was) and I'm glad that I was able to get it working. The game is much better off for it!
Cutscenes... Again!
Another thing I've been working on is updating the look of the cutscenes, which is something that I've mentioned working on before. I've updated several of the cutscene images on this gamepage to reflect the work that's being done and I personally think things are looking a lot better now. I won't link all of them here since you can find them under the "images" tab, but here is a taster:
I said this previously, but the best part about working on these is that I've been able to draw up a set of templates that allow me to streamline how I work on producing cutscenes, so doing this will help me to be much more consistent going forward.
Consistency
Speaking of consistency, I've noticed a lot of inconsistency with how I've gone about some things in the game, most likely related to how many large breaks I've taken in development. A very basic example is the way that option dialogues look. Sometimes, option dialogues will look like this and pressing escape whilst in them won't do a thing:
What do you want to do?
>Do the first thing!
>Do the second thing!
>Don't do either thing.
Whilst others will look like this, with cancellation being achieved by pressing escape:
What do you want to do?
>Do the first thing!
>Do the second thing!
It's a minor thing, but now that I've noticed it I'm going to try and fix it.
Another thing that I need to fix in relation to this kind of thing is my massive overuse of ellipses (...) in the text, something that I personally dislike people doing in RM* games and something that I hadn't even realised I'd been doing to such a massive extent.
Finally, I've also been rooting out the use of \| (which pauses text) in message boxes and replacing it with \! (which waits until the player presses something), again because the use of the former it is something that I personally dislike and something that I hadn't realised I'd been doing.
Again, these are all minor things, but they're things that should be consistent so that the game plays more smoothly than it does at the moment.
Conclusions?
It's good to be working on the game again. It's good to be making obvious improvements. It's good that I haven't forgotten so much about how the game works that I'm unable to mess with/fix/improve key eventing-based systems that the game 100% relies on being perfect. But there is a lot of work to do to get this game finished to the standard I want and that fact doesn't escape me. I've said before that, "I constantly worry that people are going to be incredibly underwhelmed when they realise this isn't all that different from most RPG games" and that hasn't changed. Hopefully I can prove myself wrong.
Progress Report
The Chaotic Design of Level Four
I've been saying for a very long time that level 4, which will essentially be the final level of the game, is planned out and ready to go. This is more or less true, I have most of the stage designs down on paper and I have more than 3/4 of the backgrounds sprited. The problem is that I've gone about working on this level in a completely different way to how I've worked on the other levels, and it's really throwing me through a loop.
When I was working on levels 1-3, I would do everything for a given stage at the same time. I would draw out the stage, get the stage into the maker, add all the events needed for that particular stage, test that it was working as desired, and then move onto the next stage. Doing it this way, it would only take approx. two nights of free-time to complete one stage, and the procedural nature of the work made it easy to do without thinking too hard about what I was doing. It also meant that I was constantly working on different things (different image-types, different events, different minigame systems), which helped me stay familiar with everything I needed to get a given stage finished.
However, after taking a break from developing this game to work on my PhD thesis, I found it really hard to get back into the swing of things and start work on level 4. Because of this, I decided that I should make progress by working on the easiest thing to work on. I found that the easiest thing for me to work on was the spriting, as that didn't require me to open RPGMaker and look at event coding that I was no longer familiar with. After doing that, I started to get overlays working for each stage, started to link stages together using the required teleport events, and then added the "search" events to each level (the search events are by far the easiest of the minigames to understand in terms of event coding). At this moment in time, I'm adding things like enemies and other minigames to each level, so things are definitely getting closer to being done.
The problem with doing it this way is that things are no longer procedural; I am no longer working in a way that allows me to work on auto-pilot and that is a big problem for me given how draining my job sometimes is. I'm coming across minigame systems etc. that I haven't worked with for a long time and, despite the fact that I've annotated my event code pretty well, I find it difficult to work on the game for long periods of time. I guess this should serve as a cautionary tale; my punishment for taking the path of least resistance when I came back to working on the game is really backfiring now!
Anyway, have a screenshot :3
When I was working on levels 1-3, I would do everything for a given stage at the same time. I would draw out the stage, get the stage into the maker, add all the events needed for that particular stage, test that it was working as desired, and then move onto the next stage. Doing it this way, it would only take approx. two nights of free-time to complete one stage, and the procedural nature of the work made it easy to do without thinking too hard about what I was doing. It also meant that I was constantly working on different things (different image-types, different events, different minigame systems), which helped me stay familiar with everything I needed to get a given stage finished.
However, after taking a break from developing this game to work on my PhD thesis, I found it really hard to get back into the swing of things and start work on level 4. Because of this, I decided that I should make progress by working on the easiest thing to work on. I found that the easiest thing for me to work on was the spriting, as that didn't require me to open RPGMaker and look at event coding that I was no longer familiar with. After doing that, I started to get overlays working for each stage, started to link stages together using the required teleport events, and then added the "search" events to each level (the search events are by far the easiest of the minigames to understand in terms of event coding). At this moment in time, I'm adding things like enemies and other minigames to each level, so things are definitely getting closer to being done.
The problem with doing it this way is that things are no longer procedural; I am no longer working in a way that allows me to work on auto-pilot and that is a big problem for me given how draining my job sometimes is. I'm coming across minigame systems etc. that I haven't worked with for a long time and, despite the fact that I've annotated my event code pretty well, I find it difficult to work on the game for long periods of time. I guess this should serve as a cautionary tale; my punishment for taking the path of least resistance when I came back to working on the game is really backfiring now!
Anyway, have a screenshot :3
Progress Report
Replacing The Placeholders
I'm not exactly a master of pixel art but I've gotten a lot better whilst making this game, just one of the reasons that I think that forcing myself to produce custom graphics for this game has definitely been a worthwhile endeavour. Given that I have improved, I figured it was about time I replaced the placeholder graphics for the opening sequence etc. with something that actually looks the part.
I'm going to start with the "floating heads" that are present in nearly all of the cutscenes. Although a super simplistic style works well for the charaset sprites, it does not at all look good on these much larger heads...
Any thoughts..?
I'm going to start with the "floating heads" that are present in nearly all of the cutscenes. Although a super simplistic style works well for the charaset sprites, it does not at all look good on these much larger heads...
Any thoughts..?
Progress Report
Getting Out Of Riot Grrrl's Development Hell
This is a cross-post from my general gaming blog, Sore Losers Gaming...
Sore Losers: Riot Grrrl is a game that I've been working on for a very long time. Originally intended as a short project into which I could dump ideas that didn't fit the JRPG formula I used in Sore Losers, it soon sprawled into a much larger project than I had intended. Unfortunately, real life eventually managed to get in the way and I wasn't able, nor willing, to work on the game for over a year. That's obviously a long time, and so getting back into the flow of things has been very difficult... but there's nothing I can do about that other than to work hard. I've promised myself, and the friends who've helped me out, that this game is eventually going to get finished and so finishing it is what I'm going to do.
So, where am I up to? I returned to the game to find that three out of the planned five levels were complete (which had been the situation for longer than my hiatus had lasted), and that I was in the middle of bug testing those levels. This meant that I spent the first couple of months or so bug testing, fixing bugs, and then bug testing over again. Fortunately, I didn't find as many bugs as I'd found when I was making the original Sore Losers, so I'm obviously getting better at this game development thing!
Admittedly, bug testing can sometimes be a very annoying process because it usually ends up feeling like you're taking away from the game rather than adding to it, but in this case it was actually a very therapeutic process. This is as it as it allowed me to familiarise myself with how many of the game's most important systems worked and how they were linked into one another, which in turn made it much on me when I eventually started creating new levels and content.
After finishing the bug testing, it was time to get on with making the fourth level, and that's actually going well so far. Several stages are already complete, and I have a well developed plan for how the rest of the level is going to pan out. All I really need to do is turn my plans into both code (which is actually the easy part because of the clever, modular system I've set-up for generating new levels) and sprites (which is by far the more difficult part because I'm so slow when it comes to drawing out all the level backgrounds, monsters and characters I need).
Overall, it's good to be making progress, so I'll leave you with some screenshots and continue my work!
The final level takes place in a government building, throughout which stand many militaristic statues such as this one (I'm still not sold on the shading; probably needs a touch up).
Given that government in this game are a very paranoid group of people, there are lots of secret passages and security measures to deal with in this particular level!
Sore Losers: Riot Grrrl is a game that I've been working on for a very long time. Originally intended as a short project into which I could dump ideas that didn't fit the JRPG formula I used in Sore Losers, it soon sprawled into a much larger project than I had intended. Unfortunately, real life eventually managed to get in the way and I wasn't able, nor willing, to work on the game for over a year. That's obviously a long time, and so getting back into the flow of things has been very difficult... but there's nothing I can do about that other than to work hard. I've promised myself, and the friends who've helped me out, that this game is eventually going to get finished and so finishing it is what I'm going to do.
So, where am I up to? I returned to the game to find that three out of the planned five levels were complete (which had been the situation for longer than my hiatus had lasted), and that I was in the middle of bug testing those levels. This meant that I spent the first couple of months or so bug testing, fixing bugs, and then bug testing over again. Fortunately, I didn't find as many bugs as I'd found when I was making the original Sore Losers, so I'm obviously getting better at this game development thing!
Admittedly, bug testing can sometimes be a very annoying process because it usually ends up feeling like you're taking away from the game rather than adding to it, but in this case it was actually a very therapeutic process. This is as it as it allowed me to familiarise myself with how many of the game's most important systems worked and how they were linked into one another, which in turn made it much on me when I eventually started creating new levels and content.
After finishing the bug testing, it was time to get on with making the fourth level, and that's actually going well so far. Several stages are already complete, and I have a well developed plan for how the rest of the level is going to pan out. All I really need to do is turn my plans into both code (which is actually the easy part because of the clever, modular system I've set-up for generating new levels) and sprites (which is by far the more difficult part because I'm so slow when it comes to drawing out all the level backgrounds, monsters and characters I need).
Overall, it's good to be making progress, so I'll leave you with some screenshots and continue my work!
The final level takes place in a government building, throughout which stand many militaristic statues such as this one (I'm still not sold on the shading; probably needs a touch up).
Given that government in this game are a very paranoid group of people, there are lots of secret passages and security measures to deal with in this particular level!
Progress Report
He's a doctor, but not a *real* doctor...
author=Clyve
So are you done with that PHD nonsense yet?
PhD nonsense? Since I put this game on hiatus I've written a 344 page thesis, worked on and co-authored this paper, co-authored this review, worked on and lead-authored a yet to be published paper, studied for and passed a viva voce, and then had two months of feeling more burnt out than I ever have...
... "nonsense" indeed.
Anyway, yeah, I've been working on this sparingly now that I feel a little less burnt out, but I think it is going to take a while for me to re-familiarise myself with how all the systems work so I don't expect progress to be rapid. I've not looked at RPGMaker for a long time, so a lot of the eventing feels fairly foreign to me. It also feels like some of the stuff I already did has gone missing, but I could be imagining things; it's not like I have a new computer or anything like that, so there isn't any good reason why anything would've disappeared.
---
Oh, and here is a blurry picture of my thesis. I would post a picture of my degree, but it only arrived a week or so ago and I haven't actually gotten around to taking a picture of it yet.
