Full Games List
Featured Games
New Games
Reviews
Media
Images
Blogs
Game Updates
Images Feedback Summary
Game Design Highlights
Tutorials
Articles
Scripts
Utilities / Plugins
Resources
Engines
Engine Bulletins
What is Makerscore?
Past Events
Achievements
Misaos
Forums
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
Profile
Locker
Play ListsROOTS'S PROFILE
Roots
14
Close
I'm a professional software engineer. I've spent my spare time over the last several years working on an open source RPG project that I founded.
Search
Home interior tileset I've been working on
I've been working on this tileset for about a week and wanted to share what I've got so far. A lot of the original wall designs and texturing was done by a much better artist than I. But that tileset was incomplete, and could only really build rectangular structures. There were also some problems with repeat-ability for certain tiles. So I fixed those issues by creating various corners and other structures to make the walls more dynamic.
That's a mockup of what I've got so far. I'm building maps with it for my game right now and finding some further issues and holes with it that I'm addressing. What do you guys think? I'm pretty proud of the work I've done, even though I didn't start this from scratch.
Once I have the final version complete, I'm going to upload it to OpenGameArt under a permissive license for other projects to use. Things I plan to add include some more wall transitions so you can have, for example, 4-way intersections with interior walls. Also I've completed railing for the stairs that make them look more natural. Other things I plan to include are stairwell doors that can be pasted onto the walls and a wooden railing and ledge so that those wooden floorboards can be used as a loft. I welcome any other suggested additions.
That's a mockup of what I've got so far. I'm building maps with it for my game right now and finding some further issues and holes with it that I'm addressing. What do you guys think? I'm pretty proud of the work I've done, even though I didn't start this from scratch.
Once I have the final version complete, I'm going to upload it to OpenGameArt under a permissive license for other projects to use. Things I plan to add include some more wall transitions so you can have, for example, 4-way intersections with interior walls. Also I've completed railing for the stairs that make them look more natural. Other things I plan to include are stairwell doors that can be pasted onto the walls and a wooden railing and ledge so that those wooden floorboards can be used as a loft. I welcome any other suggested additions.
Are there examples of a battle system where max HP/MP decreases?
I'm working on a JRPG that is custom built and we recently designed and implemented a feature that we call battle fatigue. In a nutshell, instead of reducing your HP/SP (we use SP instead of MP) in battles, we reduce the max HP/SP instead. Are there any other JRPGs out there that have a system like this? I've played dozens in my life and I don't recall ever seeing anything like this.
Here are the motivations that we have for our battle system that gave birth to this design.
And here's a more detailed explanation about the feature itself.
There are several implications to player strategy as a result of battle fatigue. If the player is constantly using their most powerful abilities to end a battle quickly, toward the end of the dungeon they'll find that their max SP is very low and they will struggle a little more against tougher enemies and bosses. At the same time, if the player is too conservative with their skill usage and takes too much damage from drawn-out battles, their HP fatigue climbs greatly and they have a lower max HP when they face the tougher enemies deeper into a dungeon. The player must develop a strategy and carefully manage both types of battle fatigue to be successful.
1. Are there any other JRPGs out there that use a similar mechanic?
2. As a player, what are your initial thoughts/impressions about this type of battle design?
I know it's hard to get a strong opinion toward something that is just words and an idea without playing it first, so I'm looking more for just a "gut feeling" sort of impression. We already have this feature fully working in the game, but we still need to do some re-balancing work to fully realize it.
Here are the motivations that we have for our battle system that gave birth to this design.
- Remove the tediousness of players needing to go to the party menu to heal/restore HP and SP after battle
- Every character skill should be viable to use in any battle; We do not want players to only use their most basic skills for normal encounters and only their most powerful skills for boss fights
- The player should be penalized if they use their most powerful attacks too frequently
- Players should have a long-term strategy to a dungeon. They shouldn't chose actions thinking only about the current battle, but future battles as well.
- Determine a way for SP to restore naturally during battle so that the player feels encouraged to use more powerful skills regularly in battle
And here's a more detailed explanation about the feature itself.
- All characters are restored to full HP and SP at the end of every battle.
- SP regenerates a small amount every turn in battle.
- When a character loses HP, they accumulate HP fatigue. This fatigue reduces the max health HP of the character.
- When a character consumes SP (by using a skill), they accumulate SP fatigue. This fatigue reduces their max SP of the character.
- Fatigue persists between battles, meaning that the more battles the character party fights, the lower their max HP and max SP becomes.
- Fatigue is only removed by visiting an inn and resting. It is not something you can remove with an item or other readily available mechanic.
- Characters have two attributes that determine fatigue accumulation: stamina for HP fatigue, and resilience for SP fatigue.
- A higher stamina attribute causes HP fatigue to accumulate more slowly. The same holds true for resilience and SP fatigue.
There are several implications to player strategy as a result of battle fatigue. If the player is constantly using their most powerful abilities to end a battle quickly, toward the end of the dungeon they'll find that their max SP is very low and they will struggle a little more against tougher enemies and bosses. At the same time, if the player is too conservative with their skill usage and takes too much damage from drawn-out battles, their HP fatigue climbs greatly and they have a lower max HP when they face the tougher enemies deeper into a dungeon. The player must develop a strategy and carefully manage both types of battle fatigue to be successful.
1. Are there any other JRPGs out there that use a similar mechanic?
2. As a player, what are your initial thoughts/impressions about this type of battle design?
I know it's hard to get a strong opinion toward something that is just words and an idea without playing it first, so I'm looking more for just a "gut feeling" sort of impression. We already have this feature fully working in the game, but we still need to do some re-balancing work to fully realize it.
Hero of Allacrost - Team building for a RPG with a recent release
About
Hero of Allacrost is a single player 2D role-playing game inspired by classic console RPGs. In Hero of Allacrost, the player will explore rich environments, solve challenging dungeon puzzles, and fight strategic battles in an active-time based system. The game is free open-source software, built using a custom engine, and is currently available across several platforms including Windows, OS X, Linux, and FreeBSD. In addition to the game, we also develop and release a custom map editor for the game.
The three major design goals we are striving to meet with this title are listed below.
- Prioritize efforts on developing engaging gameplay and a compelling narrative
- Eliminate tedious and micromanagement mechanics that are commonly found in RPGs.
- Make battles interesting, challenging, and requiring of a high level of strategy from the player
The About page on our website describes several of the game's core features and how they enable us to meet these goals. The RMN game page for this project is available here.
Activity
Our latest release was in June 2015. This was a development release, which is essentially a snapshot of our work in progress. Below is a link to download it as well as a walkthrough video of this release with commentary.
- Release Files: http://www.allacrost.org/download
- Release Video:
The next milestone we're working toward is another development release that continues where our previous release left off, which will finish out the current "chapter" of the game. The major requirements for this release include map design, scripting, and creation of some additional artwork (map tilesets and around a dozen sprites). The anticipated date of this next release is sometime in September 2015. This is what our team will be working on for the next couple of months.
By the end of this year, we will be making an official release. This will be a fully designed, balanced, and polished product. It will be an iterative improvement of the September 2015 development release with some amount of additional content and improved event scripting, dialogue, and several noticeable improvements in the UI and other areas of the code. This is the team's current long-term goal. More information about our upcoming releases can be found on the Roadmap page on our wiki. This includes a list of all the major tasks that must be done along with their current status.
Compensation
Allacrost is created and distributed for free. Because of this we cannot offer financial compensation to those who work on the project. Our team members are quite content with putting forth their efforts into what we believe will someday be a great game to share. We learn a lot from each other on the Allacrost team and you will absolutely learn new techniques and skills from those whom you work aside with. Having this experience will also make you a much more attractive candidate if you are seeking to enter into the gaming industry. Some of our team members have been solicited by recruiters for well-known game development companies. Your full name will appear in the game credits.
Talent Needed
This project took a long hiatus and as a result has a very small team at the moment. We would really like to rebuild a team of dedicated, passionate individuals who share the vision of what Allacrost is to become and want to be a part of making it happen. Becoming a member of this team means more than simply getting told what to create. We strongly encourage people to participate in design discussions and offer their own ideas to improve the game and the project itself. Although the core design of Allacrost is pretty well-defined at this point, there's still a lot of unanswered design questions and features we have not yet implemented. There's still plenty of room for you to influence this title should you be interested in doing so. While we are seeking core team members, we're also happy to welcome contributors who prefer to help out here and there with adding a new feature or creating new art or music, but aren't as invested in this project.
You can read more about what it's like on the Allacrost team and our philosophies by reading about our team policies on our wiki. Listed below are the specific needs that we are seeking to fill and what people who fill those roles can expect to be working on for the next couple of months.
Game Designer
A game designer is one who assembles and combines the code, art, and music produced to create the game's experience. One of the primary responsibilities of game designers is to create maps using our editor and write the scripting code to make those maps come alive. For our next release, our designer's main focus will be on the expansion and scripting of an existing large map. There will also be work involving the design of battle skills, enemies, and perhaps some balancing involved.
Links:
(1) - Various pages of information for our game designers
(2) - Qualifications and skills needed, as well as directions on how to get started
(3) - A list of content on our roadmap that our designers need to complete
Pixel Artist
Pixel artists create the majority of the game's graphical assets. This includes map tilesets, sprites, and various other in-game artwork. Pixel artists have a large amount of freedom and those in the past have gifted us with some quite brilliant pieces. Below are some examples of our current pixel artwork so you can get an idea of our style. If you feel this above your skill level, please don't be intimidated. Even programmers create some of the art occasionally, and they are certainly not this skilled. The most immediate needs for pixel art include: a castle interior tileset, various demon sprites, and a few more sprites that represent townspeople.
Links:
(1) - Information on rights to an artist's work and how to get started
(2) - Lists the types of artwork found in Allacrost. The Maps, Sprites, and Icons sections cover pixel art
(3) - Explanation of our artistic styles, influences, and design
Traditional Artist
In addition to pixel art, Allacrost integrates usage of some more traditional artwork styles as well. These commonly come in the form of portraits and landscapes. See below for examples of this type of artwork. The most immediate needs for our traditional art include: face portraits for some major NPC characters, a body portrait of a generic soldier, and a landscape representing a desert castle-town.
Links:
(1) - Information on rights to an artist's work and how to get started
(2) - Lists the types of artwork found in Allacrost. The Backdrops and Portraits sections cover traditional art
(3) - Explanation of our artistic styles, influences, and design
Composer
Allacrost already has a number of tracks unique to the game and a thematic arrangement. But we are still missing a couple crucial pieces of music to complete our next release. These include: a "danger" theme to be played when a city is under attack, and a "legend" theme played when the main legend of the game is first heard. Below are links to some of our current compositions.
Links:
(1) - Musical influences, style, and technical information
(2) - Selections from our soundtrack available on our website
Writer
The most important responsibility of a writer is constructing the dialogues seen in the game. They also assist with the narrative (a novel) that the game's story is based off of. Writer's also have the unique ability to strongly influence the events and actions that occur through the game by using their written dialogues and imaginging scenes for us to produce to fit. The most immediate need we have for a writer at the moment is to improve the existing dialogue in the last release (which is essentially a placeholder at the moment) and to help with the design and dialogues that will take place in the next release.
Links:
(1) - Two full chapters of the standalone narrative that the game is based on.
Joining
Follow this link for information on how to join our team and what you can expect from working on this project. If you have questions or wish to give feedback, feel free to either post a reply in this thread or contact me directly if you wish to inquire in private.
Hero of Allacrost - Pixel artist needed for a high-quality title
About the Game
Hero of Allacrost (http://www.allacrost.org) is a RPG that has been in development for a number of years. It uses an open source custom engine and is cross-platform, available on Windows, OS X, Linux. We've released several demos (mini-RPGs) using our assets and technology in the past, and are now working toward the full title.
In a nutshell, Allacrost is inspired from SNES-era RPGs and tries to improve upon the formula. Our three primary design goals include:
All of our major features are designed with this criteria in mind. Our About Page explains some of these core features, such as status effects with various levels of intensity and the ability to target specific areas on an enemy to reduce their strength, etc.
About the Art
We use 32x32 pixel tiles and sprites that are 32x64 pixels. Here's a sample of our artwork assets so you can get a sense of our visual style.
Here are a few links to where you can view more artwork if you are so inclined.
Screenshots - most of these are very old
http://www.allacrost.org/multimedia/screenshots
Artwork Style - explains our artistic style and influences
http://www.allacrost.org/wiki/index.php/Artwork_Style
Artwork Categories - lists all of the various types of artwork we use in the game
http://www.allacrost.org/wiki/index.php/Artwork_Categories
What We Need
We're well on our way to getting the first chapter of our game released. We have about 80% of the art we need, but recently we've found that our missing assets are holding us back. Most critically, we need to finish some artwork for a castle/city map in a desert setting. Below are a couple screenshots from this map (keep in mind that it is a work in progress) and a link to the full album.
(This one is concept art for the environment we are creating)
FULL ALBUM
Some of the things we are most in need of to complete this map include:
This thread on our forums elaborates on this list. Some of these tasks are easy, and some are more challenging. I've been knocking out a couple of them myself this week. Although if tile/environment art isn't your thing, there's plenty of other art to do (including non-pixel art). Sprites, spell effects, and so on are all on the table. Map art is simply our highest priority at this time.
How to Help
Visit http://www.allacrost.org/contribute to find out how to contribute to the project. There's no formal process or anything. This page simply gets you pointed in the right direction to better understand what Allacrost is, what is expected of contributors, and how to get the most out of your time on the team. Essentially all you have to do is make an account on our forums, state that you'd like to help, and you'll be on your way.
The following page on our wiki is really informative: New Artists. We accept artists regardless of their skill level, so don't be intimidated if you think you the level of art is above your abilities. We'd rather have a novice artist than no artist at all, and we can help you learn and grow. You will retain the full rights for all content that you create for Allacrost. The only thing you give away is permission for us to use your creations in our title. We also make our assets available for others to use at OpenGameArt.org.
This is a non-commercial project that is made freely available to those who wish to experience it. There's no financial compensation, as this is a labor of love for us all. Our compensation comes in the form of developing our skills, learning new things, and having a stellar title in our resume/portfolio. And most of all, it's fun. If we didn't have fun creating this, we wouldn't still be doing it.
Please feel free to reply to this thread with any questions, comments, feedback, etc. You can send me a PM if you'd like to ask something confidentially. Thanks!
Hero of Allacrost (http://www.allacrost.org) is a RPG that has been in development for a number of years. It uses an open source custom engine and is cross-platform, available on Windows, OS X, Linux. We've released several demos (mini-RPGs) using our assets and technology in the past, and are now working toward the full title.
In a nutshell, Allacrost is inspired from SNES-era RPGs and tries to improve upon the formula. Our three primary design goals include:
- Design the game such that the major focus is on gameplay and story, not advanced 3D graphics and physical simulations.
- As much as possible, remove the tedious, meaningless, and micromanaging aspects of many historical and modern RPGs.
- Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs.
All of our major features are designed with this criteria in mind. Our About Page explains some of these core features, such as status effects with various levels of intensity and the ability to target specific areas on an enemy to reduce their strength, etc.
About the Art
We use 32x32 pixel tiles and sprites that are 32x64 pixels. Here's a sample of our artwork assets so you can get a sense of our visual style.
Here are a few links to where you can view more artwork if you are so inclined.
Screenshots - most of these are very old
http://www.allacrost.org/multimedia/screenshots
Artwork Style - explains our artistic style and influences
http://www.allacrost.org/wiki/index.php/Artwork_Style
Artwork Categories - lists all of the various types of artwork we use in the game
http://www.allacrost.org/wiki/index.php/Artwork_Categories
What We Need
We're well on our way to getting the first chapter of our game released. We have about 80% of the art we need, but recently we've found that our missing assets are holding us back. Most critically, we need to finish some artwork for a castle/city map in a desert setting. Below are a couple screenshots from this map (keep in mind that it is a work in progress) and a link to the full album.
(This one is concept art for the environment we are creating)
FULL ALBUM
Some of the things we are most in need of to complete this map include:
- A tileset for the castle's interior
- Items to complete a throne room
- Interior walls for the houses in our town
This thread on our forums elaborates on this list. Some of these tasks are easy, and some are more challenging. I've been knocking out a couple of them myself this week. Although if tile/environment art isn't your thing, there's plenty of other art to do (including non-pixel art). Sprites, spell effects, and so on are all on the table. Map art is simply our highest priority at this time.
How to Help
Visit http://www.allacrost.org/contribute to find out how to contribute to the project. There's no formal process or anything. This page simply gets you pointed in the right direction to better understand what Allacrost is, what is expected of contributors, and how to get the most out of your time on the team. Essentially all you have to do is make an account on our forums, state that you'd like to help, and you'll be on your way.
The following page on our wiki is really informative: New Artists. We accept artists regardless of their skill level, so don't be intimidated if you think you the level of art is above your abilities. We'd rather have a novice artist than no artist at all, and we can help you learn and grow. You will retain the full rights for all content that you create for Allacrost. The only thing you give away is permission for us to use your creations in our title. We also make our assets available for others to use at OpenGameArt.org.
This is a non-commercial project that is made freely available to those who wish to experience it. There's no financial compensation, as this is a labor of love for us all. Our compensation comes in the form of developing our skills, learning new things, and having a stellar title in our resume/portfolio. And most of all, it's fun. If we didn't have fun creating this, we wouldn't still be doing it.
Please feel free to reply to this thread with any questions, comments, feedback, etc. You can send me a PM if you'd like to ask something confidentially. Thanks!
Looking for tips and feedback from experienced map designers
I'm working on a RPG that is made with a custom engine and editor. At the moment I'm working on producing a rather large city/castle map, and I was hoping to get some feedback on the early designs. If there are any resources you can point me to as far as tutorials, etc. that can teach the fundamentals of map design, I'd appreciate it if you could point me in that direction.
Below is a link to the screenshots of the current draft of this map. It is still largely incomplete but has all of the major structures there except for the castle which will be built atop the cliffs. Please ignore the obvious graphical glitches like some of the shadows are wrong and the roof tiles are not repeatable. That's not what I'm looking for feedback on.
http://imgur.com/a/ttfGE
Some important features to note about this map and our game in general:
We've put together some release demos in the past and the maps were less than stellar. I really don't want to feel the same disappointment with our maps again. Here's a video of what I mean (the first minute or so is all you need to watch). The maps were massively large and very empty. They just weren't that interesting.
So am I on the right track with this map so far? What do you feel would improve it the most? Here's a link to the project website if you're interested in learning more about what we're seeking to create.
Hero of Allacrost - Website
Below is a link to the screenshots of the current draft of this map. It is still largely incomplete but has all of the major structures there except for the castle which will be built atop the cliffs. Please ignore the obvious graphical glitches like some of the shadows are wrong and the roof tiles are not repeatable. That's not what I'm looking for feedback on.
http://imgur.com/a/ttfGE
Some important features to note about this map and our game in general:
- The interiors of the homes must roughly the same size as the exteriors. This is because we don't contain our interiors on separate maps like most RPGs do. Thus, the structures have to be large.
- I tried to vary the size/orientation of the structures so that the town doesn't feel like a maze of nearly identical houses.
- I'm planning for only about half of these structures to be able to be entered by the player. I feel like having them all have an interior would make the map too complex, and removing houses would make the map feel too small (this is supposed to be a rather large city).
- I tried to make each area of the map somewhat unique so the player has "landmarks" as they explore the city the first time and understand what's in it and where things are. Also makes it a more interesting environment.
- The sprites are roughly as tall and half as wide as the entrances you see to the buildings, if that gives you a reference point.
- It should be obvious, but the in-game the view will be zoomed in quite a bit. I doubt you would be able to see the entire view of most of these structures if you place the player sprite directly in front of it.
We've put together some release demos in the past and the maps were less than stellar. I really don't want to feel the same disappointment with our maps again. Here's a video of what I mean (the first minute or so is all you need to watch). The maps were massively large and very empty. They just weren't that interesting.
So am I on the right track with this map so far? What do you feel would improve it the most? Here's a link to the project website if you're interested in learning more about what we're seeking to create.
Hero of Allacrost - Website
Improving Menu-Based Battle Systems
I've been developing a 2D RPG (link) built from scratch with a custom engine for a number of years that uses a menu-based battle system. One of my areas of concern is that your typical RPG menu-based battle is pretty dull, and I want to try and improve that with my game. So I'm going to throw some ideas at you guys and I'd like to hear your comments and suggestions, as well as receiving any ideas you all put forward to address the issues. Almost all of these ideas are already implemented and working in our current build of the game. We are still in the process of refining and improving them.
Before I begin with my ideas, first, let me list what I believe are the major downside to such battle systems.
Most battles require little skill from the player. Games typically have a basic "Attack" function that you can spam and win over half of your battles without a problem. These types of battles are not fun, and only serve to consume the player's time. Boss battles, on the other hand, typically require more focus and decision making from the player.
A significant percentage of the time spent in a battle involves the player taking no action. They are either waiting for some stamina/action meter to build up so that they can select an action for their characters, or they are watching action unfold on the screen. In turn-based systems, what often happens is that the battle is "paused" while you select actions for your characters. Then when your actions are selected, the player sits and watches (and does nothing) while the battle unfolds. The result is a "stop-and-go" system that is not very engaging, nor is it very fun in my opinion. Even if the battle does not pause while the player selects actions, they are still waiting a significant amount of time to select their actions or (in some games) watching certain abilities be used.
Here's a video of an old demo release of our game. If you watch the battles in this video, you can clearly see that our battle system suffers from those problems and that our battles are not very interesting.
Now allow me to present the ideas that we've been testing to solve these issues. While we were brainstorming these ideas, we made sure to keep in mind the three primary design goals we have for this title because we wanted these ideas to align to them as well.
Feature #1: Allow actions to target specific areas on an opponent
This is one of the oldest and most fundamental ideas for our battle system. Essentially, both enemies and characters have multiple areas on their bodies that can be targeted (arms, head, legs, wings, torso, etc.). Each target on the body has different strengths and weaknesses that can be taken advantage of. For example, target a warrior's arms to lower their attack strength. A successful hit to an opponents head will deal more damage, but the attack is more likely to miss. A hit to the legs may have a chance to lower an enemy's speed. And so on.
The idea with this feature is to increase the number of strategic options available to the player. They can choose to try and target high-damage areas to dispatch a foe more quickly. Or if the foe is annoyingly quick, the legs can be targeted to lower their speed. Many familiar RPGs sort of had a feature like this on certain boss encounters where you could target different parts for different effects. We simply expand this idea to apply it to essentially every enemy (and playable character) in the game.
Feature #2: Status Effects Have Multiple Intensities
Nearly every RPG implements some sort of status effect like poison, mute, etc. The problem with these is that it can be annoying to cure a status ailment, only to have the same enemy re-afflict the status on a character soon after they are cured. Often, status effects are simply ignored as they do not impact the characters enough to be worth the time to heal (for example, a characters with 5000HP that is poisoned only losses maybe 40HP a turn to the effect).
In our game, we have four different intensities for a status effect. The lowest intensity for poison only removes a small amount of HP from a character (say 20HP/turn), whereas the most severe status is much more devastating. The player is faced with a less clear decision of whether it is worthwhile to spend a turn to cure the status effect based on the intensity that it has.
Additionally, we allow all negative status effects (poison, stone, etc.) and positive status effects (strength+, agility+, etc.) to naturally dissipate over the course of the battle. Without the player doing anything, over time these status effects will gradually lessen in intensity until they disappear completely. The player must also consider this information in choosing whether or not to immediately cure it. Finally, all status effects are completely cured when a battle ends, meaning that the player doesn't have to go to the menu screen after battle and cure the various afflictions.
This is a simple change that makes status effects much more interesting. As was mentioned in idea #1, status effects may also be triggered simply by striking certain targets of enemies with an attack (a hit to the legs may reduce agility, etc).
Feature #3: Allow the player to pre-select actions for their characters
While the characters are in their idle state, the player can select the next action that they would like the character to take. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's no reason really to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
We also allow the selected action to be changed by the player at any time before they execute the action. If we didn't do this, players would be hesitant to pre-select actions because they may need to change their strategy based on what actions the enemy performs. We have this feature implemented in our game now and its working out pretty well.
Feature #4: Skills have a warm-up and cool-down period
For each character skill, we have a period of time where they need to prepare to use the skill, and another period where they have to recover from using the skill. The most basic skills do not have long periods of this time, while the more powerful attacks take considerably longer. Additionally, we've played around with the idea of making a character more vulnerable during these periods.
The purpose of this feature is to introduce more strategic depth to the player. In addition to the player having to consider the resource cost (MP) of using a powerful attack, they also must consider the additional time it takes for the skill to be used.
Feature #5: Blend damage frames together for enemies
This is more of a graphical feature than a design one, but it can still influence battle decisions. Instead of having a single static image for an enemy, we create four different images of the enemy representing various states of damage. We blend two of these frames together based on the current health percentage of an enemy. This way the player can get an idea of how badly hurt an enemy is.
Here are some examples of this from enemies in our game.
There are a few more features to our battle system, but I don't want to overwhelm this first post with our entire feature list. I'll add the others here later to add to the discussion. So what are your thoughts on these first five features? Do you like the ideas proposed? Do you think they help solve the fundamental problems in this type of battle system? Do you feel they would make battles more interesting and engaging, or more complicated and tedious? I look forward to hearing the opinions of people in this community. :)
Before I begin with my ideas, first, let me list what I believe are the major downside to such battle systems.
- Lack of strategy
Most battles require little skill from the player. Games typically have a basic "Attack" function that you can spam and win over half of your battles without a problem. These types of battles are not fun, and only serve to consume the player's time. Boss battles, on the other hand, typically require more focus and decision making from the player.
- Lack of player engagement
A significant percentage of the time spent in a battle involves the player taking no action. They are either waiting for some stamina/action meter to build up so that they can select an action for their characters, or they are watching action unfold on the screen. In turn-based systems, what often happens is that the battle is "paused" while you select actions for your characters. Then when your actions are selected, the player sits and watches (and does nothing) while the battle unfolds. The result is a "stop-and-go" system that is not very engaging, nor is it very fun in my opinion. Even if the battle does not pause while the player selects actions, they are still waiting a significant amount of time to select their actions or (in some games) watching certain abilities be used.
Here's a video of an old demo release of our game. If you watch the battles in this video, you can clearly see that our battle system suffers from those problems and that our battles are not very interesting.
Now allow me to present the ideas that we've been testing to solve these issues. While we were brainstorming these ideas, we made sure to keep in mind the three primary design goals we have for this title because we wanted these ideas to align to them as well.
- Design the game such that the major focus is on gameplay and story, not advanced 3D graphics and physical simulations.
- As much as possible, remove the tedious, meaningless, and micromanaging aspects of many historical and modern RPGs.
- Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs.
Feature #1: Allow actions to target specific areas on an opponent
This is one of the oldest and most fundamental ideas for our battle system. Essentially, both enemies and characters have multiple areas on their bodies that can be targeted (arms, head, legs, wings, torso, etc.). Each target on the body has different strengths and weaknesses that can be taken advantage of. For example, target a warrior's arms to lower their attack strength. A successful hit to an opponents head will deal more damage, but the attack is more likely to miss. A hit to the legs may have a chance to lower an enemy's speed. And so on.
The idea with this feature is to increase the number of strategic options available to the player. They can choose to try and target high-damage areas to dispatch a foe more quickly. Or if the foe is annoyingly quick, the legs can be targeted to lower their speed. Many familiar RPGs sort of had a feature like this on certain boss encounters where you could target different parts for different effects. We simply expand this idea to apply it to essentially every enemy (and playable character) in the game.
Feature #2: Status Effects Have Multiple Intensities
Nearly every RPG implements some sort of status effect like poison, mute, etc. The problem with these is that it can be annoying to cure a status ailment, only to have the same enemy re-afflict the status on a character soon after they are cured. Often, status effects are simply ignored as they do not impact the characters enough to be worth the time to heal (for example, a characters with 5000HP that is poisoned only losses maybe 40HP a turn to the effect).
In our game, we have four different intensities for a status effect. The lowest intensity for poison only removes a small amount of HP from a character (say 20HP/turn), whereas the most severe status is much more devastating. The player is faced with a less clear decision of whether it is worthwhile to spend a turn to cure the status effect based on the intensity that it has.
Additionally, we allow all negative status effects (poison, stone, etc.) and positive status effects (strength+, agility+, etc.) to naturally dissipate over the course of the battle. Without the player doing anything, over time these status effects will gradually lessen in intensity until they disappear completely. The player must also consider this information in choosing whether or not to immediately cure it. Finally, all status effects are completely cured when a battle ends, meaning that the player doesn't have to go to the menu screen after battle and cure the various afflictions.
This is a simple change that makes status effects much more interesting. As was mentioned in idea #1, status effects may also be triggered simply by striking certain targets of enemies with an attack (a hit to the legs may reduce agility, etc).
Feature #3: Allow the player to pre-select actions for their characters
While the characters are in their idle state, the player can select the next action that they would like the character to take. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's no reason really to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
We also allow the selected action to be changed by the player at any time before they execute the action. If we didn't do this, players would be hesitant to pre-select actions because they may need to change their strategy based on what actions the enemy performs. We have this feature implemented in our game now and its working out pretty well.
Feature #4: Skills have a warm-up and cool-down period
For each character skill, we have a period of time where they need to prepare to use the skill, and another period where they have to recover from using the skill. The most basic skills do not have long periods of this time, while the more powerful attacks take considerably longer. Additionally, we've played around with the idea of making a character more vulnerable during these periods.
The purpose of this feature is to introduce more strategic depth to the player. In addition to the player having to consider the resource cost (MP) of using a powerful attack, they also must consider the additional time it takes for the skill to be used.
Feature #5: Blend damage frames together for enemies
This is more of a graphical feature than a design one, but it can still influence battle decisions. Instead of having a single static image for an enemy, we create four different images of the enemy representing various states of damage. We blend two of these frames together based on the current health percentage of an enemy. This way the player can get an idea of how badly hurt an enemy is.
Here are some examples of this from enemies in our game.
There are a few more features to our battle system, but I don't want to overwhelm this first post with our entire feature list. I'll add the others here later to add to the discussion. So what are your thoughts on these first five features? Do you like the ideas proposed? Do you think they help solve the fundamental problems in this type of battle system? Do you feel they would make battles more interesting and engaging, or more complicated and tedious? I look forward to hearing the opinions of people in this community. :)
Revolutionizing Menu-Based Battle Systems
A couple years ago I was having a discussion online with some fellow open source game developers and the general consensus was (and I agree) that menu-based battle systems usually aren't that much fun. In a typical RPG, you wait, select an action (that 80-90% of the time is just "Attack"), wait again, select attack again, and repeat until you win. The battle pauses each time and so this action is really stop-and-go. This kicked off some gears in my brain and I started thinking about ways to improve this formula. I want to share my ideas with you guys and get a discussion going.
---
I'm going to start this discussion off by talking about it in direct reference to my own project, Hero of Allacrost. This game is written completely from scratch in C++, so the only real limits to the battle system design are our imaginations. First, let me state the high-level goals that we have for our battle system (and the game in general).
Now lets get to the set of ideas. There are many of them, so I'm only going to open with a handful of ideas and introduce others later in the discussion.
-----
Idea #1: Allow the player to pre-select actions for their characters before those characters are ready to execute their next command.
While the characters are in their idle state, the player can select actions for their characters. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's not really reason to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
Idea #2: Allow the player to change pre-selected actions for their characters
This goes along with idea #1. If the player selects an action for a character during the idle state and something happens which makes the player wish to change the action for the character (such as an ally was badly hurt and needs healing immediately), then we would allow the player to do so (but only if the character is still in the idle state, the warm-up state is too late to cancel). This would also apply toward changing the target. With this idea, we have to consider whether there would be any penalty associated with changing an action/target. We could completely reset the stamina bar back to zero and force the character to go through the entire idle state again, or we could apply a less severe penalty such as a 20%-50% reduction of the current idle time that has been met, or there could be no penalty at all. I think I'd rather see a small penalty, because this will cause the player to consider whether or not they want to select an action for their characters as soon as they can (at the 0-time mark in the idle state). But I'm undecided here.
Idea #3: Populate a small action + target hot-key menu to allow the player to quickly execute actions
In our menus, we currently sort actions by category (Attack, Defend, Support, Item) and we have cursor memory implemented as well (the menu remembers the previously selected action and target). But I've been toying with the idea of having a small number (four) of "hotkey" actions and targets for characters. This idea came to me because I realized that you often only want to change between a small number of actions and targets in battle. For instance, one character might be a designated healer, and when there is no healing needed you would instead want that character to "meditate" to regain lost magic points (called skill points in the case of my game), or to attack an enemy if no healing and no SP regeneration is needed. Three actions, and three targets that the player cycles between for this character. Going through the entire action selection menu and target selection menus each time they want to switch between one of these settings is kind of a pain in the ass, so we would have this hot-key command card available for the player to quickly switch between these actions and targets. It could either be auto-generated by the game (ie saves last x number of action + target combinations) or we could allow the player to configure this, either in and out of battle.
I also had thought that maybe we could limit the character's actions to what they could fit in the command card to create an additional depth of strategy for the player, as they would need to select which skills they brought into battle (and couldn't use all the skills they learned). For our purposes though I think this would be a bad idea, because the strategic benefit is outweighed by the negative cost of additional micromanagement needed by the player, plus it could be seen as an annoying limitation for many people (not to mention it doesn't have much of a practical explanation for why skills are limited).
Idea #4: Allow multiple actors (characters or enemies) to execute actions simultaneously
This is another idea to reduce the amount of time that the player is forced to sit and watch. Right now only one actor can execute an action at any time (in this sense the game is turn-based). But what if this was not the case, and we could have multiple characters and enemies all engaging each other at once? Perhaps we can even add a strategic element to this, and say that if two opposing actors engage each other at the same time, the one who strikes first will cancel the other's action completely.
It sounds like a promising idea I think if its implemented well, but I have a couple major concerns with it. First, it could cause battles to become very chaotic with swords and spells flying everywhere (but shouldn't battles be chaotic anyway?). Second, it may be difficult to implement both from a programming and an artistic perspective. And there may be other issues that I haven't thought of yet.
-----
For the record, we've already implemented ideas #1 and #2 in our game, and they have been working pretty darn well. I'm still interested to hear people's thoughts about it though. Here's a concept piece that I drew up for how this implementation would work:
The key are those arrow icons surrounded by the circles. When the circle is white, you can select an action for that character and you only need to hit the corresponding directional key on your gamepad or keyboard. When it is grey, you can't select an action (because they are about to execute the one that was last selected). If a character gets to the green marker on the stamina bar (right side of screen) and they don't have an action selected, the battle action stops and the player is forced to enter a command for that character before the game continues.
You can see it in action during this video here. Notice that the actors on the stamina bar continue to get closer to being ready to execute an action while I'm selecting commands for all four characters. Once the first actor is ready to attack, they can do so immediately and there's no sitting around and waiting. But you can still play it out as the traditional "wait mode" as well, if you prefer. The nice thing about this is that you can get through simple battles more quickly, but still be more methodical and careful about your action choices when facing tougher opponents, such as a boss.
(Go to the 5:40 mark to see the battle that I'm talking about)
-----
So what do you think about these ideas? What alternatives or improvements would you do if you were designing your own game from scratch?
---
I'm going to start this discussion off by talking about it in direct reference to my own project, Hero of Allacrost. This game is written completely from scratch in C++, so the only real limits to the battle system design are our imaginations. First, let me state the high-level goals that we have for our battle system (and the game in general).
author=Allacrost Design Goals
Design the game such that the major focus is on gameplay and story, not advanced 3D graphics and physical simulations.
As much as possible, remove the tedious, meaningless, and micromanaging aspects of many historical and modern RPGs.
Require a high level of strategic thinking and planning from the player, and less mindless "button mashing" found in many RPGs.
Now lets get to the set of ideas. There are many of them, so I'm only going to open with a handful of ideas and introduce others later in the discussion.
-----
Idea #1: Allow the player to pre-select actions for their characters before those characters are ready to execute their next command.
While the characters are in their idle state, the player can select actions for their characters. This solves the problem of the player having nothing to do when no characters are ready to execute an action. Of course the player can still wait until the stamina bar is full (and the character changes from the idle to the selection state), although there's not really reason to wait, unless the player is delaying the action selection based on the state of the enemies (ie if an enemy is seen charging up for a big attack, the player will want to put their character in a defensive state).
Idea #2: Allow the player to change pre-selected actions for their characters
This goes along with idea #1. If the player selects an action for a character during the idle state and something happens which makes the player wish to change the action for the character (such as an ally was badly hurt and needs healing immediately), then we would allow the player to do so (but only if the character is still in the idle state, the warm-up state is too late to cancel). This would also apply toward changing the target. With this idea, we have to consider whether there would be any penalty associated with changing an action/target. We could completely reset the stamina bar back to zero and force the character to go through the entire idle state again, or we could apply a less severe penalty such as a 20%-50% reduction of the current idle time that has been met, or there could be no penalty at all. I think I'd rather see a small penalty, because this will cause the player to consider whether or not they want to select an action for their characters as soon as they can (at the 0-time mark in the idle state). But I'm undecided here.
Idea #3: Populate a small action + target hot-key menu to allow the player to quickly execute actions
In our menus, we currently sort actions by category (Attack, Defend, Support, Item) and we have cursor memory implemented as well (the menu remembers the previously selected action and target). But I've been toying with the idea of having a small number (four) of "hotkey" actions and targets for characters. This idea came to me because I realized that you often only want to change between a small number of actions and targets in battle. For instance, one character might be a designated healer, and when there is no healing needed you would instead want that character to "meditate" to regain lost magic points (called skill points in the case of my game), or to attack an enemy if no healing and no SP regeneration is needed. Three actions, and three targets that the player cycles between for this character. Going through the entire action selection menu and target selection menus each time they want to switch between one of these settings is kind of a pain in the ass, so we would have this hot-key command card available for the player to quickly switch between these actions and targets. It could either be auto-generated by the game (ie saves last x number of action + target combinations) or we could allow the player to configure this, either in and out of battle.
I also had thought that maybe we could limit the character's actions to what they could fit in the command card to create an additional depth of strategy for the player, as they would need to select which skills they brought into battle (and couldn't use all the skills they learned). For our purposes though I think this would be a bad idea, because the strategic benefit is outweighed by the negative cost of additional micromanagement needed by the player, plus it could be seen as an annoying limitation for many people (not to mention it doesn't have much of a practical explanation for why skills are limited).
Idea #4: Allow multiple actors (characters or enemies) to execute actions simultaneously
This is another idea to reduce the amount of time that the player is forced to sit and watch. Right now only one actor can execute an action at any time (in this sense the game is turn-based). But what if this was not the case, and we could have multiple characters and enemies all engaging each other at once? Perhaps we can even add a strategic element to this, and say that if two opposing actors engage each other at the same time, the one who strikes first will cancel the other's action completely.
It sounds like a promising idea I think if its implemented well, but I have a couple major concerns with it. First, it could cause battles to become very chaotic with swords and spells flying everywhere (but shouldn't battles be chaotic anyway?). Second, it may be difficult to implement both from a programming and an artistic perspective. And there may be other issues that I haven't thought of yet.
-----
For the record, we've already implemented ideas #1 and #2 in our game, and they have been working pretty darn well. I'm still interested to hear people's thoughts about it though. Here's a concept piece that I drew up for how this implementation would work:
The key are those arrow icons surrounded by the circles. When the circle is white, you can select an action for that character and you only need to hit the corresponding directional key on your gamepad or keyboard. When it is grey, you can't select an action (because they are about to execute the one that was last selected). If a character gets to the green marker on the stamina bar (right side of screen) and they don't have an action selected, the battle action stops and the player is forced to enter a command for that character before the game continues.
You can see it in action during this video here. Notice that the actors on the stamina bar continue to get closer to being ready to execute an action while I'm selecting commands for all four characters. Once the first actor is ready to attack, they can do so immediately and there's no sitting around and waiting. But you can still play it out as the traditional "wait mode" as well, if you prefer. The nice thing about this is that you can get through simple battles more quickly, but still be more methodical and careful about your action choices when facing tougher opponents, such as a boss.
(Go to the 5:40 mark to see the battle that I'm talking about)
-----
So what do you think about these ideas? What alternatives or improvements would you do if you were designing your own game from scratch?
Mature non-RPGMaker project seeking designers and artists
Hi everyone. I run an open source project with the goal of producing a RPG in a style similar to Chrono Trigger and Final Fantasy VI. We've been working on the project for a long time and have released several demos in the past, and now we're at work to assemble the first of many parts of the full game (we release it in pieces at a time). I'm hoping that we can find people with past game design experience to do things like assemble maps, write scripts, and generally make the game come alive. It would be great if we could find some more artists to help out as well. Anyway, read on for a more complete description of the project, the roles we are looking to fill, and how to help out. I'll be happy to answer any questions and look forward to your feedback as well.
Project Description
Hero of Allacrost is a single player 2D role-playing game inspired by classic console RPGs. In Hero of Allacrost, the player will explore rich environments, solve challenging dungeon puzzles, and fight strategic battles in an active-time based system. The game is free open-source software and is currently available across several platforms including Windows, OS X, Linux, and FreeBSD. In addition to the game, we also develop and release a custom content editor for the game. Development on the game and editor began in June 2004. Our project has released numerous playable demos in the past and we are now working on production of the true game, starting with the first of many release modules to come.
Many great people from this community have found our project and joined our efforts throughtout the years. Our project took a long break last year, but we're back to work and need some additional help. This project has a lot of history behind it, and thanks to that we are now at a junction where our development efforts are no longer focused on code, but instead on content. What we need most right now are artists to help us fill in the missing gaps to our content and game designers to take art, music, sound, and code and tie it all together into what the player will experience. We have all of the code completed that is necessary to make this game come alive, but we could still use additional programmers to continue making progress on this front as well.
Very recently we produced a development video, which you can watch below. This video shows the game being played in real time in it's current state and includes commentary on missing artwork and design ideas that we've been discussing. Watching this video is the best way to get a feel for what this game is all about, so please have a look.
You may also wish to check out our roadmap to see a list of what we're currently working on and what is required for us to meet our next release goal.
http://www.allacrost.org/wiki/index.php/Roadmap
Compensation
No monetary compensation is offered through participation in the project and all members of the team work for free. Everyone has their own personal reasons for contributing, whether it is to gain experience for their resume or portfolio, improve their skills, or simply because they enjoy it.
Talent Needed
=== Game Designers ===
Game designers combine our code and content and craft the game's experience. This includes designing maps, crafting of enemy data, scripting of battle actions, balancing, and more. This is a great position for someone who is interested in making games, but lacks the skills to create game content themselves. Please see the following page for more information on what game designers do and what you can expect if you accept this role.
http://www.allacrost.org/wiki/index.php/New_Game_Designers
=== 2D Artists ===
The game artwork is developed in two complementary styles: traditional pixel art and digital painting. Please take a look at the following pages to get an idea of our artistic influences and style, and to learn more about being an artist on our project.
http://www.allacrost.org/wiki/index.php/New_Artists
http://www.allacrost.org/wiki/index.php/Artwork_Style
Website
http://www.allacrost.org
How to Join
Please see the following page on our wiki:
http://www.allacrost.org/wiki/index.php/New_Contributors
The best way to contact the team with a question or request is through our forum at http://www.allacrost.org/forum
You can also try joining our IRC channel at #allacrost at irc.freenode.net to see if anyone is around to speak to you.
And of course you can either reply to this thread with your questions, or send me a private message here if you would like to ask something privately.
Screenshots and Artwork
You can find all of our screenshots at http://www.allacrost.org/multimedia/screenshots . Unfortunately these are all old and the current state of the game has a slightly improved appearance. Here are some selections:
(The game is developed in English, but includes internationalization support so it can run in other languages).
Project Description
Hero of Allacrost is a single player 2D role-playing game inspired by classic console RPGs. In Hero of Allacrost, the player will explore rich environments, solve challenging dungeon puzzles, and fight strategic battles in an active-time based system. The game is free open-source software and is currently available across several platforms including Windows, OS X, Linux, and FreeBSD. In addition to the game, we also develop and release a custom content editor for the game. Development on the game and editor began in June 2004. Our project has released numerous playable demos in the past and we are now working on production of the true game, starting with the first of many release modules to come.
Many great people from this community have found our project and joined our efforts throughtout the years. Our project took a long break last year, but we're back to work and need some additional help. This project has a lot of history behind it, and thanks to that we are now at a junction where our development efforts are no longer focused on code, but instead on content. What we need most right now are artists to help us fill in the missing gaps to our content and game designers to take art, music, sound, and code and tie it all together into what the player will experience. We have all of the code completed that is necessary to make this game come alive, but we could still use additional programmers to continue making progress on this front as well.
Very recently we produced a development video, which you can watch below. This video shows the game being played in real time in it's current state and includes commentary on missing artwork and design ideas that we've been discussing. Watching this video is the best way to get a feel for what this game is all about, so please have a look.
You may also wish to check out our roadmap to see a list of what we're currently working on and what is required for us to meet our next release goal.
http://www.allacrost.org/wiki/index.php/Roadmap
Compensation
No monetary compensation is offered through participation in the project and all members of the team work for free. Everyone has their own personal reasons for contributing, whether it is to gain experience for their resume or portfolio, improve their skills, or simply because they enjoy it.
Talent Needed
=== Game Designers ===
Game designers combine our code and content and craft the game's experience. This includes designing maps, crafting of enemy data, scripting of battle actions, balancing, and more. This is a great position for someone who is interested in making games, but lacks the skills to create game content themselves. Please see the following page for more information on what game designers do and what you can expect if you accept this role.
http://www.allacrost.org/wiki/index.php/New_Game_Designers
=== 2D Artists ===
The game artwork is developed in two complementary styles: traditional pixel art and digital painting. Please take a look at the following pages to get an idea of our artistic influences and style, and to learn more about being an artist on our project.
http://www.allacrost.org/wiki/index.php/New_Artists
http://www.allacrost.org/wiki/index.php/Artwork_Style
Website
http://www.allacrost.org
How to Join
Please see the following page on our wiki:
http://www.allacrost.org/wiki/index.php/New_Contributors
The best way to contact the team with a question or request is through our forum at http://www.allacrost.org/forum
You can also try joining our IRC channel at #allacrost at irc.freenode.net to see if anyone is around to speak to you.
And of course you can either reply to this thread with your questions, or send me a private message here if you would like to ask something privately.
Screenshots and Artwork
You can find all of our screenshots at http://www.allacrost.org/multimedia/screenshots . Unfortunately these are all old and the current state of the game has a slightly improved appearance. Here are some selections:
(The game is developed in English, but includes internationalization support so it can run in other languages).
Hi. I make RPGs, but not with RPGmaker
Hi everyone. I'm a software engineer and I develop open source software in my spare time. My main project throughout the years has been Hero of Allacrost, a project that I founded and started completely from scratch in 2004. I've worked on it off and on throughout the years and we've made several small demo releases (which you can find on our website).
I've never used nor had much interest in RPGMaker (although I do think it is an awesome product). So what brings me here? I decided to join for three reasons. First, I hope to learn from other experienced RPG creators here about certain areas of game design, such as making nice maps. Second, I'm hoping that by participating in discussions here, my own project will gain some exposure to a new audience. And finally, I'm seeking others who are interested in contributing to our project as game designers, artists, or to fill other roles. So while I can't really contribute to any RPGMaker discussions, I hope that I'll be welcome in discussions on general design topics. Thanks!
Oh, I suppose that I should probably leave some eye candy about my project as well. :)
A lot of samples of our artwork
http://www.allacrost.org/wiki/index.php/Artwork_Style
Some screenshots. These are unfortunately all two years old or more. The game looks slightly better than the most recent screens convey.
http://www.allacrost.org/multimedia/screenshots
Earlier this week I made a video showing the game in it's current state, along with audio commentary about what we're working on and where the design is heading.
I've never used nor had much interest in RPGMaker (although I do think it is an awesome product). So what brings me here? I decided to join for three reasons. First, I hope to learn from other experienced RPG creators here about certain areas of game design, such as making nice maps. Second, I'm hoping that by participating in discussions here, my own project will gain some exposure to a new audience. And finally, I'm seeking others who are interested in contributing to our project as game designers, artists, or to fill other roles. So while I can't really contribute to any RPGMaker discussions, I hope that I'll be welcome in discussions on general design topics. Thanks!
Oh, I suppose that I should probably leave some eye candy about my project as well. :)
A lot of samples of our artwork
http://www.allacrost.org/wiki/index.php/Artwork_Style
Some screenshots. These are unfortunately all two years old or more. The game looks slightly better than the most recent screens convey.
http://www.allacrost.org/multimedia/screenshots
Earlier this week I made a video showing the game in it's current state, along with audio commentary about what we're working on and where the design is heading.
Pages:
1
Games - Tester
Games - Other
Statuses
Posts
