|
4 years ago ::
Aug 16, 2009 - 9:17PM
#31
|
|
|
Only, it's been shown that wasn't why they didn't go that route, and the link and quote have been given to you over and over.
They weren't mislead into thinking it would be to hard.
Actually, if there excuse is that it will take a lot of extra time, or a lot of extra resources they are wrong, unless of course they are locked into a contract to use .Net 2003 or whatever. Really it takes a tiny amount of extra effort and time to do it at the beginning.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 9:40AM
#32
|
|
|
Actually, if there excuse is that it will take a lot of extra time, or a lot of extra resources they are wrong, unless of course they are locked into a contract to use .Net 2003 or whatever. Really it takes a tiny amount of extra effort and time to do it at the beginning.
That wasn't their excuse.
The reason was that it wasn't worth the cost, because the revenue from Mac customers wouldn't even cover the cost.
Meaning, they had the time, they had the resources, they had the money. What they didn't have was enough customers using MACs, before they started this. Not after, where mac using customers could simply run a emulator.
Why is that so hard to understand?
|
|
|
|
4 years ago ::
Aug 17, 2009 - 2:41PM
#33
|
|
|
That wasn't their excuse.
The reason was that it wasn't worth the cost, because the revenue from Mac customers wouldn't even cover the cost.
Meaning, they had the time, they had the resources, they had the money. What they didn't have was enough customers using MACs, before they started this. Not after, where mac using customers could simply run a emulator.
Why is that so hard to understand?
It's not. That's acknowledged for the CB, however this issue came up after the CB, but before they even knew which AT they were going to do first (MB). Thus they had plenty of time to plan it from the beginning of the MB to do it cross platform. Doing it from the planning stage would have cost almost nothing more than doing a plain windows version. Heck they could have even just made the windows version and designed it to be ported easily, and done that later on down the road. As of now.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 5:22PM
#34
|
Date Joined:
Apr 10, 2006
|
Mac support is not worth the money...
when I was taking a buisness class many many years ago it was explained to me as % retuern...
If I spend $100 to make $200 profit (Yes profit over cost)
or I can spend $125 to make $205 profit
or I can spend $150 to make $207 profit
witch is the best use of the money...well Years ago in that class I said C...spend 150 make 207 profit...I was told not really. you see in A I made 2$ profit (over cost) per dollor invested...in B and C that drops...the best use of my money is A...the largest out for the smallest in...
the reason is time... lets say it is a year investment...1 year of $100 tied up gives me $50 to put elsewhere...hopefuly at a better retuenr...
Before posting, ask yourself WWWS: What Would Wrecan Say?
|
|
|
|
4 years ago ::
Aug 17, 2009 - 5:43PM
#35
|
Date Joined:
Aug 13, 2007
|
It's not. That's acknowledged for the CB, however this issue came up after the CB, but before they even knew which AT they were going to do first (MB). Thus they had plenty of time to plan it from the beginning of the MB to do it cross platform. Doing it from the planning stage would have cost almost nothing more than doing a plain windows version. Heck they could have even just made the windows version and designed it to be ported easily, and done that later on down the road. As of now.
you assume that MB and specifically AT is separate then CB. I believe its the opposite it is gonig to rill in all the apps together.
So saying "Its a new app they could start a new platform" is invalid. Because MB is probably build upon the CB base because its going to all roll together.
 Never Point a loaded party at a plot you are not willing to shoot. Arcane Rhetoric. My Blog.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 7:38PM
#36
|
Date Joined:
Dec 31, 2007
|
The Adventure Tools' updater program is called "CharacterBuilderUpdater.exe"...
Now, could they have chosen to replicate work already done and make the AT on a new platform? Sure. But they didn't, presumably to save time (thus money) on bringing out the AT.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 7:44PM
#37
|
|
|
you assume that MB and specifically AT is separate then CB. I believe its the opposite it is gonig to rill in all the apps together.
So saying "Its a new app they could start a new platform" is invalid. Because MB is probably build upon the CB base because its going to all roll together.
While the apps might work together I believe based on my experiences that it will be more along the lines of each app opening the output of the other apps. As in the combat tracker opening the output files for the CB and MB. the campaign mapper or encounter builder opening each others files or something along those lines. Since this is the most likely case, it would not affect being cross-platform. It is as simple as reading XML which any platform can do.
Also its a misconception to assume that you are starting a new platform. Its more like building in the ability to separate what the app does from the platform its on, then just matching up an API on both platforms. It adds negligible time and effort to the actual work.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 8:00PM
#38
|
|
|
The Adventure Tools' updater program is called "CharacterBuilderUpdater.exe"...
Now, could they have chosen to replicate work already done and make the AT on a new platform? Sure. But they didn't, presumably to save time (thus money) on bringing out the AT.
There's another misconception. The code that does the calculating is a matter of copy and pasting. The only work that needs to be done is matching an API that will work on the other platform. It works like this:
Code that does the program specific things like calculating AC, and the attack roll and things of that nature sit at the top and make no platform or API specific calls. They make calls to a middle layer called the abstraction layer. The abstraction layer then makes calls to a specific API on a specific platform. This API can be changed out with a minimal rewrite of the abstraction layer to make calls to the new API. In most cases this is a simple find and replace job like 'find "createMSWindow()" replace with "createMacWindow()"' of course those functions don't really exist, but the idea is there. In the rare case that there is something that doesn't directly translate you can usually get it to do what you want it to do with a few extra lines of code. In situations like a Microsoft window control versus a Mac window control really most calls will have a direct mirror on the other API.
So like I said if you start with a cross-platform design there is very little extra time or money spent, and the amount of profit is maximized. Of course if they can't do it because they are making all of the programs in .Net because they want them to plug and play into each other, then there is nothing they can do. This is very unlikely and very amateurish, so I don't think they would be doing it that way.
|
|
|
|
4 years ago ::
Aug 17, 2009 - 8:22PM
#39
|
Date Joined:
Apr 10, 2006
|
So like I said if you start with a cross-platform design there is very little extra time or money spent, and the amount of profit is maximized.
Mr brown (My old buisness teacher) would have some diffrent thoughts on maximized... see every $ spent is an investment...if you can invest 5 to get 20, or 6 to get 21, 0r 10 to get 23...the maximized bet in buisness is 5 to 20...then to take the other 5 (fromt he 10 example) and find anything that is better then spend 10 to get 13...and you are ahead of the game...
Before posting, ask yourself WWWS: What Would Wrecan Say?
|
|
|
|
4 years ago ::
Aug 17, 2009 - 8:49PM
#40
|
Date Joined:
Apr 22, 2008
|
Lokiare:
Sure, it's possible to create cross-platform software, and there are several ways of doing it. The question isn't whether it's possible, but whether such a solution fit into time frame, assets, skills, experience, tools, costs, goals, advantages, disadvantages, and all other considerations.
Obviously it wasn't a good fit.
If it was always trivial to implement, with only advantages and no disadvantages, they would have done it, right?
Your insistence that you know how their development process should and does work arrogant, short-sighted, and naive.
They aren't out to screw over Mac users. It would be nice if there was a Mac and Linux version. However, it didn't work out that way. No amount of second-guessing and vicarious development on your part is going to change that until it becomes reasonable for them to do so.
In the meantime, it's best to use one of several solutions mentioned.
|
|
|
