I'm working with a team that's building an engine for a variety of 2D and eventually 3D mini-games. The problem we're facing is a solid, cross-platform, sound API. Obviously, DirectX is out of the question due to our needs for cross-platform capabilities. SDL is nice, and works great, but let's face it SDL_Mixer is a bit limited in what it can do. We're currently using it, but when we eventually expand to 3D, it's going to be a problem.
I've been messing with OpenAL, but most of the documentation I've found is fairly out of date, and doesn't seem to work all that great. I'm willing to learn OpenAL, and fight my way through it, but I'd like to be a bit more certain that I'm not wasting my time. Other than the DevMaster tutorials though, I haven't seen much documentation that's blown me away. If someone has some better material than I've found, that'd be awesome.
I've also seen projects such as FMOD, which seems decent despite the licensing. However, like OpenAL, they have nearly non-existant documentation. Granted, I can pour over the code to deduce my options, but it seems like a bit of a pain considering I might eventually be paying for it.
Anyways, thoughts, comments, concerns? Thanks a lot!
(note: I have experience with FMOD, BASS, OpenAL and DirectSound; and while I list other libraries below, I haven't used them).
BASS and FMOD are both good (and actually I liked FMOD's documentation a lot; why would you say it's "non existing"?). There are also Miles Sound System, Wwise, irrKlang and some more middleware packages.
OpenAL is supposedly cross platform, and on each platform it has it's own quirks. It's not exactly "open", either. And I'm not sure what is the future for it; it seems like it got stuck when Creative got hold of it. There's a recent effort to built the implementation from ground up, though: OpenAL Soft.
Then there are native platform APIs, like DirectSound or XAudio2 for Windows, Core Audio for OS X, ALSA for Linux, proprietary APIs for consoles etc. I think using native APIs on each platform makes a lot of sense; you just abstract it under common interface that you need, and have different implementations on each platform. Sure, it's more work than just using OpenAL, but OpenAL is not even available on some platforms, and has various quirks on other platforms that you can't even fix (because there's no source code you can fix). Licensing a commercial library like FMOD or Miles is an option in a sense that all this platform dependent work is already done for you.
We're using OpenAL at work right now, but are considering switching away from it, because it's just not going anywhere and we can't fix the quirks. So while OpenAL is easy to get started, it does not get my vote as a good option.
I have used DirectX, FMOD and Wwise on a range of platforms in shipped games. I won't talk about DirectX here since other people will have plenty of feedback here ;-)
Here's what you need to consider:
License, I put this first because this may make your decision for you. Have your lawyer go over them and make sure you understand the costing and restrictions.
API - FMOD has a very clean, minimal API that is very easy to grok. Wwise offers a little more in terms of functionality, but its API seems much larger and cumbersome with awkward concepts to get your head around.
Tools - Wwise has very sophisticated tools, geared very much towards audio-designers rather than programmers, if you want to give audio designers a lot of direct control and room for experimentation, Wwise may be the way to go. FMOD is catching up in the tool department but its tools are more geared towards programmers I feel.
Performance - This is something you'll need to evaluate for yourself, you can't say any one is better than the other because it depends on your platform and type of game. You may get performance statistics quoted to you - take these with a grain of salt, they may well be idealised in some fashion. Determine your performance budget (eg 2 ms per frame for sound, X number of channels, X number of streams) and do a bunch of tests for different sound formats, sample rates and bit depths - graph those suckers.
Support - Both FMOD and Wwise have very good support channels, good tech guys. Check if support costs extra though.
If you're asking me to pick one.. FMOD - it really is a very good product, those guys do a great job.
I've recently worked on a AAA PC title that used FMOD. Our audio programmer loved it and was very productive with it, so I'd give FMOD a thumbs up. We only used FMOD on Windows so I can't speak to the cross-platform aspects of it at all.
The Bass library works on Mac and Windows, and has good documentation and SDK examples:
http://www.un4seen.com/
I've shipped two PC games using Miles Sound System and it worked quite well. MSS is easy to integrate, fast, and stable. The support you get from RAD Game Tools is excellent. This library has been used in over 4500 games, and it is rock-solid as a result. It's cheap too!
On the other hand, MSS is a fairly low-level library compared to FMOD or WWise. The library doesn't provide any way for the sound designer to have control over sound volumes, attenuation, randomization, fading, or just about anything else that isn't stored in the sound file itself. You will have to write these high level features yourself.
That's why I'm evaluating WWise for my next game. It has a much more developed toolset than Miles. It took longer to get up and running, but is working well so far. I'm not nearly far enough into using it to really offer a recommendation one way or the other.
Wwise is probably the most complete solution for sound development in terms of workflow. The way it's designed really saves you programming time and gives you more possibilities to experiment and build complex sound structures. With Wwise, we were able to keep the project organized for our team.
I personally really like their interactive music system. It's flexible and makes your music smoothly react to your game inputs.
Also, Audiokinetic's support is very sharp too. Always fast and ready to help.
I recommend.
I can vouch for FMOD as well, it's used quite a extensively in game development due to the tools and excellent multi-platform support. It's designers are really a bliss to work with. Thing is though, it requires an expensive license for commercial development.
Related
I am looking for a C++ library for reading data matrix codes, specifically ECC 200 codes (so not QR codes). I have found libdmtx and zxing. zxing is java, but there seems to be a C++ port. Does anyone have experience with reading ECC 200 codes with these libraries, or possibly with other libraries?
The DM support in the C++ port of ZXing is up to date with the Java (not true of many of the 1D codes). It's not enabled by default in the test apps but is easy to enable (and will be enabled by default in the future.)
I don't have any personal experience with actually using the DM decoder but it is included in the test suites and I believe available in the Android app.
Here's a real answer then.
I have used both libdmtx and libzxing succesfully. Libdmtx was more straightforward, because it's limited to datamatrices. In my experpience the results were, strangely enough, not always deterministic.
Libzxing is fine as well, but when you do real production (millions or readouts) it will crash sometimes due to the fact that memory management is not perfect. It's really good, but not perfect for a real production environment.
Both the libraries, libzxing and libdmtx require you to have the datamatrix deadcenter of the image and quite large. That means you need to do pre-localisation yourself.
I managed to do this by just using image routines and looking for the 'L' shape and then some smartness with a minimal-area squared bounding box, etc etc. Then the decoding and error correciton step itself i used from libzxing, which still isnt perfect.
If you go for a production environment, either do everything yourself within your own contraints, and if you are not comfortable with doing that, use a paid package, which in turn are never perfectly suited for your application and cost money.
The best port of libzxing-cpp is that of user glassenchidna. https://github.com/glassechidna/zxing-cpp
I am currently trying to use libdmtx
http://www.libdmtx.org/
It has support for all kinds of interfaces. It seems to have good reviews here and in other places….
(But I am looking for help on building the utilities :-)
Since no "real" answer was posted to my question, at least no answer from someone with experience with one of these libraries for reading 2D matrix codes, I thought I will post my own experience.
I tried both libraries and both could read codes, but the performance was not good enough for my situations. In my situation the codes are frequently not "perfect", Dots can be missing, have different size, and code can be a bit skewed. Both libraries had problems reading these codes.
At the end I used a commercial (not free) library, Sapera. Sapera was able to read the non-perfect codes much better. I used Sapera because it was used at my company in the past, but it is quite possible that other commercial machine vision libraries (like Halcon) also perform well.
I have exensively used Halcon, including for Decoding DataMatrix. I can tell you that it works really well. Even with distortions caused by, for example, reading off a circular body, or skewed prints, it still is able to read them very well, in a short amount of time.
The only downside, and a big one, is the price. The runtime license is very expensive, and you need a development license before you can purcahse a runtime license, which is even more expensive. Unless you project has enough funds, this might not be an option due to this reason. Good luck!
I'm a relatively new developer, and I'm looking to learn C++. I've had experience coding in java, javascript, actionscript, and python, but I want something fast enough to do some high performance 2D and 3D games.
When I eventually learn the basics (control structures, classes, etc) I'd like to develop a 2D game. I've explored various libraries for 2D graphics (cairo, sdl, openframeworks, clutter) but clutter seemed to be the most optimised for accelerated graphics and vector drawing.
Would clutter be a good fit for a 2D game? I realise that it maintains its own scenegraph unlike other libraries, but I've developed a flash game in the past, so I should be used to that.
Are there any performance issues I should be aware of? Has anyone else had experience doing heavy graphics with clutter?
I've done a lot of embedded systems work using Clutter, and am now doing a desktop project with it. It would probably be great for a desktop-based 2D game, with certain caveats:
Mainline development on the toolkit is very heavily Linux-oriented. I'm not sure how well the Windows, Mac, or iOS ("fruity") ports are maintained.
Documentation is sparse, and afaik there are no books. (I'm thinking of writing one.)
It's written in C, and natively exposes C-language bindings. While there are Clutter bindings for many languages including C++, you'll still need to understand the C-language bindings.
It doesn't natively use C++ objects. Instead it uses the C-based GObject system for single-inheritance objects, and even if you're writing to it with the C++ bindings, you'll need to understand about GObject some, too.
If you want to use it with threads, you have to use its threading system - not POSIX threads, or Boost threads, or anything else.
It can really beat the tar out of a GPU, so if you're doing something fancy, frame rates can be mediocre on some of the low-end Intel chips used in cheap laptops and netbooks.
That said, you can do amazing things with it. I really enjoy working with it, and once you understand how to do it, mixing-and-matching with C++ is a lot of fun.
Also, there's a really rockin' open-source conference called GUADEC where the Clutter folks hang. If you were to show up there in July 2011 in Berlin with a really fun Clutter-based game, people would buy you lots of drinks.
I must admit I've never heard of Clutter before, probably because it's not a Windows library and the majority of games developers work on Windows platforms. Similarly, most game developers (even indie/hobbyist ones) are not considering Cairo, or Openframeworks either. More common by far would be the use of SDL, although that is not fully hardware accelerated and thus not a good choice for modern games. SFML is an alternative that is growing in popularity, but most game developers these days are probably rolling their own OpenGL rendering on top of something like SDL.
By the looks of it, Clutter might be a good choice, and it certainly seems fully-featured. But sometimes the problem with the larger frameworks is that they become a bit of a walled garden and it's hard to integrate extra bits that you might need - for example, I don't know how well the input might work.
The other problem with using a less well-known engine is that if you go to https://gamedev.stackexchange.com/ or http://www.gamedev.net and ask questions, the community won't be able to help as much since they are not familiar with the technology you're using. You have to balance the cost of that against the potential gains that come from using an unpopular but actually very competent library. (As well as the possibility that these other guys know something you don't...)
Clutter is relatively new and there are not many applications that use it right now. Especially games. So you will have a hard time finding somebody who has experience with it for gaming purposes.
That said, clutter indeed has some interesting features that make it look compelling for the purpose, and I would even claim that for many types of gameplay the internal scene graph can even be an advantage to the game developer.
I would like to propose you another interesting option for 2D game graphics: Qt from Nokia.
While it is primarily a general-purpose GUI toolkit, it has nice proportions not every game developer would be aware of in first place. In fact, it has a fully-fledged OpenGL drawing backend which can be used to draw any widget, and to use any of Qt's canvas drawing operations.
Things go crazy as soon as you start to explicitely using a QGLWidget, which not only enforces GL drawing mode (which is not the default), but also allows you to mix your own GL drawings with Qt's drawing operations in the same context. You gain the possibility to not only use simple-to-use, high level drawing operations paired with a powerful event queue and efficient input handling; furthermore you keep the freedom to build-in more advanced, low level graphics in the future.
See this example. Note that you can mix native GL drawing freely with Qt's Painter functionality (if you take care of the GL matrix stack).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm looking for some answers for a project I'm thinking of. I've searched and from what I understand (correct me if I'm wrong) the only way the program I want to make will work is through 3D application. Let me explain.
I plan to make a studio production program but it's unique in the fact that I want to be able to make it fluid. Let me explain. Imagine Microsoft's Surface program where you're able to touch and drag pictures across the screen. Instead of pictures I want them to be sound samples (wavs,mp3,etc). Of course instead the input will be with the mouse but if I ever do finish the project I would totally add touch screen input compatibility! Anyway, I'm guessing there's "physics" to do with it which is why I'm thinking that even though it'll be a 2D application I'll need to code it in a 3D environment.
Assuming that I'm correct in how I want to approach my project, where can I start learning about 3D programming? I actually come from PHP programming which will make C++ easier for me to learn. But I don't even know where to start. If I'm not wrong OpenGL is the most up to date API as far as I know.
Anyway, please give me your insights guys. I could really use some guidance here since I could totally be wrong in everything that I wrote :)
I would like to add that I'm most likely looking for tutorials, Linux 3D programming sites, source/demos (google failed me for the most part).
Note: I also understand this is not a project I'll finish in weeks, months and might take years. That's fine, I want to get C++ under my belt however long it takes. I'm just looking for opinions, sources, tutorials and things that might help me (as stated above).
I don't know much about the MS Surface, but I'm a musician and multimedia artist working mostly with code, so... My advice is very much different - it doesn't matter if it's Irrlight, Orge, pure OpenGL or anything else. If you don't know much about 3D prgramming you'd better start with something different. There are several environments for artists to work with graphics, multimedia and code. Try one of them and watch the projects made in each of them on the project's websitees and on Vimeo. I think most of what you want to do is already done, but still can be very inspiring. The environments that come to my mind are:
Processing - great prototyping environment by Ben Fry and Casey Reas. I use it always before coding anything serious as it provides me with all the multimedia and communication libraries i need, it's simple like hell and it's Java so you can easli deploy your apps after all! (As far as I remember there is touch surface library for Processing)
openFramewoks - same as above but C++, but it's less clean and still under development. It's very easy to prototype in Processing and code finally in openFrameworks as the latter was very much influenced by the former. (The touch surface library is implemented for oF for sure)
NodeBox - great and very powerful environment in Python. Has a very strange but great and intuitive (after all) GUI with some very unique methodolody of work!!
SuperCollider is a wonderful sound processing and algorythimc composition programming language with a very easy to code GUI library and graphics API. It gives you everything you ever imagined about sound programming functionality.
Pure Data - graphical approach toward programming. Made by Miller Puckett (the co-author of Max/MSP) with OpenGL (GEM extension) functionality provided by the guys from IEM in Austria.
Final good advice: Books!!! Programming Interaction (O'Reilly), a few books on Processing website, classic work - Computer graphics for Java programmers (great one, really!!). Read as well all the chapters about domain languages and domain knowladge in "97 things every programmer should know". It can really help!!
BTW: if you don't concider heavy real-time procedures thing about Java (Java2D, Java3D, JOGL) - it's millions times easier then C++ and Processing is actually Java, so you have a very good prototyping environment that can produce ready to use Java classes and applets. I used Processing in real-time theatre productions where stage movement was controlling the sound (syths and hardware samplers) all made in Processing, so this "heavy real-tme" means HEAVY real-time!!
If any further questions about this particular domain programming - don't hesitate to email me.
Coming from PHP won't make C++ any easier to you as riding a bicycle won't make driving a car easier.
Now, I think for Linux, your only choice is OpenGL as an API, and use any of the many wrappers, 3D programming frameworks, and what not available.
Maybe you can go into an easier language, like Python, and if there are OpenGL bindings (which I am pretty sure there is) you can use that, that would make the learning curve more easy and fast.
Update:
Today I wouldn't recommand Ogre3D for a lot of reasons (including very poor long-term interface, which defeat the purpose of a dependency for long term usage - although it does have nice performance sinc v2.1).
There is currently a lot of other alternatives which work well on Linux.
Ogre, using OpenGL on Linux-based OSes, will save your life and time, compared to using OpenGL that is your sole alternative.
That said, to use Ogre, you'll have to know a fair amount of knowledge and practice in C++.
And you will have to know about "graphic pipeline".
You can use C with OpenGL, that seem simpler, but it make you loos time by not providing higher abstraction of the graphic pipeline as Ogre does.
And almost all graphic engines are written in C++ anyway.
Now, if you try to learn C++, take a good book like "Accelerated C++", take a deep and long breath and please forget all you learnt about php before. Be humble in your search for knowledge and you'll get it faster.
You'll be interested in:
OpenGL (obviously)
Box2D (a 2D physics engine)
SDL (a portable media library)
You can find basic tutorials for them on the web. However, think if you really want to code in C++. The language is very powerful, but not easy to learn, and really hard to master. Wouldn't it be better to use a rapid development language like Python with PyGame?
Don't get me wrong -- I love C++ and it's my language of choice, but unless you're working on top-notch performance, operating systems or compilers, it may be overkill to learn C++'s up and downsides the hard way.
You need neither 3D graphics or a physics engine for this. The UI could even be done in a browser using some funky javascript.
However, the audio engine for something like this is going to be a pretty complex, performance-oriented beast, and is probably best done in C++ (or maybe OpenCL).
Finally, are you sure you're not reinventing Pure Data?
I prefer Irrlicht as a lighter, easier-to-learn, but less feature-complete API than OGRE.
It's literally possible to write a prototype in a few minutes in Irrlicht, and the code itself is easier to understand.
The best thing about it is that it would interface seamlessly with Irrklang, a sound library that may help you with your project.
I have an opportunity to attend Sony licensed training classes to learn about programming with the PS3's cell architecture.
However I only have a rudimentary knowledge of C++ and was wondering if the PS3 is a bit of an overkill for a starter aspiring game dev like me.
And also what is the best resources to get me to a decent level in C++ graphics programming in about 2 months time?
I bet it will be fun and whatever you learn in the course will help you become a better programmer.
Finally a question about my day job.... :)
A lot of what you learn about PS3 will be applicable to other architectures, as parallel programming is starting to look like the future. A lot of the parallel techniques used on PS3 are directly applicable on Xbox 360. I suspect a lot of the future game consoles will be going in the same direction, and we'll all need to start thinking about parallelization a lot more than we may currently.
That said, if you have only a rudimentary knowledge of C++, a lot of the material may be over your head. It depends on what you want to get out of the session I suppose. Are you looking for an intro to PS3, or were you hoping to be able to start making games in PS3 Linux the day after the conference?
Assuming you can afford it, the info will be interesting and probably helpful. I wouldn't pass up an opportunity like this unless you feel the cost outweighs the benefits. (I'm assuming there's a cost, I don't really know.)
Game programming resources are all over the net. If you want to do a crash course in C++ I'd pick up C++ Primer by Lippman et al. If you want a crash course in graphics then Real Time Rendering is the best starting place, along with a good book on math like Eric Lengyel's Mathematics for 3D Game Programming. Dig through some OpenGL or D3D tutorials as well; even if neither is commonly used on PS3 the principles are the same as any API.
The problem isn't so much that a PS3 is overkill, it's that the Cell processor is notoriously difficult to program to it's potential. The highly parallelized architecture is potentially quite powerful, but it's not easy to actually get that performance.
I think it's a great architecture to prepare for the future (multi-core programming). However, for most practical purposes you are actually better off learning windows-based game development since startup costs with consoles are much higher. For example, it would be much easier to start coding for DirectX.
So yes, in some ways you're seeking trouble. If you do decide to go with the PS3, make sure to check out the MIT PS3 course.
No not at all, it's just going to be harder if your use .NET as your primary language. If you want to use .NET I would recommend C#/XNA for the XBOX 360.
Edit:
Here is a great link to get you started: http://www.cag.csail.mit.edu/ps3/
I think if you have the opportunity to attend vs doing nothing at all you should definitely go for it. The payoff from learning something from someone that knows more than you is a gift that a lot do not have. The fact that it's from a licensed trainer makes it all the more worthwhile.
He's specifically talking about LEARNING C++ while learning the PS3 architecture, libraries, special tricks, etc. I would not suggest doing that. You need to be strong in your C++ kung fu to code well on the PS3 and you will make a huge fool of yourself if you show up and don't even know the language.
Worst off you will be wasting professional developer's time. They could actually use the info but you'll be eating up time with newbie questions you should already know.
I'm not trying to be mean; I wouldn't go either because I don't know C++ very well. Just try to be considerate of the other people that payed to go there.
I've been teaching myself Cell processor programming (in C) for the last couple of months. It is definitely not the best place to start, since successfully programming the Cell requires mastering a lot of skills: C/C++, pthreads, libspe, the various types of communication on the cell (DMA, Mailboxes, Signals, Interrupts, Atomic I/O). To make this harder, the documentation for the Cell can be cryptic, hard to find, and wrong. If you use a more common platform (XNA, pyGame, SDL), there will be a much larger community of users. That is not to say that there isn't any community of users for the Cell, just that it is smaller. And even though there are other environments where one might find multi-processor programming, it can be difficult to translate techniques for these environments to the cell, due to its unique architecture. Also, using a standard PS3 with linux won't allow you to access the graphics hardware.
But it's not all bad. Learning the PS3/Cell will teach you a lot about programming close to the machine. You really don't have any choice, as there are not very many abstractions available to the programmer. Each SPU on the Cell has 256KB of local memory and if you need more than that, then you will need to figure out some sort of scheme to issue the correct DMA requests to bring the right values into memory at the right time and (hopefully) keep the SPU busy doing something while that DMA request is in flight. Learning the Cell
So, maybe not the best platform for learning, but given that you have the opportunity to take classes from Sony, this sounds like a good opportunity.
In any case, if you are interested, the book from Scarpino is a great reference, and has a couple of chapters about game programming on the cell with the OGRE engine, which might also be interesting to you.
Although I have no experience developing applications on the 360 or the PS3, I have done a lot of research into the various merits of the two platforms. I have used C++ for a long time now, and even though I've built several MFC and BeOS applications with it, I've build a number of UNIX server applications with it, and still the console game environment is significantly different.
The PS3's Cell chip is really quite a beast to tame, as others have said here, and takes a Carmack-level of talent to properly utilize. That being said, there's nothing wrong with attending a course if it's free, especially if you get to meet people that have developed games before and could give you some advice.
If you want to develop games for a console, the best bet for someone with only a rudimentary knowledge of C++ is to use the C#-based XNA kit for the Xbox 360. If you're familiar with the way C++ works, C# isn't that hard to pick up. In fact, I'd argue it's a much smaller learning curve than to make the jump to multi-core, multi-thread Cell-based programming. If you've never developed kernel-level applications before, you should steer clear of that sort of thing until you're ready. Two months is not enough time.
There are a number of points that make the XNA platform very compelling for aspiring console developers, not the least of which is the relative safety of C# vs. C++, and the fact that XNA games can be sold through the Microsoft marketplace.
I don't know of many PS3 games that have been developed single-handedly, but there are a few examples on the 360 such as Braid that are pretty much solo efforts. The XNA examples are also quite interesting and educational.
As a hobby project I am trying to create a ROM (Diku-Merc based) derivative. (Now defunct) I would appreciate it if anybody has done something similar and has some useful resources to share or tips to offer. I'm finding that a lot the resources such as mailing lists are no longer active and many links are dead.
I've picked ROM because that is what I am familiar as a player, but the source is more complicated than anything I have come across and I wouldn't mind picking a code base that was easier to understand. Any recommendations before I dive in in earnest would also be appreciated.
As for mudding communities in general I don't know of much beyond the mud connector because I've always been in more of a user/player role than developer. A forgiving and active place where I can get answers to my questions is what I value most.
After extensive research I've decided to go with a tba code base. I may elaborate later but very broadly
Coding experience is more important than experience as a player and this has convinced me to abandon my roots. I wanted a well documented, reasonably modern, managable code base undergoing active development and this seems to fit the bill.
Anyways muds are truly a labour of love and you have to have a few screws loose if you plan to run one. Moreover the glory days have passed (it seems like there many muds shut down en masse around 2000) and in my opinion the community is largely inactive and fragmented. An exerpt from from some of the tba docs sums this up nicely:
So, you're sure you want to run your own MUD? If you're already an
old hand at playing MUDs and you've
decided you want to start one of your
own, here is our advice: sleep on it,
try several other MUDs first. Work
your way up to an admin position and
see what running a MUD is really
about. It is not all fun and games.
You actually have to deal with people,
you have to babysit the players, and
be constantly nagged about things you
need to do or change. Running a MUD is
extremely time consuming if you do it
well, if you are not going to do it
well then don't bother. Just playing
MUDs is masochistic enough, isn't
it? Or are you trying to shave that
extra point off your GPA, jump down
that one last notch on your next job
evaluation, or get rid of that pesky
Significant Other for good? If you
think silly distractions like having
friends and seeing daylight are
preventing you from realizing your
full potential in the MUD world, being
a MUD Administrator is the job for
you.
Anyways I don't have any high hopes for success, but this is something I will find interesting, improve my code-fu and will keep me busy for many years to come :D
There is no active ROM developer mailing list, so tba definitely is a better choice. There was some effort to clean up ROM with the RaM project.
Dead Souls sees active development as well (the main dev is a hero in my eyes for the amount of work he produces).
I would not recommend MUCK as the userbase is rather small. However that is not to say there isn't good work being done -- look up the user Valente on the code subforum of the wora.netlosers.com forum, as he's probably one of the foremost MUCK developers at the moment.
However if you thought that ROM was complicated I should caution you about tackling an established/canon codebase for any purpose other than getting a familiarity with mud servers. For actual development you may be better off with a barebones codebase such as NakedMUD (C/Python) or even something slimmer than that such as Socketmud (ports in many languages).
There are of course dozens of mud servers you can look at; all will be educational in some manner, but in the beginning stages it won't be obvious what is good practice and what is not. You may want to look up ColdC (similar to LP) and TeensyMUD (Ruby) to study. The author of Teensy, Jon Lambert, has a useful developer site up at http://sourcery.dyndns.org/.
However you'll find very experienced ROM and tba (i.e., Circle) developers at MudBytes, and I'll second Sam to say that is the most active mud developer site currently. It's a little surprising but in the last year there has been a significant growth in activity at MB. I think people are coming in from the fold so to speak and gathering at MB. There also is a good-sized code repository at MB as well.
Your other options are The Mudconnector which you already know, Top Mud Sites which has a somewhat smaller crowd of mostly developers (typically of established and long-running muds), and Mudlab, which is much quieter but usually with a good signal to noise ratio. MudGamers is an interesting new site with a fairly quiet forum, but a new approach to creating a more contemporary-looking portal for playing muds.
Not to be overlooked is the archive for the old mud-dev mailing list. There is a staggering amount of information to be gleaned there. The raw archive can be found at muddev.wishes.net/. Richard Tew also has done some noble work in combing through old usenet archives to find valuable mud development related threads, which you can find through his mud tag at posted-stuff.blogspot.com/search/label/mud.
I should note that many muds use the IMC chat network to link muds (MB has a portal to this as well on the front page of their site). Once your mud is running it can be useful to get on IMC if you're in need of real-time chat to fix a problem (of course, there are many IMC channels and you'll want to choose which one you use prudently).
Despite the fact that muds today are niche at best and unheard of at worst, there is no shortage of new muds in development. They offer a design and programming challenge that is still accessible to the solo developer, unlike any graphical game of equal size or complexity.
Furthermore you shouldn't be discouraged if it feels like you'll never release a playable game. Like many larger projects you may start and abandon it many times over, but you'll be building proficiencies across a wide spectrum of programming skillsets and applications -- not many projects will allow you to take such a whole systems approach. Good luck!
An active community seems to be around for the Dead Souls MUDlib
http://en.wikipedia.org/wiki/Dead_Souls_MUDlib
I was an old player of Nightmare LPMud which sadly disappeared. I'm not much in for the coding of these MUDs, but I have been following this community loosely just due to so many positive MUDding memories.
Take a look at Nameless MUCK. It's a solid piece of software.
First concentrate on getting or finding a solid Telnet Socket library going, this is generally the main protocol for a MUD.
Next, create a FULL list of features that you want to implement, you should probably get some sort of feature or bug tracking system setup (even if it is a spreadsheet). Then prioritize the features based on dependencies of other systems.
Check out http://www.gamasutra.com for some architectural discussions on creating games in general, creating basic AI, character systems, and multi-player games.
Once you understand the theory, it is just a butt load of programming to build in everything you want to support.
I'd make the MUD engine abstract enough to run behind both a terminal client, a web-based Ajax client, and maybe stand-alone clients - i.e., don't tie the front end in with the actual game logic. I'm not averse to a MUD actually using a decent font for the text, and real graphics (as interstitials or to make notes on the bulletin board look like notes, etc), not in place of the text based interface) where necessary instead of ASCII, etc.
You might also want to have some MUD script file converters into your own format, so that you don't have to spend ages creating zones.
I find the problem with MUDs is that there is too much emphasis on killing NPCs, and not many puzzles or other interesting aspects. So a more interesting, story-oriented (possibly to the extend of sharding zones for single-player or single-team use) engine could be a nice feature to have.
I will take this opportunity to recommend MudBytes, which is probably the most active MUD developer site available right now.