I've decided, dear readers, that since you've been so tolerant of my delays between posts, I would share a sneak peek of the work I've been doing on the book I mentioned. The text and picture are both rough drafts from the book, in a section about forts. This particular fort is called the Pallet Palace. I'd love to hear any feedback you have, since this is a rough draft. Follow the break to read the page. Thanks for sticking with me, Readers!
Saturday, June 16, 2012
Thursday, May 17, 2012
My Latest Project (or, excuses excuses...)
Hello readers, I know that you had probably given up on seeing any updates from this blog, but it's not true! I've been very distracted lately, and haven't felt that I had much to say to you, so rather than pester you with filler, I decided to let it go for awhile. I admit, after this post, I may go silent for another while. However, let me fill you in on what is currently taking up my time!
So, you may not have heard of lulu.com, but it is a self-publishing website. I had an idea for a book a few months ago, and have finally decided to get my butt into gear and start writing. The title of the book is The Expert's Guide To Getting Into (And Sometimes Out Of) TROUBLE I know, it's a long winded title, but I like it. Anyway, it's a book about projects for kids, from building treehouses to fun pranks to pull, to stories to tell younger siblings to torment them for years. It's basically a guide to all of the things that kids used to do when it was okay to climb trees and skin knees.
For now, that's all I can really tell you, but I have already wrapped out about twenty pages (sans illustrations) and wanted to let you know that I am not dead, but rather, happily busy. Look for more updates on the book as I get closer to publishing, and thank you for being supportive!
So, you may not have heard of lulu.com, but it is a self-publishing website. I had an idea for a book a few months ago, and have finally decided to get my butt into gear and start writing. The title of the book is The Expert's Guide To Getting Into (And Sometimes Out Of) TROUBLE I know, it's a long winded title, but I like it. Anyway, it's a book about projects for kids, from building treehouses to fun pranks to pull, to stories to tell younger siblings to torment them for years. It's basically a guide to all of the things that kids used to do when it was okay to climb trees and skin knees.
For now, that's all I can really tell you, but I have already wrapped out about twenty pages (sans illustrations) and wanted to let you know that I am not dead, but rather, happily busy. Look for more updates on the book as I get closer to publishing, and thank you for being supportive!
 |
| An exploded view of the doghouse project from the book! |
Friday, February 3, 2012
Hangout Games Pt. 2
Okay, where were we? That's right, my next step was explaining the builder portion of this game.
Basically, the builder is a simple tile-based system. The creator chooses a size level at the beginning, and from there they are asked to choose an element/theme. This determines the tileset and sprites the creator will be able to use, such as volcanic mine, or dreary forest. There would be a large array of tilesets, and the library would be constantly expanding. The tiles aren't different physically, that is, a wall is still a wall, a rock is a rock, floors are floors, etc. Mostly, the difference is aesthetic. However, there would likely be elements from each them that would be unique, such as cart rails in the aforementioned mines, or foliage overhead in a forest. Every element would be able to be painted onto the map, and the edges would automatically align. So, when a player draws a pool of water, lava or acid (as examples) the edges of that pool would create their own shores. So, the player draws all the elements of their map, including multiple floors, stairs, walls, decorations, raised walkways, and bodies of water. Then the player moves to the puzzle layer of the editor.
This layer takes care of the elements that adventurers interact with using the action button. The creator is given a palette of objects such as doors, switches and pushable blocks. Each of these behave in specific ways, and are aesthetically adapted to the them of the map.
First of all, doors. Doors are pretty obvious, so I'll pair them with locks for simplicity. Whenever a player paints a door, lock, or locked treasure chest, they are immediately prompted to place a key for that object. The creators will be given the option to ignore the notice, if they need to, but will not be able to test or publish their dungeon without placing keys for every lock. They may place a key in a chest, in the open, as the solution to a puzzle, or even into the pocket of a monster (I'm getting there, I promise.) There may also be theme-specific components that they may place keys, like a minecart, for example, or the belly of some sort of machine.
The second element of the Puzzle layer is the puzzles themselves. These are more complicated, if only because there are so many different types of them. In the editor, when the creator decides to place a puzzle, they must first select the obstacle that the puzzle removes. This could override a lock on a door, for example, or even walls. If the creator decides that their puzzle opens a secret passage through a wall, for example, they would draw a brightly colored indicator over which wall pieces would disappear when the puzzle is completed. If, on the other hand, the puzzle say, lifted a bridge from a pool of acid, they would first draw the bridge and then place the indicators over it. Then, after placing the indicators, they would be asked which state is natural, is the bridge there before the puzzle, or does is appear?
Then they may begin building the puzzle itself, using switches and blocks, lasers, and who knows what all else. one of the tricks is that every switch has a series of options. It's a bit complicated to explain, but in a right-click window (as it would appear in-designer) the options would be simple. the creator would choose which puzzle the switch operates, they would choose which direction it works, (for example, pressing one switch might undo others) and they can decide if the switch must be held down for it's effect to remain. The switches can also be linked to specific indicator colors, so that when say, a player presses one switch, maybe a door opens, but the floor leading to it becomes covered in spikes, so that only a certain combination of switches will create the access the players need. Switches can also be triggered in such a way that multiple switches must be triggered at once to activate them. That would cause players to have to cooperate to solve puzzles. eventually, when the creator has satisfied their puzzle building needs, they can test-play it to make sure all puzzles are solvable. In the test-play mode, they are given "dolls" which they can leave on a switch as a person, so as to test multi-person puzzles.
This layer also includes story-related events, including events triggered by being in a location, or conversations with npc's. these are created in almost exactly the same way as puzzles, using triggers and actions.
Then, the creator moves on to the final layer of the editor; monsters.Every style of dungeon has it's own types of monsters that are location-specific. For example swamp-plants in a marsh, or goblin machinists in a factory. However, there are classic monsters that can be called on as well, spiders, lizard-men, slimes, etc. These can be placed one at a time onto the map, using a brush tool. they can be grouped into teams, so that they wear color-coded clothes/accents and work cooperatively (obviously not all enemies can work together, since swamp plants are likely to operate on instinct). some enemies would come with objects rthat can be placed with them, for example, a Kobold machine-gunner would likely come with sandbags, and the Kobold might even be placed away from his den, to create a race-against the clock element. Another example (and a much more obvious one I should have thought of first) is spider webbing.
Finally, the player creates a boss fight for the dungeon. The boss fight is created in a separate sort of editor, still part of the main one, but brought up in a new window. In this window, there is a viewing screen, where they can view their boss as it acts through its animations and attacks. Underneath that frame is the editor for it. First, the creator chooses from many sprites of enemy, and even types (Small fighter, classic serpent dodging around the room, giant stationary monster, giant walking monster, etc.) Then after selecting an enemy, and coloring it appropriately, they are given a timeline for it's actions. The timeline is based on hitpoints. For example, if the villain starts with 100 hp, the first portion of timeline could be from 100-75 hp. During that time in the boss' life, they would perform a certain type and number of attacks in a certain order, and move in a specific way. Then, after the hero has done 25 hp of damage, the monster would move into say, it's 75-50 range, where it would perform different attacks and movements. The boss' hp could be divided many times, creating a complex creature. Then the player could introduce Dialogue for the villain, and choose a loot category for it, determining the type of treasure that the villain can drop. In certain sized dungeons, specifically large ones, the creator would be allowed to insert a mini-boss partway through, using the same editor.
The creator is also able to use pre-built rooms and enemies, which they could drop into place like tiles.
The last and most important element of this designer (I know, I know, too long, didn't read) is the grading scale. After the creator has finished editing, the click "Publish" They will be prompted for a name, and a description, and given the option to include the dungeon into a quest. Then, the computer takes over. The computer would review the map, looking at things like the number of switches used to trigger puzzles, the total HP of enemies, the level of enemies, and the size of the map, and create a star rating for the difficulty of the map. This is crucial because if the maps aren't ranked appropriately, new players may find themselves trapped in a dungeon that is too powerful, and end up having no fun at all, which is the most important part of any game. However, the difficulty grading does more than that. It allows the designer to create escalation in a campaign, and also determines the quality of items inside of the dungeon. More difficult dungeons obviously earn players more powerful armor, weapons and treasures. Players can also upvote maps after having completed them, and provide reviews, which can also effect the overall rating of the map. The entire game is about creating a social experience that causes players to work together, either in a dungeon, or on a dungeon.
Hopefully you managed to get through all that, I didn't realize I had spent so much time thinking about it between my last post and this one, but apparently, there was a lot going on in the back of my head. Anyway, I'd love to hear anyone's thoughts on this or any of the designs I've posted, so feel free to comment! Thanks for reading!
Basically, the builder is a simple tile-based system. The creator chooses a size level at the beginning, and from there they are asked to choose an element/theme. This determines the tileset and sprites the creator will be able to use, such as volcanic mine, or dreary forest. There would be a large array of tilesets, and the library would be constantly expanding. The tiles aren't different physically, that is, a wall is still a wall, a rock is a rock, floors are floors, etc. Mostly, the difference is aesthetic. However, there would likely be elements from each them that would be unique, such as cart rails in the aforementioned mines, or foliage overhead in a forest. Every element would be able to be painted onto the map, and the edges would automatically align. So, when a player draws a pool of water, lava or acid (as examples) the edges of that pool would create their own shores. So, the player draws all the elements of their map, including multiple floors, stairs, walls, decorations, raised walkways, and bodies of water. Then the player moves to the puzzle layer of the editor.
This layer takes care of the elements that adventurers interact with using the action button. The creator is given a palette of objects such as doors, switches and pushable blocks. Each of these behave in specific ways, and are aesthetically adapted to the them of the map.
First of all, doors. Doors are pretty obvious, so I'll pair them with locks for simplicity. Whenever a player paints a door, lock, or locked treasure chest, they are immediately prompted to place a key for that object. The creators will be given the option to ignore the notice, if they need to, but will not be able to test or publish their dungeon without placing keys for every lock. They may place a key in a chest, in the open, as the solution to a puzzle, or even into the pocket of a monster (I'm getting there, I promise.) There may also be theme-specific components that they may place keys, like a minecart, for example, or the belly of some sort of machine.
The second element of the Puzzle layer is the puzzles themselves. These are more complicated, if only because there are so many different types of them. In the editor, when the creator decides to place a puzzle, they must first select the obstacle that the puzzle removes. This could override a lock on a door, for example, or even walls. If the creator decides that their puzzle opens a secret passage through a wall, for example, they would draw a brightly colored indicator over which wall pieces would disappear when the puzzle is completed. If, on the other hand, the puzzle say, lifted a bridge from a pool of acid, they would first draw the bridge and then place the indicators over it. Then, after placing the indicators, they would be asked which state is natural, is the bridge there before the puzzle, or does is appear?
Then they may begin building the puzzle itself, using switches and blocks, lasers, and who knows what all else. one of the tricks is that every switch has a series of options. It's a bit complicated to explain, but in a right-click window (as it would appear in-designer) the options would be simple. the creator would choose which puzzle the switch operates, they would choose which direction it works, (for example, pressing one switch might undo others) and they can decide if the switch must be held down for it's effect to remain. The switches can also be linked to specific indicator colors, so that when say, a player presses one switch, maybe a door opens, but the floor leading to it becomes covered in spikes, so that only a certain combination of switches will create the access the players need. Switches can also be triggered in such a way that multiple switches must be triggered at once to activate them. That would cause players to have to cooperate to solve puzzles. eventually, when the creator has satisfied their puzzle building needs, they can test-play it to make sure all puzzles are solvable. In the test-play mode, they are given "dolls" which they can leave on a switch as a person, so as to test multi-person puzzles.
This layer also includes story-related events, including events triggered by being in a location, or conversations with npc's. these are created in almost exactly the same way as puzzles, using triggers and actions.
Then, the creator moves on to the final layer of the editor; monsters.Every style of dungeon has it's own types of monsters that are location-specific. For example swamp-plants in a marsh, or goblin machinists in a factory. However, there are classic monsters that can be called on as well, spiders, lizard-men, slimes, etc. These can be placed one at a time onto the map, using a brush tool. they can be grouped into teams, so that they wear color-coded clothes/accents and work cooperatively (obviously not all enemies can work together, since swamp plants are likely to operate on instinct). some enemies would come with objects rthat can be placed with them, for example, a Kobold machine-gunner would likely come with sandbags, and the Kobold might even be placed away from his den, to create a race-against the clock element. Another example (and a much more obvious one I should have thought of first) is spider webbing.
Finally, the player creates a boss fight for the dungeon. The boss fight is created in a separate sort of editor, still part of the main one, but brought up in a new window. In this window, there is a viewing screen, where they can view their boss as it acts through its animations and attacks. Underneath that frame is the editor for it. First, the creator chooses from many sprites of enemy, and even types (Small fighter, classic serpent dodging around the room, giant stationary monster, giant walking monster, etc.) Then after selecting an enemy, and coloring it appropriately, they are given a timeline for it's actions. The timeline is based on hitpoints. For example, if the villain starts with 100 hp, the first portion of timeline could be from 100-75 hp. During that time in the boss' life, they would perform a certain type and number of attacks in a certain order, and move in a specific way. Then, after the hero has done 25 hp of damage, the monster would move into say, it's 75-50 range, where it would perform different attacks and movements. The boss' hp could be divided many times, creating a complex creature. Then the player could introduce Dialogue for the villain, and choose a loot category for it, determining the type of treasure that the villain can drop. In certain sized dungeons, specifically large ones, the creator would be allowed to insert a mini-boss partway through, using the same editor.
The creator is also able to use pre-built rooms and enemies, which they could drop into place like tiles.
The last and most important element of this designer (I know, I know, too long, didn't read) is the grading scale. After the creator has finished editing, the click "Publish" They will be prompted for a name, and a description, and given the option to include the dungeon into a quest. Then, the computer takes over. The computer would review the map, looking at things like the number of switches used to trigger puzzles, the total HP of enemies, the level of enemies, and the size of the map, and create a star rating for the difficulty of the map. This is crucial because if the maps aren't ranked appropriately, new players may find themselves trapped in a dungeon that is too powerful, and end up having no fun at all, which is the most important part of any game. However, the difficulty grading does more than that. It allows the designer to create escalation in a campaign, and also determines the quality of items inside of the dungeon. More difficult dungeons obviously earn players more powerful armor, weapons and treasures. Players can also upvote maps after having completed them, and provide reviews, which can also effect the overall rating of the map. The entire game is about creating a social experience that causes players to work together, either in a dungeon, or on a dungeon.
Hopefully you managed to get through all that, I didn't realize I had spent so much time thinking about it between my last post and this one, but apparently, there was a lot going on in the back of my head. Anyway, I'd love to hear anyone's thoughts on this or any of the designs I've posted, so feel free to comment! Thanks for reading!
P.s. If you decided to create this game, PLEASE let me know, and please give me credit for the original concept. If someone does make it, I'll do my very best to help you publicize, and I'd even be willing to collaborate, if needed. Thanks!
Wednesday, January 11, 2012
Hangout games pt. 1
So, It's been awhile, but I did promise you at least three game ideas, so here, dearest readers, is number three.
A lot of people have heard of Google Plus, and may be familiar with one of its big components, hangouts. However, for those of you who are unfamiliar, let me sum it up. Hangouts is a chatroom with video for up to ten people to video chat on, with adaptive screen scaling, and a developer component called Hangouts with add-ons. That's the part that matters here, because it allows web developers to make apps for hangouts. The idea behind my game is to create an add-on that serves as a full blown game, using hangouts to play. My idea is a dungeon crawler, in the fashion of diablo, where the players co-operate to battle through the dungeon, and must solve puzzles in collaboration. The game uses simple action mechanics, walk, fight, and push, like an oldschool adventure game. Think Legend of Zelda: Link to the Past, as far as mechanics, but with ten players running around at the same time. Obviously, It's a lot for developers to work on, because to develop puzzles for that size group, there's a lot of thought involved.
That's why the second half of the game is based around building. On a website separate from the played game, players will be invited to create dungeons. The computer will assess the difficulty of the puzzles, as well as the enemies, and pay the player for their maps in in-game gold.
I'll focus more on the dungeon builder in my next post, but I wanted to give you a taste of it.
As far as plot goes, I actually imagine this game as fairly classic. It's an adventure game set in a somewhat steam-powered fantasy world. Swords and sorcery and steam, if you will. There are five types of class: Fighter, Healer, Mage, Thief, and for lack of a better term, a red mage. The fighter, obviously is geared toward combat, healer toward healing, and mage toward magic. The thief has abilities more geared toward status effects, stealing and light damage, while the red mage is a fair balance between magic and fighting. Each character has two assignable attack slots, one for left click, and one for spacebar. The left click would be especially suited for things like arrows, throwing knives, or spells, which would be aim-able via the mouse. While the spacebar would be good for short-range attacks. However, when the player is standing next to a chest, door, person or switch, the spacebar would become the "Action button" allowing them to acivate those things, or to speak to a person. Movement would be controlled by WASD.
I think that most of the plot would be devoted to being roving adventurers, saving princesses, defeating monsters and saving villages. However, through the building system, some dungeons could be linked together into campaigns, with full-blown story archs. It would allow people who are drawn to the dungeons and dragons to create a full story for their friends to play, without having to worry about managing dice rolls and mechanics, since the game will handle all of that already. Players could even divide the task of dungeon building in an arch, so that no player knows all of the dungeons, and everyone could play together.
As I said earlier, I'll get into dungeon building in my next post. Hopefully you enjoy the concept so far, I have a lot of Ideas for this game, and would love to work with a team to create it.
A lot of people have heard of Google Plus, and may be familiar with one of its big components, hangouts. However, for those of you who are unfamiliar, let me sum it up. Hangouts is a chatroom with video for up to ten people to video chat on, with adaptive screen scaling, and a developer component called Hangouts with add-ons. That's the part that matters here, because it allows web developers to make apps for hangouts. The idea behind my game is to create an add-on that serves as a full blown game, using hangouts to play. My idea is a dungeon crawler, in the fashion of diablo, where the players co-operate to battle through the dungeon, and must solve puzzles in collaboration. The game uses simple action mechanics, walk, fight, and push, like an oldschool adventure game. Think Legend of Zelda: Link to the Past, as far as mechanics, but with ten players running around at the same time. Obviously, It's a lot for developers to work on, because to develop puzzles for that size group, there's a lot of thought involved.
That's why the second half of the game is based around building. On a website separate from the played game, players will be invited to create dungeons. The computer will assess the difficulty of the puzzles, as well as the enemies, and pay the player for their maps in in-game gold.
I'll focus more on the dungeon builder in my next post, but I wanted to give you a taste of it.
As far as plot goes, I actually imagine this game as fairly classic. It's an adventure game set in a somewhat steam-powered fantasy world. Swords and sorcery and steam, if you will. There are five types of class: Fighter, Healer, Mage, Thief, and for lack of a better term, a red mage. The fighter, obviously is geared toward combat, healer toward healing, and mage toward magic. The thief has abilities more geared toward status effects, stealing and light damage, while the red mage is a fair balance between magic and fighting. Each character has two assignable attack slots, one for left click, and one for spacebar. The left click would be especially suited for things like arrows, throwing knives, or spells, which would be aim-able via the mouse. While the spacebar would be good for short-range attacks. However, when the player is standing next to a chest, door, person or switch, the spacebar would become the "Action button" allowing them to acivate those things, or to speak to a person. Movement would be controlled by WASD.
I think that most of the plot would be devoted to being roving adventurers, saving princesses, defeating monsters and saving villages. However, through the building system, some dungeons could be linked together into campaigns, with full-blown story archs. It would allow people who are drawn to the dungeons and dragons to create a full story for their friends to play, without having to worry about managing dice rolls and mechanics, since the game will handle all of that already. Players could even divide the task of dungeon building in an arch, so that no player knows all of the dungeons, and everyone could play together.
As I said earlier, I'll get into dungeon building in my next post. Hopefully you enjoy the concept so far, I have a lot of Ideas for this game, and would love to work with a team to create it.
P.s. If you decided to create this game, please let me know, and please give me credit for the original concept. If someone does make it, I'll do my very best to help you publicize, and I'd even be willing to collaborate, if needed. Thanks!
Wednesday, December 28, 2011
Invasion
So, as promised, here's another idea for a game.
This one takes advantage of the wii platform, but could also work on the xbox Kinect, or the ps3's new motion control system. It's a formula that has been used on the wii already, but not to good effect.
Basically, the game is a rail shooter, in the style of Time Crisis, but with several improvements on the formula, and particularly improvements on what (I believe) the wii has seen so far in the genre.
First of all, let me roll into atmosphere, the flavor of it. Not because it's the most important aspect, certainly, but because the flavor makes the other elements seem more tangible. The game is set in a science-fiction universe. It's a mildly playful style, bright and colorful. The story starts in a liquor store, where the hero is working as a clerk. Large booming sounds reverberate outside, a low rumble fills the sky, and shadows creep across the street. The hero steps out from behind the counter, and dashes into the street, in time to see an alien spacecraft filling the skies. In a rush, pods smash into the ground, and burst open, with alien marines dashing out and instantly vaporizing several nearby humans. The hero runs backward into the liquor store, and crawls under the counter, where a pistol is laying next to the alarm button. The hero grabs the pistol, just as one of the aliens enters the liquor store. In six shots, the alien is dead, and the hero is out of bullets. The alien has dropped a gun, however, and the hero runs to pick it up. The hero goes into the streets and battles through aliens and machines and the chaos of humans in terror to make it home to their family.
So, hopefully, that flavor enticed you enough to listen to some mechanical talk. Anyway, here's the deal: the problem with rail shooters is that they are essentially the same thing as shooting gallery games. Normally, it is a short sequence of running, during which you have no control, followed by a short section of shooting, then your character runs again. Here's a key difference for the shooter I am proposing bears several differences, primarily in that structure there. The player is given much more control over their character, using the nunchuck. Firstly, the hero is in control of hiding behind cover. Holding the Z button raises the hero up from behind cover. Moving behind cover automatically reloads the hero's gun. There are two other buttons on the nunchuck that come into play: firstly, the c-button, which is used to change weapons. The key to that is that to press the c button more or less requires you to release Z, moving you into cover, which is the only place you can change weapons. The other button on the nunchuck that matters is the analogue stick. Rail shooters always lock the player into one single line of sight: forward. The analogue stick is used to turn the hero's field of view, a total of ninety degrees in all directions, and when the stick is released, it moves to a neutral center. What it means is that the player feels more in control of their play, and the gameplay becomes more immersive.The player can also move their camera and shoot during all of the moving portions. They are playing at all times, which is important. It helps blur the line between rail shooter and first-person-shooter. A lot of players hesitate to play rail-shooters because they feel that the experience is lacking compared to a first-person-shooter because of the difference between movement, and the length of time waiting for action to resume.
At the beginning of each chapter, the player is given the option of choosing their load-out for the trip. They will always have the pistol they stole from the first alien, which does not run out of ammo. They will also have two slots for other guns. The hero can gather more guns as they fight through their adventure, sometimes by shooting certain enemies, sometimes by finding them behind cover, and other things like that.
One last thing that is missing from rail shooters is the feeling of choice. Fortunately, the mechanics I'm suggesting make it possible to split the track that the player is on. When the hero is in a running portion, occasionally two arrows will flash on screen, suggesting two paths. The player will use the analogue stick to choose a path, and the story will go in that direction. There may also be instances where the arrows will not flash on screen, but holding the stick during a run will change paths anyway, allowing for secrets.
I think I could write more on this game, actually, but for now, it is 2:24 at night, and I am incredibly sleepy. If you are interested in hearing more, let me know in the comments!
This one takes advantage of the wii platform, but could also work on the xbox Kinect, or the ps3's new motion control system. It's a formula that has been used on the wii already, but not to good effect.
Basically, the game is a rail shooter, in the style of Time Crisis, but with several improvements on the formula, and particularly improvements on what (I believe) the wii has seen so far in the genre.
First of all, let me roll into atmosphere, the flavor of it. Not because it's the most important aspect, certainly, but because the flavor makes the other elements seem more tangible. The game is set in a science-fiction universe. It's a mildly playful style, bright and colorful. The story starts in a liquor store, where the hero is working as a clerk. Large booming sounds reverberate outside, a low rumble fills the sky, and shadows creep across the street. The hero steps out from behind the counter, and dashes into the street, in time to see an alien spacecraft filling the skies. In a rush, pods smash into the ground, and burst open, with alien marines dashing out and instantly vaporizing several nearby humans. The hero runs backward into the liquor store, and crawls under the counter, where a pistol is laying next to the alarm button. The hero grabs the pistol, just as one of the aliens enters the liquor store. In six shots, the alien is dead, and the hero is out of bullets. The alien has dropped a gun, however, and the hero runs to pick it up. The hero goes into the streets and battles through aliens and machines and the chaos of humans in terror to make it home to their family.
So, hopefully, that flavor enticed you enough to listen to some mechanical talk. Anyway, here's the deal: the problem with rail shooters is that they are essentially the same thing as shooting gallery games. Normally, it is a short sequence of running, during which you have no control, followed by a short section of shooting, then your character runs again. Here's a key difference for the shooter I am proposing bears several differences, primarily in that structure there. The player is given much more control over their character, using the nunchuck. Firstly, the hero is in control of hiding behind cover. Holding the Z button raises the hero up from behind cover. Moving behind cover automatically reloads the hero's gun. There are two other buttons on the nunchuck that come into play: firstly, the c-button, which is used to change weapons. The key to that is that to press the c button more or less requires you to release Z, moving you into cover, which is the only place you can change weapons. The other button on the nunchuck that matters is the analogue stick. Rail shooters always lock the player into one single line of sight: forward. The analogue stick is used to turn the hero's field of view, a total of ninety degrees in all directions, and when the stick is released, it moves to a neutral center. What it means is that the player feels more in control of their play, and the gameplay becomes more immersive.The player can also move their camera and shoot during all of the moving portions. They are playing at all times, which is important. It helps blur the line between rail shooter and first-person-shooter. A lot of players hesitate to play rail-shooters because they feel that the experience is lacking compared to a first-person-shooter because of the difference between movement, and the length of time waiting for action to resume.
At the beginning of each chapter, the player is given the option of choosing their load-out for the trip. They will always have the pistol they stole from the first alien, which does not run out of ammo. They will also have two slots for other guns. The hero can gather more guns as they fight through their adventure, sometimes by shooting certain enemies, sometimes by finding them behind cover, and other things like that.
One last thing that is missing from rail shooters is the feeling of choice. Fortunately, the mechanics I'm suggesting make it possible to split the track that the player is on. When the hero is in a running portion, occasionally two arrows will flash on screen, suggesting two paths. The player will use the analogue stick to choose a path, and the story will go in that direction. There may also be instances where the arrows will not flash on screen, but holding the stick during a run will change paths anyway, allowing for secrets.
I think I could write more on this game, actually, but for now, it is 2:24 at night, and I am incredibly sleepy. If you are interested in hearing more, let me know in the comments!
P.s. If you decided to create this game, please let me know, and please give me credit for the original concept. If someone does make it, I'll do my very best to help you publicize, and I'd even be willing to collaborate, if needed. Thanks!
Wednesday, December 21, 2011
The ghost's castle
So, I spend a lot of time thinking about games, and about game design. Maybe you've noticed. Anyway I've decided that since I never seem to have the time to actually execute any games, and haven't really had time to create anything playable (after all, I barely take the time to update this blog) I've decided to share some ideas for games and see if the ideas get picked up by anyone with the time and knack. So, here we go!
The first concept is an exploration-based adventure game. The protagonist has been kidnapped by otherworldlies, say fairies, or spirits, and dropped into an old castle, drifting in and endless space, to teach the hero a lesson about his/her life. The castle is vast, with gardens, towers, grand halls, and a multitude of varied rooms. Many, maybe most of these rooms, are empty when the hero first enters them. But, after solving a few puzzles in some of the fuller rooms, the hero finds the first of several masks. The masks resemble people from his life, possibly through one characteristic, definitely not through facial emulation, because that's creepy. Anyway, The hero finds the mask, and puts it on, and in doing so, the castle changes before them. Suddenly, rooms that were empty are furnished, there are more puzzles to solve, and from time to time, people pass through the halls.
The hero tries to address the people in the halls, but the figures just carry out their actions. They act out scenes from the hero's life, moments of regret, choices made, etc. They are all dressed in fancy clothing, ball gowns, suits, and masks, as if they are all attending a masquerade, which they are. All of the figures are fairies, or spirits, playing their part in the heroes' past. As the hero progresses through the flashbacks and puzzles, he or she eventually finds another mask, which reveals a different set of full rooms, events and the like. The hero eventually finds a total of say, seven masks. Each one reveals a different set of rooms and puzzles, and helps the hero understand their mistakes, and eventually, to come to understand what they must do to set things right.
The important thing about the masks is that they don't change the castle, they just reveal what is there. From the very start, just about all rooms are accessible, only one or two doors are ever locked, and they are unlockable by things hidden by the masks.
Now, I just realized that I had planned on spouting out about three games in this one post, but since I ended up writing a whole big chunk about that one idea, I've decided to break this up into a few different posts. So, expect the second in a week or so.
P.s. If you decided to create this game, please let me know, and please give me credit for the original concept. If someone does make it, I'll do my very best to help you publicize, and I'd even be willing to collaborate, if needed. Thanks!
The hero tries to address the people in the halls, but the figures just carry out their actions. They act out scenes from the hero's life, moments of regret, choices made, etc. They are all dressed in fancy clothing, ball gowns, suits, and masks, as if they are all attending a masquerade, which they are. All of the figures are fairies, or spirits, playing their part in the heroes' past. As the hero progresses through the flashbacks and puzzles, he or she eventually finds another mask, which reveals a different set of full rooms, events and the like. The hero eventually finds a total of say, seven masks. Each one reveals a different set of rooms and puzzles, and helps the hero understand their mistakes, and eventually, to come to understand what they must do to set things right.
The important thing about the masks is that they don't change the castle, they just reveal what is there. From the very start, just about all rooms are accessible, only one or two doors are ever locked, and they are unlockable by things hidden by the masks.
Now, I just realized that I had planned on spouting out about three games in this one post, but since I ended up writing a whole big chunk about that one idea, I've decided to break this up into a few different posts. So, expect the second in a week or so.
P.s. If you decided to create this game, please let me know, and please give me credit for the original concept. If someone does make it, I'll do my very best to help you publicize, and I'd even be willing to collaborate, if needed. Thanks!
Monday, October 31, 2011
The Haunt: Finale!
Okay, dear readers, the Haunted Library is finally over! So, as promised, I'm doing one more post about it, looking back on what I would (and likely will) do differently next year. Now, you may have heard the phrase "pics, or it didn't happen," as it turns out, none of us remembered this, so we have no proof that we ever performed this haunt. I have a few phone pictures of a few props being built, which I will put on a page HERE with the maze, but without pictures of everything installed in the library, I'll excuse your skepticism. As for the video I mentioned, It exists, but is really just five minutes of black with occasional flickers of faces and light. it's pretty lousy, so I've decided not to put it up.Now for the good news. On Friday, we put the haunted house up starting at about ten am, and finishing at about 5:10 pm. With a total of four actors in the haunt, we managed to scare the daylights out of a total of 378 guests, and earned as many dollars for the library to buy books with! Or, in other words, the Haunt was a huge success! While we didn't manage to get everything working that we wanted to, we put together enough of a haunt that people were going through more than once, and had a fantastic time.
Subscribe to:
Posts (Atom)