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.
Lip synch?? I think you may approach this the wrong way... Start solving simple problems, like getting a game engine to work, and then do the AAA-stuff a few years down the road... Don't animate any characters at all, instead just focus on getting some basic gameplay working in unity or unreal and if you have more time, generate more content! Not a lot of people will care THAT much about character animations much less whether they have working lip-synch!
As for the assets, all the text written should be considered an asset and stored as such (in separate text files, xml or whatever) is what I meant before.
I think you misunderstood, they meant that you could write ascript that reads the text of your batch-files and translates it to another language. I think you're better off starting over with e.g. Unity and just reuse all you content (that is, all text and images you already created).
To make the transition easier you should get some type of Dialogue extension from the asset store, e.g.
I haven't that one myself and there are others so check around a bit before buying. If you don't want to learn c# (you should, it's a lot eaasier than batch-script IMO) then there are visual scripting extensions as well. I think Playmaker is the most used one. I haven't used it myself though, I like writing code :)
If you wrote 50k lines of batch script then I suspect that you included the output text in those scripts? That's a mistake you're now paying for when transitioning technologies. Imagine if all your text was instead in a text file that your batchscript read from? Then you could just write a new c#-script in unity and reuse the same asset. That's why we always try to separate data from logic, I learned that the hard way myself many many years ago...
Again, good luck, whatever solution you decide on!
After waiting almost 3 weeks my engine is now up on asset store! Thanks a lot for publishing CC0 assets, they really make the engine shine a lot more. I think maybe I'll update it a bit more later on to support larger maps (currently you don't want to go above 512x512) and maybe some procedural city generation and stuff. In the application for asset store sales I also mentioned that my engine would work well in a bundle with assets like yours and eg "Simple buildings - Cartoon city".
Now I just need to figure out a simple game to make, I want to keep it a bit simpler than Transport Tycoon for a first iteration, maybe some type of idle game, sort of like my demo that's linked in the asset store
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.
Lip synch?? I think you may approach this the wrong way... Start solving simple problems, like getting a game engine to work, and then do the AAA-stuff a few years down the road... Don't animate any characters at all, instead just focus on getting some basic gameplay working in unity or unreal and if you have more time, generate more content! Not a lot of people will care THAT much about character animations much less whether they have working lip-synch!
Solve simpler problems first...
If lip synch is a must then it if possible, UMA has phoneme lip synch so you could make a text-to-phoneme parser for it. https://www.assetstore.unity3d.com/en/#!/content/35611
As for the assets, all the text written should be considered an asset and stored as such (in separate text files, xml or whatever) is what I meant before.
I think you misunderstood, they meant that you could write ascript that reads the text of your batch-files and translates it to another language. I think you're better off starting over with e.g. Unity and just reuse all you content (that is, all text and images you already created).
To make the transition easier you should get some type of Dialogue extension from the asset store, e.g.
https://www.assetstore.unity3d.com/en/#!/content/14854
I haven't that one myself and there are others so check around a bit before buying. If you don't want to learn c# (you should, it's a lot eaasier than batch-script IMO) then there are visual scripting extensions as well. I think Playmaker is the most used one. I haven't used it myself though, I like writing code :)
https://www.assetstore.unity3d.com/en/#!/content/368
If you wrote 50k lines of batch script then I suspect that you included the output text in those scripts? That's a mistake you're now paying for when transitioning technologies. Imagine if all your text was instead in a text file that your batchscript read from? Then you could just write a new c#-script in unity and reuse the same asset. That's why we always try to separate data from logic, I learned that the hard way myself many many years ago...
Again, good luck, whatever solution you decide on!
You are either mad or brilliant. I eagerly wait to find out which :) Either way I wish you good luck, can't wait to see the result of this endeavour!
After waiting almost 3 weeks my engine is now up on asset store! Thanks a lot for publishing CC0 assets, they really make the engine shine a lot more. I think maybe I'll update it a bit more later on to support larger maps (currently you don't want to go above 512x512) and maybe some procedural city generation and stuff. In the application for asset store sales I also mentioned that my engine would work well in a bundle with assets like yours and eg "Simple buildings - Cartoon city".
Now I just need to figure out a simple game to make, I want to keep it a bit simpler than Transport Tycoon for a first iteration, maybe some type of idle game, sort of like my demo that's linked in the asset store
Here's the asset on the store BTW:
https://www.assetstore.unity3d.com/en/#!/content/37649
Awesome! To make a full "Transport Tycoon"-like world I think some more types of vehicles and buildings would be really nice...
Pages