Great work on v1.2. The whole thing looks more polished and easy to use. I could just drag and drop it into Tiled and it all worked perfectly.
Get known for making things as good as this and you will start attracting real job offers I'm sure.
I don't know when it has been updated, so I check this page regularly. Making a quick 'Updated!' post in the comments would send an email to everyone who has comment follow-up notification e-mails enabled (I think it is by default), and put you back into the active forum topics section.
I don't know if this practice is frowned upon here, but this stuff is too good not to.
Some of the new tiles have allignment issues, but nothing that can't be worked around.
The new modular objects are by far better. So useful to be able to mix and merge/overlay different object combinations. Relaly helps break up that strict 'grid' feeling that tile based games have.
I would even recommend removing the rocks in water tiles as the same effect can be achieved with the new componential rocks, and there are is more variety.
The fence sections could benefit from have the backgrounds remove too. Can't use on sand ATM.
The earlier you learn the basics of programming the better. The better I got, the more I realised I could do.
It was this strange feeling of empowerment, almost godlike, that kept me opening up my IDE and smashing away at my keyboard, knowing that in my own little virtual world, anything was possible.
The only one of those mentioned that I have used is Game Maker, but after a quick look at the basic features of each one, my opinions are as follows:
RPGToolKit: Looks a bit meh. The crappy looking graphics on a lot of the games will just be down to whoever has created them. The renderer shouldn't care what colour pixels are used on each image.
Big downside is it only works (officially) on Windows PCs. It wouldn't be worth trying to 'port' it to other platforms.
Game Maker: We have this at college, and I don't like it. I guess that is just me being used to doing everything myself and not having stuff hidden from me behind a GUI. Some people have made some cool stuff with it, and the GML language that it comes with is easy enough to use. Might end up being your best bet for now.
Engine001: Never heard of this one before. Looks OK, I guess. The scripting system works similar to Kismet used in UDK, intuitive and easy to use. Though your game will probably feel quite similar to most of the other games made with it.
If you do decide to concede to the inevitable, then JavaScript is what I recommend you learn. Most of what you learn from it can be transferred over to some other language very easily once you understand the core concepts.
"We have a completely original game idea, now we just need people to make it for us."
The programmers are going to be by far the hardest for you to get hold of. There is a shortage of engineering-minded people in the mainstream games industry ATM, which means that established companies are paying good money to get their hands on them.
A full GDD is a must for me before I think about joining any project.
You will need to learn some programming if you want to make anything, even if using an engine.
It's just an unavoidable truth I'm affraid.
No game 'engine' will have all of the features that you will require for your specific game. No game engine is going to make the game for you.
An engine is just meant to do the 'heavy lifting' stuff (rendering, collision detection, device recognition, posibly networking). You will need to create the actual gameplay logic yourself.
I was going to recommend trying to find the source code for an older game that already has the features that you want and change it to taste, but even that will require programming knowledge.
I've been doing programming for a little while, I come from C++, working with SFML, but am now doing JavaScript with Phaser for web based games.
I was hesitant at first to learn how to program. This was the sentiment I had at the time:
"It looks too complicated!" "It will take years to learn!" "What if I am no good at it? Q_Q"
But I just sat my ass down and trudged through it. There were bits I hated, times where I thought I should just give up, that the end goal of making my super awesome game was just too unrealistic.
It all depends on how much you really want to make whatever game I guess.
If you are just getting started with the idea of making a game, then be warned, you have a mountain to climb.
Also, the 'quality' of the graphics as I think you mean it doesn't really make a difference speed-wise. You are still going to be drawing the same amount of pixels onto the screen, regardless of whether your assets look 8-bit or photorealistic. Unless you actually intend on making the display area of the game smaller...
The tall grass would make sense as a tile, but the boulder should be independant, like the tree.
I think some of the other things should be separated into their own objects too, like the small rocks in the ground, tree stump, flowers, etc. ATM they are a part of the 'center' grass tile, and look odd if used on a border. See attached image.
Being able to mix and match different objects with different background tiles makes each one a lot more versatile.
Modularity = Reusability.
Ideally the tree should also be broken up into separate tiles with 1px spacing for consistency with the rest of the tileset.
Great work on v1.2. The whole thing looks more polished and easy to use. I could just drag and drop it into Tiled and it all worked perfectly.
Get known for making things as good as this and you will start attracting real job offers I'm sure.
I don't know when it has been updated, so I check this page regularly. Making a quick 'Updated!' post in the comments would send an email to everyone who has comment follow-up notification e-mails enabled (I think it is by default), and put you back into the active forum topics section.
I don't know if this practice is frowned upon here, but this stuff is too good not to.
Some of the new tiles have allignment issues, but nothing that can't be worked around.
The new modular objects are by far better. So useful to be able to mix and merge/overlay different object combinations. Relaly helps break up that strict 'grid' feeling that tile based games have.
I would even recommend removing the rocks in water tiles as the same effect can be achieved with the new componential rocks, and there are is more variety.
The fence sections could benefit from have the backgrounds remove too. Can't use on sand ATM.
The earlier you learn the basics of programming the better. The better I got, the more I realised I could do.
It was this strange feeling of empowerment, almost godlike, that kept me opening up my IDE and smashing away at my keyboard, knowing that in my own little virtual world, anything was possible.
The only one of those mentioned that I have used is Game Maker, but after a quick look at the basic features of each one, my opinions are as follows:
RPGToolKit: Looks a bit meh. The crappy looking graphics on a lot of the games will just be down to whoever has created them. The renderer shouldn't care what colour pixels are used on each image.
Big downside is it only works (officially) on Windows PCs. It wouldn't be worth trying to 'port' it to other platforms.
Game Maker: We have this at college, and I don't like it. I guess that is just me being used to doing everything myself and not having stuff hidden from me behind a GUI. Some people have made some cool stuff with it, and the GML language that it comes with is easy enough to use. Might end up being your best bet for now.
Engine001: Never heard of this one before. Looks OK, I guess. The scripting system works similar to Kismet used in UDK, intuitive and easy to use. Though your game will probably feel quite similar to most of the other games made with it.
If you do decide to concede to the inevitable, then JavaScript is what I recommend you learn. Most of what you learn from it can be transferred over to some other language very easily once you understand the core concepts.
Basically what I read here was:
"We have a completely original game idea, now we just need people to make it for us."
The programmers are going to be by far the hardest for you to get hold of. There is a shortage of engineering-minded people in the mainstream games industry ATM, which means that established companies are paying good money to get their hands on them.
A full GDD is a must for me before I think about joining any project.
You will need to learn some programming if you want to make anything, even if using an engine.
It's just an unavoidable truth I'm affraid.
No game 'engine' will have all of the features that you will require for your specific game. No game engine is going to make the game for you.
An engine is just meant to do the 'heavy lifting' stuff (rendering, collision detection, device recognition, posibly networking). You will need to create the actual gameplay logic yourself.
I was going to recommend trying to find the source code for an older game that already has the features that you want and change it to taste, but even that will require programming knowledge.
I've been doing programming for a little while, I come from C++, working with SFML, but am now doing JavaScript with Phaser for web based games.
I was hesitant at first to learn how to program. This was the sentiment I had at the time:
"It looks too complicated!" "It will take years to learn!" "What if I am no good at it? Q_Q"
But I just sat my ass down and trudged through it. There were bits I hated, times where I thought I should just give up, that the end goal of making my super awesome game was just too unrealistic.
It all depends on how much you really want to make whatever game I guess.
If you are just getting started with the idea of making a game, then be warned, you have a mountain to climb.
Also, the 'quality' of the graphics as I think you mean it doesn't really make a difference speed-wise. You are still going to be drawing the same amount of pixels onto the screen, regardless of whether your assets look 8-bit or photorealistic. Unless you actually intend on making the display area of the game smaller...
The tall grass would make sense as a tile, but the boulder should be independant, like the tree.
I think some of the other things should be separated into their own objects too, like the small rocks in the ground, tree stump, flowers, etc. ATM they are a part of the 'center' grass tile, and look odd if used on a border. See attached image.
Being able to mix and match different objects with different background tiles makes each one a lot more versatile.
Modularity = Reusability.
Ideally the tree should also be broken up into separate tiles with 1px spacing for consistency with the rest of the tileset.
EDIT: NVM I didn't realise it has been updated.
Awesome stuff. Good tones for the colours used. Animated environments are hard to come by.
I hope you keep making stuff like this. If you are going to be adding more stuff to this, some must haves IMO are:
It's too detailed for use in what I'm working on ATM, but someone will find a use for quality stuff like this.
Good stuff. This is very much the kind of style I was looking for for my game.
The grass and dirt looks a bit too bright for the building IMO. What are the grey tiles for?
Would be cool if there was some transition tiles for use with your other RPG tilesets.
Pages