No I don't think so. You might be able to make a wrapper somehow that you can call from c#, javascript or boo (the three supported languages) but honestly I think just rewriting the codebase is faster than doing that...
Yeah I was referring to euclidean vectors used in 3d math. If you haven't studied linear algebra yet then I recommend staying away from 3d graphics for the time being. Also, if you stick to 2D you won't need the lightmaps. I am sure unreal has a setting for not using lightmaps at all or rebuild them only when needed. But there are probably forums for those types of questions realted to unreal.
As I said earlier I am a unity guy, never worked with unreal but I am sure they have pålenty bricks for that too!
If you have specific question about how to glue two bricks together in unity I'll gladly help you but I STILL think you should just get one of all the dialog extensions for unity and start using that. Or an equivalent for unreal. Don't start with 3D just yet, get something working with one brick before you start glueing them together!
As for my earlier question,what programming languages do you know and have you studied linear algebra (ie do you know your way around vector operations, projections etc)?
All the tools you describe already exist for unity. Procedural worlds, dialogue systems etc. All of them. I work with Unity every day so I am very wella aware of this fact. UMA is awesome and I use it in my master thesis. So all of those bricks already exist. So now you need to be a "mason of code" and put all those bricks together to build a skyscraper. Problem is you need to know masonry, architecture etc etc. You seem to be a guy that has seen a bunch of bricks and thought "hmm, now that someone else made the bricks, it must be really easy to make a house, let's make a skyscraper".
What everyone here has been trting to tell you is, try to put two brick together before you build a house. Try to build a house before you make a skyscraper. Otherwise you'll just end upå with a pile of bricks.
But yes, life as a game dev is MUCH easier now that we don't have to make every single brick ourselves. Building a game though, that still requires a lot of skill. All I am saying try to make a simple game with dialogs first. Learning the whole 3D stuff before you even know programming c++ or c# will not help you.
I am not trying to be harsh, I am actually trying to help you complete a game, because it seems really cool and I want to play it! :)
What formal training or education do you have? Do you know any other programming languages than batch script? Have you studied linear algebra (3D math)? If I knew that I might be able to help you a bit on the way to finding the correct engine for you to use.
Look Tozan you're approaching this the wrong way. Start making a simpler game. Just dialog based. THEN you can add some simple movement on a map. Unless you have a team of 10 experienced coders that can work for you for a year your game will never be finished if you try to make all the stuff you're describing.
I am not saying anything about batch script... I don't know much about it. I am just talking about game dev in general.
Yes, as it stands now your text assets are hard to port. If they were in a database separated from logic it would be a lot easier to port.
If you are looking at c64-games for technical solutions then I think you are doing something wrong. If you want to develop games learn one of the following:
1. Enough programming to make your own engine
2. How to use an existing engine
That's my two cents... Checking back through this thread I can't help to suspect trolling. Someone defending the use of batch-script for game development, talking about burning out HDDs, lip-synch and using c64-tech just seems... Unlikely... If that's not the case then I'm sorry but I don't think I can help you much more anyway.
Good luck with your game, I hope you switch to some other tech than batch-script and that you actually manage to finish it.
No it does not need to be in thousands of little text files (but it could be, i really doubt that this would be a problem*) it could very well be in a database, in xml or whatever BUT NOT EMBEDDED IN CODE!! If it was and you needed to change techs from say one game engine to another then there would be tonnes of work to port it.
Well each to his own I guess, whatever works for you and actually results in a game that people play is what you should go with!
As for Unreal, I never used it, I use Unity myself but Unreal is an engine used for AAA games. I think you're safe to trust them that they don't burn through HDDs or their QA would know about it.
*) I have never heard of any best practices in game development that you need to keep everything in one file for the purpose of saving HDDs of users.
I am using these for my second project. Thanks soooo much for making them CC0, I just can't handle all that attribution stuff :P
Here's the first project that used them:
http://www.kongregate.com/games/mikhog/it-came-from-the-forest
The second is still to be anounced... :)
I'm using this as an included art asset in this:
https://www.assetstore.unity3d.com/en/#!/content/37649
Thanks for sharing CC0!
What are your skills?
No I don't think so. You might be able to make a wrapper somehow that you can call from c#, javascript or boo (the three supported languages) but honestly I think just rewriting the codebase is faster than doing that...
Yeah I was referring to euclidean vectors used in 3d math. If you haven't studied linear algebra yet then I recommend staying away from 3d graphics for the time being. Also, if you stick to 2D you won't need the lightmaps. I am sure unreal has a setting for not using lightmaps at all or rebuild them only when needed. But there are probably forums for those types of questions realted to unreal.
As I said earlier I am a unity guy, never worked with unreal but I am sure they have pålenty bricks for that too!
If you have specific question about how to glue two bricks together in unity I'll gladly help you but I STILL think you should just get one of all the dialog extensions for unity and start using that. Or an equivalent for unreal. Don't start with 3D just yet, get something working with one brick before you start glueing them together!
As for my earlier question,what programming languages do you know and have you studied linear algebra (ie do you know your way around vector operations, projections etc)?
All the tools you describe already exist for unity. Procedural worlds, dialogue systems etc. All of them. I work with Unity every day so I am very wella aware of this fact. UMA is awesome and I use it in my master thesis. So all of those bricks already exist. So now you need to be a "mason of code" and put all those bricks together to build a skyscraper. Problem is you need to know masonry, architecture etc etc. You seem to be a guy that has seen a bunch of bricks and thought "hmm, now that someone else made the bricks, it must be really easy to make a house, let's make a skyscraper".
What everyone here has been trting to tell you is, try to put two brick together before you build a house. Try to build a house before you make a skyscraper. Otherwise you'll just end upå with a pile of bricks.
But yes, life as a game dev is MUCH easier now that we don't have to make every single brick ourselves. Building a game though, that still requires a lot of skill. All I am saying try to make a simple game with dialogs first. Learning the whole 3D stuff before you even know programming c++ or c# will not help you.
I am not trying to be harsh, I am actually trying to help you complete a game, because it seems really cool and I want to play it! :)
What formal training or education do you have? Do you know any other programming languages than batch script? Have you studied linear algebra (3D math)? If I knew that I might be able to help you a bit on the way to finding the correct engine for you to use.
Look Tozan you're approaching this the wrong way. Start making a simpler game. Just dialog based. THEN you can add some simple movement on a map. Unless you have a team of 10 experienced coders that can work for you for a year your game will never be finished if you try to make all the stuff you're describing.
I am not saying anything about batch script... I don't know much about it. I am just talking about game dev in general.
Yes, as it stands now your text assets are hard to port. If they were in a database separated from logic it would be a lot easier to port.
If you are looking at c64-games for technical solutions then I think you are doing something wrong. If you want to develop games learn one of the following:
1. Enough programming to make your own engine
2. How to use an existing engine
That's my two cents... Checking back through this thread I can't help to suspect trolling. Someone defending the use of batch-script for game development, talking about burning out HDDs, lip-synch and using c64-tech just seems... Unlikely... If that's not the case then I'm sorry but I don't think I can help you much more anyway.
Good luck with your game, I hope you switch to some other tech than batch-script and that you actually manage to finish it.
No it does not need to be in thousands of little text files (but it could be, i really doubt that this would be a problem*) it could very well be in a database, in xml or whatever BUT NOT EMBEDDED IN CODE!! If it was and you needed to change techs from say one game engine to another then there would be tonnes of work to port it.
Well each to his own I guess, whatever works for you and actually results in a game that people play is what you should go with!
As for Unreal, I never used it, I use Unity myself but Unreal is an engine used for AAA games. I think you're safe to trust them that they don't burn through HDDs or their QA would know about it.
*) I have never heard of any best practices in game development that you need to keep everything in one file for the purpose of saving HDDs of users.
Pages