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!
Subscribe to:
Posts (Atom)