Nothing is set in stone but...these are some of the things me and jake would like to put in
MScript - Don't know VB? Not a real programmer? MScript will make it easy for you to start a basic RPG. It will also give the more advance users a break from re eventing the wheel and go right into the core development.
Built in guild support
Built in mission/quest editor.
Me and Jake are in talks about having the engine work with SQL for websites and so on.
Upside : SQL database could provide an awesome ammount of website integration options
Downside : Gives the user who host the server more work and may scare away less IT sabby users
Dragoons Master
Unregistered
Full bin packets w/ .NET NETWORKING!
Inprove AI!
Let's get some more input on SQL vs Files.
No thanks...
SQL would be nice...but it'll be way too complicated. Try to make it as user friendly as possible.
You SHOULD do SQL...but include lots of detailed help documents for it 
SQL & flat files read/write speed is about the same, flat files are a little easier for the typical user to get working. Start with flat files, and make a SQL branch later down the road. Any data system can always be converted to any other data system, so it doesn't really matter which one you choose. I'm always in favor of the simple approach, flat files seem simpler.
Quote:MScript - Don't know VB? Not a real programmer? MScript will make it easy for you to start a basic RPG. It will also give the more advance users a break from re eventing the wheel and go right into the core development.
Good.. My suggestion is anything that can be scripted should be scripted, keeping the source as small and simple as possible. I don't think you should 'dumb it down' for the average developer.. make it just as powerful as coding.
Quote:Built in guild support
Built in mission/quest editor.
I'm a little disappointed about this, I think mirage should be a bare bones engine.. What if I don't want guild or mission support in my game? I have to manually take it out? Wouldn't it be better for us to choose whether or not we need these features and add them in if need be?
Mirage is great because it doesn't incorporate a bunch of half-assed bloatware features.. You don't have to spend days taking out what you don't need. I think the .net version should take this idea even further, and only provide us with the bare bones.
Support doesn't (or shouldn't) mean it's a must have...it's just like an optional thing. Like if I say you have my support, doesn't mean I'm going to be helping you all of the time, just whenever you want me to help you. So if you don't want guilds, then I'm sure you can take them out easily.
unknown Wrote:I'm a little disappointed ...
I should have been clear on what I said. These would be add on packs that would either come with the engine, or be released at a later date. They would however be 100% separate from the engine.
It would more then likely be just a script and a walk through file on how to use said script (if you wanted to). Providing these scripts will now give users , who wish to use them, extra features as well as provide examples of the newly developed MScript language.
So long story short, you will still get your bare bone engine.
I only have one issue with SQL and that's when programming, I would have to install SQL Server on my computer and run it. I hate having that thing installed. On the bright side, it's easier to manage the data and it's faster. As well as having the website integration support.
*shrugs* I'm for and against both. Lol.
Exadon Wrote:unknown Wrote:I'm a little disappointed ...
I should have been clear on what I said. These would be add on packs that would either come with the engine, or be released at a later date. They would however be 100% separate from the engine.
It would more then likely be just a script and a walk through file on how to use said script (if you wanted to). Providing these scripts will now give users , who wish to use them, extra features as well as provide examples of the newly developed MScript language.
So long story short, you will still get your bare bone engine. Sounds great, I'm glad we're on the same page.
I vote for flat files because..
- You can easily convert from flat files to SQL (if needed)
- Flat files are easier to program
- More people will be able to use your server if you use flat files
Well hopefully we code this in a way that different data structures can be modular. That way anyone can develop a SQL module and plug it into the system and that's all that would need to be changed. Just a thought...
I don't know if it's possible but make it an option in some kinda config file whether to save the data to mysql or to save it locally on your hard-drive. This would be better for more basic people who can't afford webhosts just for the purpose of testing a game they are working on or hosting for friends. I'd use the data files on pc over mysql personally though but that's just me.
Add MySQL Definitely, used files as an addition. It'll make a lot of peoples lives easier if someone doesn't have to make an unofficial version with MySQL Added.
I'd say have them save locally by default, but we should have detailed documentation, including lots of copy and paste code, for converting the default MS# to use SQL.
James Wrote:Agreed. Also, could we set it up so you did not have to have it use a local MySQL server to run, but be allowed to connected to say, a remote one based on your web host with all the correct information? This way developing would be such a hassle..?
I hadn't thought of that. Would be perfect if possible. Everyone has access to at least ONE mysql database.
Nice, James.
Of course I would have the SQL that way.
James Wrote:Agreed. Also, could we set it up so you did not have to have it use a local MySQL server to run, but be allowed to connected to say, a remote one based on your web host with all the correct information? This way developing would be such a hassle..?
As far as I know, it 's against most web host rules to have an application (off the web) connect to a remote web host MySQL database. I don't know if this is the case for all web hosts however..
Toast Wrote:James Wrote:Agreed. Also, could we set it up so you did not have to have it use a local MySQL server to run, but be allowed to connected to say, a remote one based on your web host with all the correct information? This way developing would be such a hassle..?
As far as I know, it 's against most web host rules to have an application (off the web) connect to a remote web host MySQL database. I don't know if this is the case for all web hosts however..
Yeah, you'll have to check with your webhost if they allow remote connections.
Yeah to use it with your website you will also have to have your website stuff stored on your db of your game. Well depending how your incorporate it. As said most web hosts dont allow remote connections to mysql servers.
|
