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
Post History
Chat
New to RMN?
Full Store List
RMN Music Pack (free)
HERO OF ALLACROST - PIXEL ARTIST NEEDED FOR A HIGH-QUALITY TITLE
Posts
Pages:
1
Roots
14
Roots
View playlists
CloseAbout 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!
Ummm... I've seen this project here a couple times already and I must ask a couple' questions's been bothering me for a while now:
1.) Why are you making a JRPG?
2.) Why are you going 2D SNES with such a humunguous tile size and screen resolution?
3.) What makes you believe this is a "High-Quality title"?
1.) Why are you making a JRPG?
2.) Why are you going 2D SNES with such a humunguous tile size and screen resolution?
3.) What makes you believe this is a "High-Quality title"?
Roots
14
Thanks for asking those questions.
1) I've always been a fan of JRPGs. Chrono Trigger and FFVI are my two favorite games and when I first played them as a child, they had a great influence on me. One of my goals was to create my own game someday, and this project just sort of happened a few years ago when I was bored one summer.
2) Honestly, I don't have a good answer for this one. When we started out this project, our team was very inexperienced and ignorant about many things. We debated different tile sizes and screen resolutions and ultimately settled on these dimensions. The screenshots I posted in the top post are not the resolution you would see in the game. Those were made that large because they are from the map editor, where I was trying to capture as much of the map as possible to illustrate the map design. Our native resolution is 1024x768, although the game can be run in other resolutions. We wanted to keep our requirements modest because a game like this shouldn't require modern hardware to run well.
Here's an older screenshot that is running in 1024x768 so you can get a better idea of what an in-game screen actually looks like. We render all the artwork at a 4x zoom, so each 32x32 tile becomes 64x64 pixels on the screen.
Here's an even older screenshot at the same 1024x768 resolution. In this version we didn't do the 4x zoom, so you can see a wider area. We decided to not use this perspective because the characters felt too small and distant, and you could see too great of a distance in dungeons.
3) When I used high-quality in the title, I was referring specifically to the artwork. I feel that we have pretty high quality visuals. As for the rest of the game, it still needs work to do to make it as high quality as the rest. I wasn't completely happy with our last demo release and I felt the map design, battle system, and balancing weren't very good. But we learned some good lessons from our design and I have high hopes that our next release will be something much better.
1) I've always been a fan of JRPGs. Chrono Trigger and FFVI are my two favorite games and when I first played them as a child, they had a great influence on me. One of my goals was to create my own game someday, and this project just sort of happened a few years ago when I was bored one summer.
2) Honestly, I don't have a good answer for this one. When we started out this project, our team was very inexperienced and ignorant about many things. We debated different tile sizes and screen resolutions and ultimately settled on these dimensions. The screenshots I posted in the top post are not the resolution you would see in the game. Those were made that large because they are from the map editor, where I was trying to capture as much of the map as possible to illustrate the map design. Our native resolution is 1024x768, although the game can be run in other resolutions. We wanted to keep our requirements modest because a game like this shouldn't require modern hardware to run well.
Here's an older screenshot that is running in 1024x768 so you can get a better idea of what an in-game screen actually looks like. We render all the artwork at a 4x zoom, so each 32x32 tile becomes 64x64 pixels on the screen.
Here's an even older screenshot at the same 1024x768 resolution. In this version we didn't do the 4x zoom, so you can see a wider area. We decided to not use this perspective because the characters felt too small and distant, and you could see too great of a distance in dungeons.
3) When I used high-quality in the title, I was referring specifically to the artwork. I feel that we have pretty high quality visuals. As for the rest of the game, it still needs work to do to make it as high quality as the rest. I wasn't completely happy with our last demo release and I felt the map design, battle system, and balancing weren't very good. But we learned some good lessons from our design and I have high hopes that our next release will be something much better.
It'll be interesting to see how you guys do your battle system as I'm doing something similar, inspired by the battle system in Vagrant Story but in a turn-based environment.
Hmmm... I see. Ok, just a few things to keep in mind then.
If you're scaling your graphics, you might as well consider your resolution effectively that.
If you're scaling from 32x32 to 64x64, it means you're scaling it 2x and not 4x.
starting from that, 512 x 384 sounds kind of an awkward resolution to make your game in. Perhaps 640 x 416, or something more standard like that would be better!
I don't know how're you coding your engine, but instead of scaling the graphics, wouldn't it be wise to make the game actually low res? I don't know if it can conflict with graphics cards, but you can use a post effect zoomer or something like that!
If you're displaying less tiles per screen (and I'm glad you will, the bottom screen looks like a bad browser game JUUUUST because of the way you scaled and mapped things) then I suggest making your maps smaller and busier!
Back on the ancient times of RPG Maker, we had something called the "3-tile rule". while not something that should be actually heralded as the great first law of mapping, it's quite interesting to use when your problem is bland, uninteresting and needlessly big maps. Try simply to shrink them as much as possible, and avoid having more than 3 tiles comprised of the same tile. (break them up with patches of grass, walls, pots, whatever you want.)
It may be hard in the beginning but you'll get a feel for it. Also we have plenty of mapping tutorials that may help you. Your tiles are amazing, but the mapping itself feels really, really griddy and overly big. Also, the lack of elevation and variation on ground tiles is very, very obvious.
I have to say I wouldn't make a standard JRPG with tiles this big 32x32 tiles are standard RMVXA fare but you're using them much differently and they're much more detailed) because it's inneficient. Pixel art is a medium that grows more and more inneficient the higher resolution you go. And I can see a lot of disparity between asset artstyles thanks to that. It's hard to keep consistent with this level of detail -- and it's hard to animate characters beautifully like that too. But then again, you seem to already have a lot of work in, so keep up with it. Uhmm... It wasn't the wisest decision, though!
As for gameplay mechanics, yours evidently need work. That's something that's pretty hard to "fix", but don't simply brainlessly imitate big name RPGs. That's a sure way to go to the lavey hell of failure. If anything, read a lot of our Game Design discussions here, and try to think of fun mechanics and types of players. Who do you want to engage with your gameplay?
That's it. What I see in this game is a beautiful mess of by people with a lot of talent but that lack synergy or focus. Then again, I only know your project superficially from a few gameplay videos and threads, but these are my points. I'll be happy to see it evolving, and please don't take that personally! ^-^'
If you're scaling your graphics, you might as well consider your resolution effectively that.
If you're scaling from 32x32 to 64x64, it means you're scaling it 2x and not 4x.
starting from that, 512 x 384 sounds kind of an awkward resolution to make your game in. Perhaps 640 x 416, or something more standard like that would be better!
I don't know how're you coding your engine, but instead of scaling the graphics, wouldn't it be wise to make the game actually low res? I don't know if it can conflict with graphics cards, but you can use a post effect zoomer or something like that!
If you're displaying less tiles per screen (and I'm glad you will, the bottom screen looks like a bad browser game JUUUUST because of the way you scaled and mapped things) then I suggest making your maps smaller and busier!
Back on the ancient times of RPG Maker, we had something called the "3-tile rule". while not something that should be actually heralded as the great first law of mapping, it's quite interesting to use when your problem is bland, uninteresting and needlessly big maps. Try simply to shrink them as much as possible, and avoid having more than 3 tiles comprised of the same tile. (break them up with patches of grass, walls, pots, whatever you want.)
It may be hard in the beginning but you'll get a feel for it. Also we have plenty of mapping tutorials that may help you. Your tiles are amazing, but the mapping itself feels really, really griddy and overly big. Also, the lack of elevation and variation on ground tiles is very, very obvious.
I have to say I wouldn't make a standard JRPG with tiles this big 32x32 tiles are standard RMVXA fare but you're using them much differently and they're much more detailed) because it's inneficient. Pixel art is a medium that grows more and more inneficient the higher resolution you go. And I can see a lot of disparity between asset artstyles thanks to that. It's hard to keep consistent with this level of detail -- and it's hard to animate characters beautifully like that too. But then again, you seem to already have a lot of work in, so keep up with it. Uhmm... It wasn't the wisest decision, though!
As for gameplay mechanics, yours evidently need work. That's something that's pretty hard to "fix", but don't simply brainlessly imitate big name RPGs. That's a sure way to go to the lavey hell of failure. If anything, read a lot of our Game Design discussions here, and try to think of fun mechanics and types of players. Who do you want to engage with your gameplay?
That's it. What I see in this game is a beautiful mess of by people with a lot of talent but that lack synergy or focus. Then again, I only know your project superficially from a few gameplay videos and threads, but these are my points. I'll be happy to see it evolving, and please don't take that personally! ^-^'
Roots
14
author=Trihan
It'll be interesting to see how you guys do your battle system as I'm doing something similar, inspired by the battle system in Vagrant Story but in a turn-based environment.
I expect our battle system is going to be continually evolving for a while. While our ideas sound reasonable in theory, implementing them has been more challenging than we thought. Not the technical details, but the design aspect of making everything we have planned work together well. I'm not reluctant in the least bit to completely throw out a major feature in the future if we find it isn't working out like we had hoped. Do you have a gameplay video of your battle system? I'd be interested to see what you've done.
RE: Seraph
Thanks for all the feedback and suggestions. No worries. I don't take anything personally and want to hear people's honest thoughts and opinions more than anything.
- On scaling
True, we could just render the graphics in their native size and reduce the screen resolution. Hadn't thought about that to be honest. We want to allow the user to run the game in both windows and fullscreen modes though, and a small window (say 640x480) is really tiny on a large monitor that has a 1920x1080 resolution. So we'd want to upscale the graphics there anyway to have a reasonable sized window. Maybe we'll change things in the future, but for now things are working fine and we're focusing our efforts on more immediate issues.
- On map design
The 3-tile rule sounds like an interesting rule of thumb. One of the challenges particular to our maps stems from the fact that we have to have large structures, because there is no separate map for the inside of a home, castle, etc. It's difficult to explain how this work, but just believe me when I say if we have a 3x3 tile house, the interior is going to be 3x3 tiles as well (which is not sufficiently large for a home). We didn't realize our game would have this problem until we created our first maps. I'll take a look at the tutorials on the site though (I mistakenly presumed they were RPG-maker specific).
Thanks again for your comments.
Corfaisus
"It's frustrating because - as much as Corf is otherwise an irredeemable person - his 2k/3 mapping is on point." ~ psy_wombats
7874
I'm guessing all the screenshots are using placeholder rips? Because I'm quite sure I've seen these graphics before. Also, I'm assuming since this is a free game that you're looking for a free artist?
Roots
14
Most of our artwork (around 75-80%) is original. Yes, we do use other assets, mostly from OpenGameArt.org and other free open source game projects. All of them are used with permission and are credited appropriately.
And yes, we are looking for an unpaid artist as stated at the bottom of my original post.
And yes, we are looking for an unpaid artist as stated at the bottom of my original post.
I don't have a gameplay video available yet, Roots; the current iteration of the ABBS (Anatomy-Based Battle System, as I've coined it) in VX Ace is in early stages. I've just finished the code for creating highlightable parts of enemies for targeting, which basically involves declaring all of the points in the polygon that makes up the graphic using a custom line-drawing method.
Edit: I can give you a bit more background in how my system is going to work, though.
Essentially it's similar to what you've stated: enemies of different types will have various limbs you can target independently in battle to varying effect.
For example, a humanoid enemy would have a head, a torso, two arms and two legs. Each part will be tied to a logical stat: head to intellect, arms to attack power and legs to agility. Each part also has its own independent HP value, but damaging a part will still reduce the enemy's overall HP as well. "Killing" a part will render the enemy unable to perform a particular action associated with it. In the humanoid example, killing the arms will mean it can't attack, killing the legs will mean it can't run from battle, killing the head will mean it can't cast spells or use particularly concentration-intensive battle abilities. As a part loses HP, the effectiveness of the associated stat decreases as well. Damaging the arms means its physical damage will be less.
The torso basically takes the place of the standard jRPG targetable enemy and will have 100% of the enemy's overall HP (where other parts will likely possess less overall). So you could finish a battle relatively quickly by just focusing everything on the torso and destroying it, but it pays to focus on areas where the enemy is strong in order to make it manageable.
Different types of enemy will obviously have different combinations of targetable parts. A slime is essentially just a one-piece unit and won't have any particular parts to target (which also means you can't weaken them in the conventional way) whereas something like a spider has eight targetable legs (and therefore will have high agility and take longer to cripple).
That's the nutshell of it. I'm still ironing out specific details while I work on implementation.
Edit: I can give you a bit more background in how my system is going to work, though.
Essentially it's similar to what you've stated: enemies of different types will have various limbs you can target independently in battle to varying effect.
For example, a humanoid enemy would have a head, a torso, two arms and two legs. Each part will be tied to a logical stat: head to intellect, arms to attack power and legs to agility. Each part also has its own independent HP value, but damaging a part will still reduce the enemy's overall HP as well. "Killing" a part will render the enemy unable to perform a particular action associated with it. In the humanoid example, killing the arms will mean it can't attack, killing the legs will mean it can't run from battle, killing the head will mean it can't cast spells or use particularly concentration-intensive battle abilities. As a part loses HP, the effectiveness of the associated stat decreases as well. Damaging the arms means its physical damage will be less.
The torso basically takes the place of the standard jRPG targetable enemy and will have 100% of the enemy's overall HP (where other parts will likely possess less overall). So you could finish a battle relatively quickly by just focusing everything on the torso and destroying it, but it pays to focus on areas where the enemy is strong in order to make it manageable.
Different types of enemy will obviously have different combinations of targetable parts. A slime is essentially just a one-piece unit and won't have any particular parts to target (which also means you can't weaken them in the conventional way) whereas something like a spider has eight targetable legs (and therefore will have high agility and take longer to cripple).
That's the nutshell of it. I'm still ironing out specific details while I work on implementation.
Roots
14
Yeah, our ideas are very similar. I think you took your design one step further though. I like that you can "kill" a body part and disable an enemy's attacks, etc. In our design, each part has modifiers to defense, magic defense, and evasion from the base stats of the character or enemy, as well as different elemental resistances and weaknesses and the ability to inflict status effects by targeting them (ie, hit the legs for a chance to reduce their agility).
I really like the name ABBS too. We called our design MAPS, standing for multiple attack point system. I really don't like that name though (even though I came up with it), because the phrase "attack point" sounds like some sort of accumulator value like hit points, when it means something entirely different.
You're also doing something much fancier than us for the UI portion of the part. Where you do your fancy polygon highlighting deal, we simply select an x,y point on the enemy sprite and draw the target reticule there with the name of the selected point in the menu (ie: Spider - Legs). Ours is much simpler to implement, but your concept is a really nice touch.
An issue for both of us is that balancing the game well becomes more difficult with this type of system. You don't want to make exploiting weaknesses cause the game to be too easy, or make them not worth the time and effort it takes to discover and target them.
I really like the name ABBS too. We called our design MAPS, standing for multiple attack point system. I really don't like that name though (even though I came up with it), because the phrase "attack point" sounds like some sort of accumulator value like hit points, when it means something entirely different.
You're also doing something much fancier than us for the UI portion of the part. Where you do your fancy polygon highlighting deal, we simply select an x,y point on the enemy sprite and draw the target reticule there with the name of the selected point in the menu (ie: Spider - Legs). Ours is much simpler to implement, but your concept is a really nice touch.
An issue for both of us is that balancing the game well becomes more difficult with this type of system. You don't want to make exploiting weaknesses cause the game to be too easy, or make them not worth the time and effort it takes to discover and target them.
That's mainly why I decided to have attacking any part contribute to killing the overall enemy, so that you can choose to exploit weaknesses and still be making progress. My goal is to balance it such that battles are challenging enough to feel like you're accomplishing something, but still take roughly as long for a normal battle as they would in any other RPG. The thing I'm looking forward to most is designing boss battles, as there's a lot you can do with a system like this.
Roots
14
Yeah, I forgot to point out that dealing damage to a part in our title also deals damage to the enemy as a whole, same as in your game. It has to, since we don't have individual HP counters for parts like in your design.
Here's a question for you: does every skill/ability target a single part of an enemy? Or do some allow you to target the enemy "as a whole"? And what about abilities that target multiple enemies? How do you handle that?
We have three types of skills (all of our attacks, magic, etc. we call skills). Those that target a specific point, those that target a single enemy (or ally) and those that target multiple enemies (or allies). I can't recall at the moment how the latter two work, but I know it's one of two things. Either they just target an enemy's base stats and completely ignore the parts on their body, or they attack each part, and we divide the damage dealt by the number of parts and sum up the totals. So for example, say we cast a fire spell on an enemy with 4 parts, and 1 of those parts is weak to fire while 2 more are resistant to it. We'd deal the damage to each part and divide that number by four, then we add up the damage dealt to each part and report that as the total damage. This way we can still factor in the weaknesses and strengths of each part in the total calculation.
Do you do something similar to that? I'm curious how that works in your design.
Here's a question for you: does every skill/ability target a single part of an enemy? Or do some allow you to target the enemy "as a whole"? And what about abilities that target multiple enemies? How do you handle that?
We have three types of skills (all of our attacks, magic, etc. we call skills). Those that target a specific point, those that target a single enemy (or ally) and those that target multiple enemies (or allies). I can't recall at the moment how the latter two work, but I know it's one of two things. Either they just target an enemy's base stats and completely ignore the parts on their body, or they attack each part, and we divide the damage dealt by the number of parts and sum up the totals. So for example, say we cast a fire spell on an enemy with 4 parts, and 1 of those parts is weak to fire while 2 more are resistant to it. We'd deal the damage to each part and divide that number by four, then we add up the damage dealt to each part and report that as the total damage. This way we can still factor in the weaknesses and strengths of each part in the total calculation.
Do you do something similar to that? I'm curious how that works in your design.
The idea at the moment is to have skills that target individual parts or groups of parts, ones that do direct damage which will damage all parts of the enemy, and AoE which will damage all parts of all enemies they hit.
This is a tricky one as I've been playing with the idea of having positioning in battle as well, which would mean choosing targets for AoE more carefully, but I'm not sure whether that'll make things too complex.
This is a tricky one as I've been playing with the idea of having positioning in battle as well, which would mean choosing targets for AoE more carefully, but I'm not sure whether that'll make things too complex.
Pages:
1
