The lack of strong typing is one of the reasons why Python is much easier to learn than C/C++. Also you can use strong typing in Python if you want. And then use Cython to convert said Python code to C which is then compiled to native machine code. So Python can go just as fast as C/C++ if you need it to. Usually not every part of a program needs the speed offered by native machine code so you can mix Cython with standard Python as needed to get the best of both worlds. Besides, if you aren't doing something 3D with AAA level graphics the speed of C/C++ isn't needed anyway. You don't need native machine code for a tetris or asteroids clone. Both would teach you a lot about how to make a game and are good "my first game" candidates.
When starting as a beginner you are learning two totally seperate things at the same time. How to make a game and how to program. Sticking with an easier language lets you spend more time learning how to make a game and less time learning how to program. It also makes the whole process less frustraiting which makes it more likely that you will suceed with your first simple game. Once you are past that initial hurdle you can move on to more complex games and/or more complex languages as you feel you are ready to.
Inheritance and other OOP features in Python are not much different than C++. I don't even see this as a differentiating factor. Also Python lists are ridiculously similar to C/C++ arrays on the surface. They are ordered, interable, addressed by numbered index starting at 0, can have their contents be manipulated in place, can have arbitrary elements added/removed, and can be multi dimensional. Under the hood we can get into the differences between contiguous and non contiguous memory and both have their strong points with C/C++ arrays probably winning out in most cases. But that is not something a beginner should be concerned with.
C/C++ are great for writing games. But Python is much better for a beginner as it forces you to learn proper coding habits and lets you ease into the speed and power of C when you are ready. C# is solid too and is probably a good alternative when used with Unity as Unity abstracts a lot of things that you would otherwise have to worry about with C/C++ or Python and a text based IDE.
Once you have learned one language picking up another one is very easy. So start with one that is easy to learn, Python. Then move to something else if you feel the need to. Starting with Python and going to C++ once you know how to program will be far less frustraiting than starting out with C++.
I think that this image has a pretty good summary of several popular languages.
In fact, learning C++ with Allegro should be fairly straight forward for anyone who is famaliar with Python and the Pygame library.
Well I do get a bit confused every once in a while but yes, I am most certainly human, and not a lawyer, or a spelling bee champion, or a towel, but I digress.
What's wrong with normal names? There are a ton of baby names sites on the internet with a bazillion names in them. Some (many?) of the names are even pretty funky. Many baby names sites even let you search for names by meaning or origin, which you could then tie into the game story. At the very least it should give you about a million places to start.
Who said that the main character in an RPG can't be named Alex, Stephen, Bill, Jennifer, or Sally?
I would think that if you took a CC0 public domain work and then created a derivative work based on it that you would then be able to apply whatever terms you wanted to said derivative work becase it would be yours.
Normally derivative works are still basically owned by the author of the origional work unless you can convince a judge otherwise. How easy that is varies quite a bit. Great leeyway is usually given for satire and social/political commentary but just adding an extra note to a Metallica song does not give you your own Metallica song. But in the case of CC0/public domain works there is no origional author from a legal/copyright perspective.
So I would think that any derivative work derived from a public domain work would by default fall under normal copyright unless the author of the derivative work stated otherwise. For example the story of Goldilocks and the Three Bears is clearly in the public domain yet the TV series Goldie and Bear, although derived from the origional public domain story, is clearly owned by and copyrighted by Disney.
The real questions would be what constitutes a derivative work and at what point does the author of the origional work loose control over the derivative work. This is really something that should be discussed with a lawer.
I'm not sure why people think interpreted languages like Python are slow. I suppose for AAA 3D stuff with lots of triangles and hi res textures on the screen where you need every last clock cycle from the CPU/video card then sure, C++ is where it's at. But for a simple 2D JRPG in the style of the SNES era FF games Python seems to be just fine as far as I can tell.
I've actually got something to near the tech demo stage myself in Python using pygame. (Github link if anyone is interested.) You can walk around the map, leave to the world map, go to some other area from the world map, get in random battles, talk to NPCs, make dialog choices, ect... All at 1280x720 with SNES style graphics that are better than SNES graphics due to the higer resolution.
Its not done yet, but it runs and the battle system and party screen functionality are all that's really left to impliment before I can start thinking about story and characters and stuff like that. Well, I guess there is still lots of polish and code optimization to do to, but still, it runs and gets 60 fps, even in the battle swirl. Oh and the save/load system, I still need to do that, but the pickle module looks like a ready to go boilerplate solution to that since everything is already in objects anyway.
I think the most performance intensive thing I did was make the world map a ludicrious 1024x1024 32 pixel tiles in Tiled. It took about 4 seconds for the game to load up with a map that size and even then it still ran just fine through the viewport once it loaded up. I dropped the world map to a more reasonable 128x128 tiles and the load time vanished. I imagine most zones will be about 64x64 tiles in size, but any really large area can always be broken up into multiple zones. So 256 such zones would be one silly huge world map's worth of loading time. That should be plenty of space to make a JRPG in I think.
I agree with capbros, use whatever language you like, they all seem to be fine in the modern era of multi ghz CPUs and 8+ gigs of RAM.
New to the forums here but I thought I could make an observation. All of the assets in the XP generator appear to be from the MACK generator.
The best evidence for this is that you can make exactly the same character in both: http://imgur.com/a/vSVvF
The colors seem to have been dulled down a bit and the XP generator is missing the weapon options from the MACK generator (hence the small difference in the rear view between the two sprites) but otherwise the assets appear to be identical.
So it would seem that anything made with the XP generator falls under MACK's terms. The real question in my mind is whether or not the XP generator counts as a "collection of materials" since MACK's terms prohibit distributing things made with his sprite assets in such a collection and the generator isn't really a game per say. Per Google's translation:
"However, distribution regardless of paid gratis is prohibited from distribution in the form of a collection of materials that collects materials alone. Please sell it as a game work to the last."
My guess would be that you can use sprites made in the XP generator in games but not post them on OGA. The legality of the generator itself seems a bit muddy to me though. However I am not a layer.
The lack of strong typing is one of the reasons why Python is much easier to learn than C/C++. Also you can use strong typing in Python if you want. And then use Cython to convert said Python code to C which is then compiled to native machine code. So Python can go just as fast as C/C++ if you need it to. Usually not every part of a program needs the speed offered by native machine code so you can mix Cython with standard Python as needed to get the best of both worlds. Besides, if you aren't doing something 3D with AAA level graphics the speed of C/C++ isn't needed anyway. You don't need native machine code for a tetris or asteroids clone. Both would teach you a lot about how to make a game and are good "my first game" candidates.
When starting as a beginner you are learning two totally seperate things at the same time. How to make a game and how to program. Sticking with an easier language lets you spend more time learning how to make a game and less time learning how to program. It also makes the whole process less frustraiting which makes it more likely that you will suceed with your first simple game. Once you are past that initial hurdle you can move on to more complex games and/or more complex languages as you feel you are ready to.
Inheritance and other OOP features in Python are not much different than C++. I don't even see this as a differentiating factor. Also Python lists are ridiculously similar to C/C++ arrays on the surface. They are ordered, interable, addressed by numbered index starting at 0, can have their contents be manipulated in place, can have arbitrary elements added/removed, and can be multi dimensional. Under the hood we can get into the differences between contiguous and non contiguous memory and both have their strong points with C/C++ arrays probably winning out in most cases. But that is not something a beginner should be concerned with.
C/C++ are great for writing games. But Python is much better for a beginner as it forces you to learn proper coding habits and lets you ease into the speed and power of C when you are ready. C# is solid too and is probably a good alternative when used with Unity as Unity abstracts a lot of things that you would otherwise have to worry about with C/C++ or Python and a text based IDE.
Once you have learned one language picking up another one is very easy. So start with one that is easy to learn, Python. Then move to something else if you feel the need to. Starting with Python and going to C++ once you know how to program will be far less frustraiting than starting out with C++.
I think that this image has a pretty good summary of several popular languages.
In fact, learning C++ with Allegro should be fairly straight forward for anyone who is famaliar with Python and the Pygame library.
Well I do get a bit confused every once in a while but yes, I am most certainly human, and not a lawyer, or a spelling bee champion, or a towel, but I digress.
What's wrong with normal names? There are a ton of baby names sites on the internet with a bazillion names in them. Some (many?) of the names are even pretty funky. Many baby names sites even let you search for names by meaning or origin, which you could then tie into the game story. At the very least it should give you about a million places to start.
Who said that the main character in an RPG can't be named Alex, Stephen, Bill, Jennifer, or Sally?
I would think that if you took a CC0 public domain work and then created a derivative work based on it that you would then be able to apply whatever terms you wanted to said derivative work becase it would be yours.
Normally derivative works are still basically owned by the author of the origional work unless you can convince a judge otherwise. How easy that is varies quite a bit. Great leeyway is usually given for satire and social/political commentary but just adding an extra note to a Metallica song does not give you your own Metallica song. But in the case of CC0/public domain works there is no origional author from a legal/copyright perspective.
So I would think that any derivative work derived from a public domain work would by default fall under normal copyright unless the author of the derivative work stated otherwise. For example the story of Goldilocks and the Three Bears is clearly in the public domain yet the TV series Goldie and Bear, although derived from the origional public domain story, is clearly owned by and copyrighted by Disney.
The real questions would be what constitutes a derivative work and at what point does the author of the origional work loose control over the derivative work. This is really something that should be discussed with a lawer.
I'm not sure why people think interpreted languages like Python are slow. I suppose for AAA 3D stuff with lots of triangles and hi res textures on the screen where you need every last clock cycle from the CPU/video card then sure, C++ is where it's at. But for a simple 2D JRPG in the style of the SNES era FF games Python seems to be just fine as far as I can tell.
I've actually got something to near the tech demo stage myself in Python using pygame. (Github link if anyone is interested.) You can walk around the map, leave to the world map, go to some other area from the world map, get in random battles, talk to NPCs, make dialog choices, ect... All at 1280x720 with SNES style graphics that are better than SNES graphics due to the higer resolution.
Its not done yet, but it runs and the battle system and party screen functionality are all that's really left to impliment before I can start thinking about story and characters and stuff like that. Well, I guess there is still lots of polish and code optimization to do to, but still, it runs and gets 60 fps, even in the battle swirl. Oh and the save/load system, I still need to do that, but the pickle module looks like a ready to go boilerplate solution to that since everything is already in objects anyway.
I think the most performance intensive thing I did was make the world map a ludicrious 1024x1024 32 pixel tiles in Tiled. It took about 4 seconds for the game to load up with a map that size and even then it still ran just fine through the viewport once it loaded up. I dropped the world map to a more reasonable 128x128 tiles and the load time vanished. I imagine most zones will be about 64x64 tiles in size, but any really large area can always be broken up into multiple zones. So 256 such zones would be one silly huge world map's worth of loading time. That should be plenty of space to make a JRPG in I think.
I agree with capbros, use whatever language you like, they all seem to be fine in the modern era of multi ghz CPUs and 8+ gigs of RAM.
New to the forums here but I thought I could make an observation. All of the assets in the XP generator appear to be from the MACK generator.
The best evidence for this is that you can make exactly the same character in both: http://imgur.com/a/vSVvF
The colors seem to have been dulled down a bit and the XP generator is missing the weapon options from the MACK generator (hence the small difference in the rear view between the two sprites) but otherwise the assets appear to be identical.
So it would seem that anything made with the XP generator falls under MACK's terms. The real question in my mind is whether or not the XP generator counts as a "collection of materials" since MACK's terms prohibit distributing things made with his sprite assets in such a collection and the generator isn't really a game per say. Per Google's translation:
"However, distribution regardless of paid gratis is prohibited from distribution in the form of a collection of materials that collects materials alone. Please sell it as a game work to the last."
My guess would be that you can use sprites made in the XP generator in games but not post them on OGA. The legality of the generator itself seems a bit muddy to me though. However I am not a layer.