Slashdot Mirror
Myth II Carbonized
novocastrian writes "As reported at PlayMyth, Myth II has been Carbonized and will be released to owners of the game on the 15th of March. The work was done entirely by dedicated followers of the game. The disappointing Myth III has also undergone a major overhaul and will be soon be hosted on a popular player-based server."
J adds: Myth II will not support hardware rendering in OS X. But as I recall, software rendering gave an almost-playable framerate even on my 604/250, so on modern machines it might not be bad. Myth I and II were great tactical combat games. I'm itching to play Mudpit again!
Are they going to do anything with the Loki version of Myth 2 for Linux. I haven't been able to get it to run on my Linux boxen for a year and a half now. I never bought the windows version. So if they don't work on it, I guess I'm outta luck ;(
I'm a conservatice devil and quite frankly the games I like best are the ones I played prodigously from around 13-17 before learned to program. New games don't seem all that great to me. In fact, nostalgia plays a major part in my enjoyment of games.
I therefore think it's terrific that all these old games are being brought to MacOS X, f.e. Quake I and Quake 2 and Starcraft/Brood Wars.
The Myth 3 "Lazarus" (as in "the dead guy'll look a whole lot better once we get these bandages off") project page is here. (They have a Hotline server for build access, a nice, Mac-centric touch.) It seems that former Mumbo Jumbo developers are involved in the project, so hopefully M3 will emerge from the "beta-quality with a golden-master price" limbo it labored in for so long.
"Freedom is kind of a hobby with me, and I have disposable income that I'll spend to find out how to get people more."
This is truly a wonderful example of what a dedicated group of fans can pull off (in addition to Linux, of course ; )
::KABOOM::
I've been fairly unenthused with just about every game I've ever played, with the exception of the Myth series. The balance of skill, unit selection, terrain, and a little bit of luck makes it the most playable game I've found yet.
Just this christmas vacation we all got together for our annual LAN game -- did we play the latest and greatest Quake or Unreal version? Course not! Myth II for nine hours straight. Fear my 'lock, bitch!
Now all I need is a carbonized Deus Ex (yeah, not likely) and I will be in heaven. Well, that and Carmageddon I and II. ;)
I watched C-beams glitter in the dark near the Tannhauser gate.
this is great news. i was hoping for this just a few days ago. I still play myth 2 online at playmyth.net almost everyday (how many 5 year old games can say that? best $40 i ever spent.
In related news, Solitare has been carbonized and will now work optimally on OSX. ;-)
1. Bad signature
2. ?????
3. Profit
Religious wars aside, they're both perfectly fine development environments: Cocoa (nee OpenStep) provides a lot of encapsulated bang for the development buck, but Carbon has both familiarity for old Mac developers and access to deprecated but still-vital functionality. (N.B., I use Cocoa with small amounts of Core and Carbon for functions like getKeys() and the CoreGraphics suite -- but, then, I was never a Mac developer before OSX. YM, as they say, MV.)
Apple keeps going the extra mile with each OSX point release to improve each environment -- the goal at this point is functional parity (though ease-of-use will always differ). Choose whichever one appeals to you, and don't be afraid that one environment is "inferior" to the other.
"Freedom is kind of a hobby with me, and I have disposable income that I'll spend to find out how to get people more."
Carbon is yesterday, Coca is tomorrow. I simply can't say enough good things about Coca.
"A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
This is really an opinionated question, so it's hard to get a "real" answer. But I feel that a common misconception is that Cocoa is better than Carbon and Cocoa is phasing Carbon out. I think Carbon is going to be around a long long time. I hear people saying "oh, Carbon isn't gonna be with us in two years". Then I remind them that Apple's own Finder app is Carbon. Most of the major Mac apps are Carbon, too (Photoshop, BBEdit, Microsoft Word, etc). At least in earlier versions of the OS, (not sure about now) Cocoa actually used Carbon for many of its functions!
:)
My personal opinion is that both environments have their own advantages. There are a few things like Gestalt that are really handy in Carbon. Cocoa makes it a lot easier to create an app (sometimes this can be viewed as a disadvantage), and is generally easier to learn for newcomers. Some of these gaps will probably close; others will not change.
Some Cocoa projects of mine have used or do use Carbon for certain purposes. Up until recently, the "chasing arrows" or now the spinning gearwheel indicator was only available through Carbon. In 10.2, it's available with Cocoa too. Also, Gestalt. Plus, Carbon has some Apple Event APIs that aren't available in Cocoa. This is just to name a few.
So, essentially, they are both as good as each other. If you've had previous experience with the OS 9 and below toolbox, go for Carbon. If you're new to OS X programming, I'd recommend Cocoa. Cocoa also gives you a lot more free stuff that takes more work to add in Carbon, like Services and spell-checking. When I tried to learn the Mac toolbox a few years ago, I was very confused, and Cocoa seemed to fit right with me. But now that Carbon exists, there are probably better tutorials and books out to help teach it. It's really up to you and your preferences.
Here's a link with more info on Carbon vs. Cocoa:
http://www.unsanity.org/archives/000024.php
Again, this is just my opinion - there's no right answer, IMO. Hope this helps.
Myth: The Total Codex was the first computer game I ever played, and loved it. Didn't actually finish Myth II when I got sucked into Starcraft/Brood War but wanted to go back and replay it. Then OSX came and that was that.
I was in the middle of Rune as well when I upgraded. I wonder if and when that will be carbonized?
Etc, etc, ad nauseam, and so on and so forth.
Damn right coca is good. Where else can you get cocaine, but the coca plant? :-D
-/-
Mikey-San
Mikey-San
Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
As a long-time NeXTSTEP, MacOS (all the way back to Finder 1.0), and Newton developer, I have to take some issue with this claim that Carbon has many advantages over Cocoa at all.
Here's what it boils down to: Apple had a lot more developers and a much older OS than NeXT did. This means that MacOS had a lot more low-level hooks for goofy weird things than NeXTSTEP did. Thus Carbon has various low-level hooks that Cocoa doesn't have.
Which is exactly why you shouldn't be using it for your application, except under very special circumstances. You almost never need those hooks (or should instead be hooking to UNIX), and they just make a disaster out of your coding experience.
Cocoa was designed as an *application*framework*, not evolved as a giant morass of hooks to do this or that. And as an application framework, it beats the living bejesus mega-snot out of Carbon. Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT. You use Cocoa to write the vast majority of productivity apps. You might use Carbon when your app needs to do some odd thing that Apple isn't able to convince users to stop doing yet. But for low-level access, the Right Way to do things, if at all possible, is with Cocoa on top and BSD APIs underneath. If you can in any way help it. Carbon is really, *really* not worth the pain.
And Carbon IS a legacy library.
Sure, the Carbon developers desperately want to convince themselves, deep down, that it's NOT a legacy framework. But it is. It reeks of legacy. Apple maintains it, and adds services to it to keep it in trim, basically because of (1) Microsoft and (2) Adobe. Big software firms don't take kindly to Apple not supporting their recently-ported applications, even if they are written to link against a big pile of poo dating from the 1980's. Apple is supporting Carbon NOT because they want to. They are supporting Carbon because they HAVE to. They have no choice due to the power of their legacy developers.
Write your apps in Cocoa. Or in Java if you must. But don't write in Carbon. Might as well write 'em in COBOL.
The main advantage is that it allows the old apps to be ported to OSX. Without Carbon they'd have to be re-written from scratch - sure that's nice if you have the time and manpower, but for a lot of software houses it would be a huge deterrent. Yes its crazy to write a brand new program in Carbon, but it was and is essential for moving old apps to OS X quickly and relatively painlessly. Horses for courses.
Cocoa has true internationalization, complete unicode usage, real java interoperability, a modern, sophisticated set of graphics primitives, good access to a wide range of services, and a first-rate set of highly integrated widgets. Carbon DOES NOT.
Actually, it has identical access as Cocoa (from 10.2). Your anitpathy towards Carbon says more about you as a developer than it does about Carbon's usefulness.
The fact that Carbon has "a giant morass of hooks to do this or that" is simply due to its development over time - Cocoa has the benefit of being largely written all at once (and so has a fairly uniform design), however its main flaw as an API is that it just hasn't had the widespread use and testing that Carbon has.
This means it's ultimately less capable in some areas: e.g., how do I iterate through the list of GUI apps in Cocoa (in Carbon it's easy - talk to the Process Manager and walk through the list). The new Carbon APIs which are coming out of Apple these days (Carbon Events, HIViews, CF, etc) aren't making any of the "mistakes" people made in '84: these are APIs designed for the future, with opaque accessors, reference counting, and a very OOish flavour.
I'm a long time Mac developer as well ('86), as well as *nix/Win32, and frankly Carbon is one of the main reasons Mac OS X is still attractive as a platform - Cocoa is a nice framework, and it certainly was cutting edge when it first came out, but the world has moved on. It's just not that innovative any more, sorry.
And Carbon IS a legacy library
No, it's not. If you'd talked to Apple recently, or been to WWDC in the last couple of years, this would be crystal clear. Carbon is as much a part of the Mac's future as it ever was, and arguably in a more stable position than Cocoa (99% of the developers who generate money for the platform are using Carbon).
I am the project coordinator for the Myth 2 and Myth 3 projects. There are a lot of things being done to support these two titles. We're looking to port M2 to OpenGL for a future update - we just wanted to get the carbonized version out for people to start playing. We fully intend to support hardware accelleration via OpenGL at some point. More things in store also. Myth 2 will be in carbon by 3/15, Myth 3 will be finished by 4/15 and we have another update for M2 coming in May. For complete info, go to mythdev.com. This is the home page for these projects.
(no body)
Good example:
Guild assembles army on hill, opposite another army. Air is thick with tension. Our intrepid leader speaks.
Us:"We're sending out a ghol to negotiate!" Single ghol advances.
Them: Arrows. Dead ghol.
Us: "That's okay! We'll send out another one!" Another ghol goes out.
Them: Army charges.
Us: Army cheers! Fetch burn Peace symbol into hillside. Then a Twenty-one Wight salute. Everyone runs (or, walks... this is Myth after all).
Them: "WTF?!?"
Good times.
If Jesus wants me it knows where to find me.
e.g., how do I iterate through the list of GUI apps in Cocoa (in Carbon it's easy - talk to the Process Manager and walk through the list).
...
Actually, it's easier than that in Cocoa:
NSDictionary *thisApp;
NSEnumerator *apps = [[[NSWorkspace sharedWorkspace launchedApplications] objectEnumerator];
while (thisApp = [apps nextObject])
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
I'm a switcher, and stories like this are just fodder for my PC friends to make fun of me.
Myth II????
But I feel that a common misconception is that Cocoa is better than Carbon and Cocoa is phasing Carbon out. I think Carbon is going to be around a long long time.
Sure, Carbon's going to be around for a long time. So will stdio.
There's a reason why Apple's apps group is using Cocoa for pretty much every app they don't have to back-port to OS 9.
go to Http://www.mariusnet.com. This is the new server for Myth The Fallen Lords (Bungie's went down in 2001). If you've lost your CD serial number, don't worry, it isn't required anymore.
Cocoa has had over a decade of use and testing in its various *Step incarnations. Sure it's changed since then, but as you point out so has Carbon.
these are APIs designed for the future, with opaque accessors, reference counting, and a very OOish flavour.
Or you could use Cocoa and have real OO, not "flavored".
arguably in a more stable position than Cocoa (99% of the developers who generate money for the platform are using Carbon).
I'd like to see your source for that figure. All of Apple's new applications are Cocoa. They've said repeatedly that Cocoa is the best path for new application development. What do you know that they don't?
How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
Cocoa has had over a decade of use and testing in its various *Step incarnations.
It's hardly comparable - NeXT never really had the kind of wide-spread user base that Apple did. Both in terms of numbers of users, and in variety of apps. My point was more that the odd warts and barnacles that accumulate over time are normally there for a reason - there's the odd dubious hack, of course, but every API will grow over time as it matures. Of course, one of the whole points of the Carbon project was to remove stuff that really was pure cruft from the previous Toolbox APIs - and by and large they have.
Or you could use Cocoa and have real OO, not "flavored".
Leaving aside opinions on what's "real OO" or not, you can use whatever application framework you like if you use Carbon (PowerPlant, Zoop, your own cross-platform system, etc). If you're using Cocoa you're basically comitting your front end code to be Objective-C talking to AppKit.
I'd like to see your source for that figure. All of Apple's new applications are Cocoa. They've said repeatedly that Cocoa is the best path for new application development. What do you know that they don't?
I've been around long enough to know that Apple isn't a monolithic entity - there are different factions within the company, each of whom have their own agenda. The people touting the "all new applications must be written in Cocoa" line largely came from NeXT, and the drive to write the iApps in Cocoa comes directly from an ex-NeXT executive. Apple have had numerous "xxx is the future! We mean it this time!" phases in the past, and IMHO Cocoa could quite easily find itself turning into a similar case.
Although Apple's developer programs are quite reasonable, they are quite up front about the fact that they focus most of their resources on the "top 100 developers" (Jobs' words, from their annual shareholder meeting a couple of years ago).Those developers (Microsoft, Adobe, etc) all use Carbon, and will probably continue to do so until the end of time.
I don't work for a company that size, but what can I say - we looked into Cocoa, and decided it wasn't the miracle cure it's touted to be. We write the odd in-house tool with it when we need a GUI quickly, but really that power comes from Interface Builder (which works just fine for Carbon apps as well).
Cool, didn't know that - although to be honest they look equivalent rather than easier... :-)
But it's handy that you can get the PSN out of the dictionary as well, so you can always call over to the Process Manager while iterating if you ever need to.
As it turns out, I have been to recent WWDCs. Also to MacHack. But whatever. I would view Apple's presentations on Carbon far from "this is the way to go!". More along the lines of: don't be scared, everything's okay, Carbon's not going away, see, look at the new things we're adding to it. Put short: there are no such hand-stroking presentations for Cocoa.
Carbon only exists because Apple has to keep its existing MacOS 9 developer base. Had it had its choice, Apple'd dump Carbon like yesterday's leftovers.