Tap seems to be following the "full immersion" school of thought, which realistically will teach you to program faster if you have the patience to tackle the big learning curve. However, I'm going to play devil's advocate for a moment and say that an engine that does a lot for you might be the absolute best way to start out.
This is because with an engine like that, you can get right into making games. Since it already does a lot for you, most of the common functions will be taken care of, and you can produce a working game possibly without writing a single line of code.
You won't be totally satisfied with a game produced this way, though, because you'll invariably run into the limitations of what the canned functionality can do for you. The way around this is to dip your toes into scripting (which is the opposite approach from what Tap was talking about) and write a few lines of code here and there to start out with. Most likely, other people will have run into the same limitations that you have, so there will probably be web tutorials around that can give you some pointers on what to do.
I'm honestly not sure which of these approaches is the better one. I'm 35, so when I first started to try to make games as a kid back in the 1980s, there just weren't any game creation kits around, so I pretty much had to try and write them myself. I was never able to write anything more complicated than a simple text adventure until the early 90s.
I'm a reasonably good programmer now, and I learned how to do it the way Tap is talking about -- by jumping right in and doing it the old-fashioned way. But doing it that way will involve a lot of false starts, and you need to be prepared for the fact that it'll take you quite a while to make anything more than the most basic stuff.
My proposal is a top-down 2d racing game with procedurally generated tracks.
The object would be to either win the race or destroy all of the other cars on the track, and then use experience points to purchase upgrades (top speed, acceleration, traction, armor, shields, weapon types, etc).
From the art side, the track itself would be done with vectors, so it wouldn't require special pixel art for each possible corner, etc, although we'd need details like trees, obstacles, etc. There would be multiple cars, but they would only require one single frame apiece and just be rotated. All told, I don't think it would require all that much in the way of pixel art.
I'd be willing, but I can't enter the contest officially (conflict of interest and all), so my entry will be unofficial. In the unlikely event that you don't get any other offers and you don't mind not being eligible to win, I'd be up for teaming up. :)
There's no harm in it, but the point he's making is that if you release something under CC0, it's automatically usable under all the other licenses, since CC0 is essentially public domain. Usually we bring this up just to make sure that people understand the implications of CC0. It sounds like you're alreay clear about that stuff, though, so we're all good.
Tap seems to be following the "full immersion" school of thought, which realistically will teach you to program faster if you have the patience to tackle the big learning curve. However, I'm going to play devil's advocate for a moment and say that an engine that does a lot for you might be the absolute best way to start out.
This is because with an engine like that, you can get right into making games. Since it already does a lot for you, most of the common functions will be taken care of, and you can produce a working game possibly without writing a single line of code.
You won't be totally satisfied with a game produced this way, though, because you'll invariably run into the limitations of what the canned functionality can do for you. The way around this is to dip your toes into scripting (which is the opposite approach from what Tap was talking about) and write a few lines of code here and there to start out with. Most likely, other people will have run into the same limitations that you have, so there will probably be web tutorials around that can give you some pointers on what to do.
I'm honestly not sure which of these approaches is the better one. I'm 35, so when I first started to try to make games as a kid back in the 1980s, there just weren't any game creation kits around, so I pretty much had to try and write them myself. I was never able to write anything more complicated than a simple text adventure until the early 90s.
I'm a reasonably good programmer now, and I learned how to do it the way Tap is talking about -- by jumping right in and doing it the old-fashioned way. But doing it that way will involve a lot of false starts, and you need to be prepared for the fact that it'll take you quite a while to make anything more than the most basic stuff.
Very colorful and epic. Nice work. :)
Not to worried ally accurate physics, so use your judgment on the designs. Hovering is fine. I like what you've got so far. :)
Sorry for the delay. The file should be downloadable again.
Sci-fi.
My proposal is a top-down 2d racing game with procedurally generated tracks.
The object would be to either win the race or destroy all of the other cars on the track, and then use experience points to purchase upgrades (top speed, acceleration, traction, armor, shields, weapon types, etc).
From the art side, the track itself would be done with vectors, so it wouldn't require special pixel art for each possible corner, etc, although we'd need details like trees, obstacles, etc. There would be multiple cars, but they would only require one single frame apiece and just be rotated. All told, I don't think it would require all that much in the way of pixel art.
I'd be willing, but I can't enter the contest officially (conflict of interest and all), so my entry will be unofficial. In the unlikely event that you don't get any other offers and you don't mind not being eligible to win, I'd be up for teaming up. :)
There's no harm in it, but the point he's making is that if you release something under CC0, it's automatically usable under all the other licenses, since CC0 is essentially public domain. Usually we bring this up just to make sure that people understand the implications of CC0. It sounds like you're alreay clear about that stuff, though, so we're all good.
Nice sprite, btw. :)
Team entries are fine.
Programmers will probably want to check out the PCG Wiki for a wealth of info about procedural content generation:
http://pcg.wikidot.com/
Pages