Wow! Surt is full black background the only color change you made? Because that really hits it! My comment was going to be that the palette seemed a little washed out and maybe a bit pastely for NES, but dang that one change really cleared it all up, it looks perfectly NESy now!
Also great idea to remove highlights from background tiles. Another one I'd never have thought of but makes a huge difference! I'd say you are the master but we all know that already!
Tuesday, August 30, 2016 - 10:37
Welcome MadByte!
Very glad to have you join the OGA community! We do try to make it a nice place.
As MedicineStorm says, feel free to ask if you've any questions! Although judging by that first submission, there's not much left for us to teach you! ;)
Looks good! My only comment would be that there is an inconsistency between the head and arms which use kind of a heavy 4-5 shade gradient, and the chest which uses a much simpler 2 shade gradient.
@p0ss: I think a message like that is a great low-key way to encourage folks to upload source files. And I think you put it in a very good place.
Only concern would be that it might be confusing for new users, ie. 'What is a source file?', 'Do they mean source code for my game?', 'Should I post just the source files or do they want the wav/png/whatever too?'
So... How to clarify the basic idea without getting too verbose?
Maybe:
Editable source files (layered psd/xcf, MIDI or composer software formats, etc) are welcome and will make your work useful in more projects. Just be sure to include the work in a game ready format (png, jpg, wav, ogg, etc) as well.
I see what you mean with the vanishing point, I guess that explains the size difference.
But the y offset is not because of the vanishing point, it's to match the curve of his head. The two shouldn't be aligned perfectly horizontal in the image for because his head is curved, so just like his mouth and his chin, the eyes should align along a curve. Does that make any sense?
new mouth looks great! that bit of extra 'lip' really sells it!
Thursday, July 28, 2016 - 06:14
Some more thoughts:
His eyes are actually ok to be the same size, but they should be offset in y slightly, to account for the now isometric type angle.
The angled mouth is definitely an improvement on the stratight horizontal one, but it should have more of a curve to it, to match the curvature of his head.
I think I know what you are saying about the face being a single plane cut into the cylinder. But the cylinder still has a curve to it, so the mouth hole and eyes need to reflect that.
There's still something off between Clint's stellar shading on his body and what we've come up with for his head. The body highlights just have a more natural, organic look to them. They are a bit random, notice taht not all the bands are straight lines. The head by contrast is a bit mathematical still. It's just a really clean gradient.
Did a quick and dirty mock of offsetting the eyes and curving the mouth.
I also had a go at reducing the gradient a bit to illustrate my point about it drawing attention away from his face. I just used the fill tool to to this so it's pretty rough, but I think it shows what I was talking about. Notice how w/ fewer highlights, and especially none running through his face, it puts the emphasis back on his facial features?
Again, it's pretty rought, also I thought it still needed some highlight, so I tried roughing one in just on the top of his head, but I think that pushed him back to being a bit plasticy.
Monday, July 25, 2016 - 11:38
> The vast majority of assets available here are "sourceless"
And just to clarify, 'vast majority' here means 99.999% or thereabouts.
I think time has proven OGA's flexible approach to defining 'source' and 'open' to be for the best. The site is very active, has a pretty dedicated and engaged user base, and most importantly has amassed a collection of over 14,000 artworks, all of which can be used in open source projects. Maybe it's not perfect, but it's far from useless.
I think that the site as currently consituted has also proven to be a very valuable resource both for artists looking for works to learn from or build upon and for developers looking for useful premade assets. So I don't think those two goals are necessarily mutually exclusive.
@caeles: I think you've made an excellent case for how more detailed 'source' files can be useful, but not a case for why less detailed source files are useless. As discussed above, there alot of trade offs involved in destributing artworks in the exact form an artist used to create them, and indeed this is not always the preferred format for those looking to make changes. So it's not always clear cut what format would be most useful for others, and, again as evidenced by this entire site, it's certainly not clear that 'sourceless' works are utlimately useless. And to the point about 'sourceless' works becoming obsolete, I've been listening to the same recording of Zeppelin IV for twenty years now and it hasn't proven obsolete yet, even if I would love to fix Robert Plant's chipmunky vocals on Four Sticks. :)
Monday, July 25, 2016 - 10:48
> 2. Is it better to remake games that have simple mechanics (like Asteroids) for learning purposes
> or should I just follow an idea I have and try to learn as I go?
I would absolutely recommend starting with a simple re-make or two. Pong is the classic 'first' game to code, as it's extrmely simply and it's the one that started it all, but any simple game you chose should be fine. Just make it one you actually like to play, that always helps!
The reason for this is two fold:
1) Like so many things, it's easier to start small and then move on to bigger things later. There's a lot of basic challenges (design, controls, art, sound, feedback, UI, code structure, etc. etc.) that present themselves in even the simpliest games. And it's alot easier to master these basics with small projects first than it is to try and learn them in the middle of a larger project.
2) Everything is easier when you know where you're going. With a remake, you have a set target that you're trying to hit. Before you start you can play the original to get an idea of what pieces you'll need and how they'll fit together. And as you work, you can compare your remake to the original to easily see what you've got right and needs more love. When working on an original or larger idea, it can be much harder to know what's working and what's not.
> 1. What order should I do things in? Should I get all my art together first, then program? Or should I program everything using filler art then work on getting the final art later? Which is more time-efficient in your experience?
I always recommend starting with prototype art first, if for no other reason then it'll get you started quicker. It'll also help you define and scope what art you need before you start creating it. If you're just creating art in a vacuum with no game structure to go with it, it's extremely easy to over do it or do it wrong, creating things that you don't need or aren't in the right format. The only caveat to this approach is that, contrary to the conventional wisdom that 'gameplay is king', art is an intergrel part of any game and key to it's success. It can often be difficult to tell what's working and what's not when working strictly with prototype art. An example, consider an Asteroids clone, one key is for shooting the asteroids to feel powerful and satisfying. If all you've got is some placeholder text that says 'Bang!' for when an asteroid explodes, the game is never going to feel right. Sometimes (as in this example) it's obvious when prototype art is holding things back, but not always, and there's a real danger of getting stuck chasing phantom gameplay 'issues' when all you really need is some better art.
> 3. Do you have any tips for keeping organized and on task?
One nice part about starting small is that you can probably just get by with a simple task list, and then just keep chugging away at them and adding new tasks as they pop up. One thing not to do is get lost in trying to map out your whole project in advance. It' nice to have a general roadmap, but it's also important to be flexible and not waste too much time trying to pre-plan every little detail.
> 4. Any other general advice for a beginner?
Since you mention you are in school, I'll just add, as someone whose been in the position of hiring recent grads before, if you hope to land a gig making games professionally, I'd advise you to ABC, Always Be Coding! Work on (and finish!) as many personal projects outside of your school work as you can before you graduate. Game development takes passion and experience, if all you're only doing classroom assignments, you're not showing much passion or gaining meaningful eperience. By contrast, complete projects on your own and you'll have shown you love development enough to do it on your own without anyone telling you to, and you'll have proven you know what it takes to take a complete a game from start to finish.
Wow! Surt is full black background the only color change you made? Because that really hits it! My comment was going to be that the palette seemed a little washed out and maybe a bit pastely for NES, but dang that one change really cleared it all up, it looks perfectly NESy now!
Also great idea to remove highlights from background tiles. Another one I'd never have thought of but makes a huge difference! I'd say you are the master but we all know that already!
Welcome MadByte!
Very glad to have you join the OGA community! We do try to make it a nice place.
As MedicineStorm says, feel free to ask if you've any questions! Although judging by that first submission, there's not much left for us to teach you! ;)
Looks good! My only comment would be that there is an inconsistency between the head and arms which use kind of a heavy 4-5 shade gradient, and the chest which uses a much simpler 2 shade gradient.
Featured art feature is awesome!!
@p0ss: I think a message like that is a great low-key way to encourage folks to upload source files. And I think you put it in a very good place.
Only concern would be that it might be confusing for new users, ie. 'What is a source file?', 'Do they mean source code for my game?', 'Should I post just the source files or do they want the wav/png/whatever too?'
So... How to clarify the basic idea without getting too verbose?
Maybe:
Editable source files (layered psd/xcf, MIDI or composer software formats, etc) are welcome and will make your work useful in more projects. Just be sure to include the work in a game ready format (png, jpg, wav, ogg, etc) as well.
Now the three vents need to adjusted to match the curve a bit.
maybe pull the rightmost one down a pixel?
I see what you mean with the vanishing point, I guess that explains the size difference.
But the y offset is not because of the vanishing point, it's to match the curve of his head. The two shouldn't be aligned perfectly horizontal in the image for because his head is curved, so just like his mouth and his chin, the eyes should align along a curve. Does that make any sense?
new mouth looks great! that bit of extra 'lip' really sells it!
Some more thoughts:
His eyes are actually ok to be the same size, but they should be offset in y slightly, to account for the now isometric type angle.
The angled mouth is definitely an improvement on the stratight horizontal one, but it should have more of a curve to it, to match the curvature of his head.
I think I know what you are saying about the face being a single plane cut into the cylinder. But the cylinder still has a curve to it, so the mouth hole and eyes need to reflect that.
There's still something off between Clint's stellar shading on his body and what we've come up with for his head. The body highlights just have a more natural, organic look to them. They are a bit random, notice taht not all the bands are straight lines. The head by contrast is a bit mathematical still. It's just a really clean gradient.
Did a quick and dirty mock of offsetting the eyes and curving the mouth.
I also had a go at reducing the gradient a bit to illustrate my point about it drawing attention away from his face. I just used the fill tool to to this so it's pretty rough, but I think it shows what I was talking about. Notice how w/ fewer highlights, and especially none running through his face, it puts the emphasis back on his facial features?
Again, it's pretty rought, also I thought it still needed some highlight, so I tried roughing one in just on the top of his head, but I think that pushed him back to being a bit plasticy.
> The vast majority of assets available here are "sourceless"
And just to clarify, 'vast majority' here means 99.999% or thereabouts.
I think time has proven OGA's flexible approach to defining 'source' and 'open' to be for the best. The site is very active, has a pretty dedicated and engaged user base, and most importantly has amassed a collection of over 14,000 artworks, all of which can be used in open source projects. Maybe it's not perfect, but it's far from useless.
I think that the site as currently consituted has also proven to be a very valuable resource both for artists looking for works to learn from or build upon and for developers looking for useful premade assets. So I don't think those two goals are necessarily mutually exclusive.
@caeles: I think you've made an excellent case for how more detailed 'source' files can be useful, but not a case for why less detailed source files are useless. As discussed above, there alot of trade offs involved in destributing artworks in the exact form an artist used to create them, and indeed this is not always the preferred format for those looking to make changes. So it's not always clear cut what format would be most useful for others, and, again as evidenced by this entire site, it's certainly not clear that 'sourceless' works are utlimately useless. And to the point about 'sourceless' works becoming obsolete, I've been listening to the same recording of Zeppelin IV for twenty years now and it hasn't proven obsolete yet, even if I would love to fix Robert Plant's chipmunky vocals on Four Sticks. :)
> 2. Is it better to remake games that have simple mechanics (like Asteroids) for learning purposes
> or should I just follow an idea I have and try to learn as I go?
I would absolutely recommend starting with a simple re-make or two. Pong is the classic 'first' game to code, as it's extrmely simply and it's the one that started it all, but any simple game you chose should be fine. Just make it one you actually like to play, that always helps!
The reason for this is two fold:
1) Like so many things, it's easier to start small and then move on to bigger things later. There's a lot of basic challenges (design, controls, art, sound, feedback, UI, code structure, etc. etc.) that present themselves in even the simpliest games. And it's alot easier to master these basics with small projects first than it is to try and learn them in the middle of a larger project.
2) Everything is easier when you know where you're going. With a remake, you have a set target that you're trying to hit. Before you start you can play the original to get an idea of what pieces you'll need and how they'll fit together. And as you work, you can compare your remake to the original to easily see what you've got right and needs more love. When working on an original or larger idea, it can be much harder to know what's working and what's not.
> 1. What order should I do things in? Should I get all my art together first, then program? Or should I program everything using filler art then work on getting the final art later? Which is more time-efficient in your experience?
I always recommend starting with prototype art first, if for no other reason then it'll get you started quicker. It'll also help you define and scope what art you need before you start creating it. If you're just creating art in a vacuum with no game structure to go with it, it's extremely easy to over do it or do it wrong, creating things that you don't need or aren't in the right format. The only caveat to this approach is that, contrary to the conventional wisdom that 'gameplay is king', art is an intergrel part of any game and key to it's success. It can often be difficult to tell what's working and what's not when working strictly with prototype art. An example, consider an Asteroids clone, one key is for shooting the asteroids to feel powerful and satisfying. If all you've got is some placeholder text that says 'Bang!' for when an asteroid explodes, the game is never going to feel right. Sometimes (as in this example) it's obvious when prototype art is holding things back, but not always, and there's a real danger of getting stuck chasing phantom gameplay 'issues' when all you really need is some better art.
> 3. Do you have any tips for keeping organized and on task?
One nice part about starting small is that you can probably just get by with a simple task list, and then just keep chugging away at them and adding new tasks as they pop up. One thing not to do is get lost in trying to map out your whole project in advance. It' nice to have a general roadmap, but it's also important to be flexible and not waste too much time trying to pre-plan every little detail.
> 4. Any other general advice for a beginner?
Since you mention you are in school, I'll just add, as someone whose been in the position of hiring recent grads before, if you hope to land a gig making games professionally, I'd advise you to ABC, Always Be Coding! Work on (and finish!) as many personal projects outside of your school work as you can before you graduate. Game development takes passion and experience, if all you're only doing classroom assignments, you're not showing much passion or gaining meaningful eperience. By contrast, complete projects on your own and you'll have shown you love development enough to do it on your own without anyone telling you to, and you'll have proven you know what it takes to take a complete a game from start to finish.
Good luck!
Pages