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.
Related
my robotics lab is looking for programmers to work on some projects we have at the moment.
We nailed down the requirements (mainly, c++ and experience with openGL and 3D), but due to obvious money constraints we can't afford to hire Great Developers. Instead we're going to settle for Talented Students, offering them projects for their dissertation/thesis and hoping for some fresh ideas and creativity from their side. We can also afford to pay students that just graduated (first job experience).
So my question is:
In your experience, how did you spot a Talented Student (computer scientist or engineer)? What questions did you ask? What else did help you in finding a candidate that turned out to be a Good Programmer? (note: they might not know much about a specific language, but might have the ability to learn pretty fast)
or, if you were the interviewee,
Which questions were asked that made you jump on the bandwagon? Or, if you had an awful experience, what - in retrospect - was an obvious warning signal that you ignored?
Please note that I am not looking for an argumentative answer. We can talk all day long about what's best for us and never agree.
Instead, I'm looking for tales from your experience. Anecdotes, stories, hints, everything will help.
Background:
A bit more background: working for academia here is slightly different than working for the private sector (here = Italy). There are no 'deadlines' to 'sell' a product; instead, it's all proof-of-concept based. Nothing you start working on has the guarantee to be functional.
A comic best describes it: reinventing the wheel
I am considering doing Coding Questions for their interview, but all my colleagues are scoffing at me (too scary, nobody will ever come to work for us again, nobody really know how to code, etc).
Coding-wise, programming done by researchers is ... ugly. I am fighting to get a version control system in constant use, people have to be chased down to report bugs and document their code, everything is coded-so-that-it-works and rarely we go back to old code to 'fix bugs'. Basically once it's somewhat working, the project is closed and people go work on another project.
Lots has been reinvented and rewritten over and over again (just because nobody knew it was already there). People come and go, future is uncertain, but we play with robots so it's very cool :)
Furthermore, being really understaffed, nobody can follow you and guide you in your project. At best you're the one that has to come up with a plan, background literature and a working prototype.
Hence, we are looking for people that:
have some background to get started
can be highly independent
do want to learn and build their own expertise in new fields
Actually, here's my best advice:
Recruit among your students.
Since you work for an academic institution I assume that either you or your colleagues teach. This provides you with a wealth of information about what potential recruits are capable of -- how fast they learn, how motivated they are, what they are good and bad at, how the code they turn in for the lab assignments and projects look like, etc.
Firstly, in industry, coding questions are very much the norm - I'd be worried if coding questions weren't asked!
I've been responsible for doing technical interviews for about ten years now. And yes, I ask coding questions. But the questions themselves aren't really the point. What I'm more interested in is getting an idea of whether the candidate can think, and articulate their thoughts.
One question I ask (asuming the simple earlier stuff has gone well) is about inheritance heirachies. There is no one right answer, although there are a lot of wrong ones. But what's important is how they approach the question, the points they come up with in favour of one design over another.
Background knowledge is useful, in that it shows that they have an interest in the area in which you're working - but really knowledge can be gained. Intelligence is much more important.
However it's quite possible to have intelligent people who are impossible to work with! I haven't figured out how to determine who they are.
I have done such a project when I was a student: ie a 4-months project, working half-time. It was not about robots, per se.
I think that the most obvious requirement is motivation/passion. Since they'll be mostly on their own you will need them to be somewhat independent and able to think for themselves, this requires motivation first and foremost.
In order to determine whether the candidate is motivated or not, begin by asking them about the project itself. If they only gave it a cursory glance, they're likely not motivated. Also look at their experience / courses: optional courses in CS, projects they've done, etc... anything indicating that they really care about CS / development in general and are not there just because they've heard it paid well.
Then comes the question of ability. Like you said it might not be easy to spot those who will be smart enough to figure stuff out by themselves and DO things. Once again, you can ask them about past projects, having them detail the issues they faced and how they solved it.
Finally, I agree with you that some demonstration of their abilities is in order. They might be a bit tense initially, so I would do this at the end, once the interview is already going, you might have had a chance to get them to relax with the previous questions this way.
You don't necessarily need them to do coding questions, I think it's most about reasoning. Try to pick problems related to your area work, for example one you really had in the past, and get them to analyze the problem. If possible they should take the lead and ask you questions about the problem itself here.
We've had an issue with the robot not being able to analyze the images the camera took, it could not correctly determine the moving objects itself, do you have an idea how you would do that ?
Then you'll need to get them to think about a solution. You need a whiteboard here, and ask them to think aloud so that you can follow their reflexion. You'll probably need to nudge them a bit from time to time to keep them on track, their reaction to your input is also a key-point here, since you want them to be able to accept criticism and build on it, otherwise you might have issues directing them afterward.
Frankly, try to avoid asking them for the quicksort algorithm, or the introsort, or the radix sort... If they need sorting, they'll just fire up their computer and browse the internet. On the other hand, getting them to analyze an existing algorithm unknown to them (for example, the median of 5 sort) and checking that they understand why it works, could be worth it. If they need to work on their own, they'll need to be able to learn on their own too :)
As others say, try to hire someone that's motivated!
For master thesis students I put more emphasis on knowing the basic skills (programming, knowing how to use version control) as they don't stay on long enough to learn everything along the way.
If they're going to work mostly on their own and you have no special requirements on language I wouldn't focus much on language questions. But every decent programmer knows at least one language fairly well, get a sample or their prior work or make them code some simple application to test that they don't suck.
I'd focus more on algorithm and data structures. Ask rudimentary stuff that every programmer should know - when to use a list and when to use a vector, why summing a row-major matrix by iterating over the columns first is bad, basic complexity analysis questions, etc. That will sort out many of the bad weeds.
Ask some design questions too perhaps, e.g. what is "coupling" and why is it bad, ask them if they know what a design pattern is, etc.
Check that the applicants have a solid grasp of linear algebra and coordinate system changes in particular if they're going to work with any 3D stuff like OpenGL. In my experience, learning the API is simple, wrapping your head around how the transformations work less so.
Obviously, if you except them to perform any real robotics-specific you should check for that knowledge as well. E.g. estimation (understanding simple EKF and particle filters is a requirement in my book), control theory, pattern recognition, machine learning, vision, or whatever is useful for the particular task.
If I were hiring someone for theoretical work I would perhaps loosen up on the CS/programming skills and focus more on math knowledge. Someone with solid math skills will pick up the CS easily, and programming is just programming.
Ask for references or to see some of the prior work. Many great students already have some interesting project to show after graduation.
I'm not sure how common this is at universities in general, but I would look for a games programming (or robotics) course on the transcript where the candidate, as a student, succeeded in completing a project with a team. It would ask the candidate to describe how that project worked (important technical details) and the role he had in the team. The only way to really tell if someone is good at something is to see what happens when they try it, and since you're in academia, recruiting students, that should not be a problem.
Like many people here, I started my programming experience with the good ol' green screen BASIC that you get when you booted an Apple II without a disk. I taught myself C++ in my teens, and even took a class on it in college, but as soon as I discovered .NET and C#, I dropped C++ like a bad habit. Now, (many) years later, I'm interested in getting back into C++ development - thank the iPhone for that - and I have to admit, I feel a little daunted. Having to deal with pointers, ATL, macros, etc. seems a bit overwhelming at times when you've been in managed .NET land for a long time.
What are some good resources or weekend type projects I could do to ease me back into C++? I'm not interested in debating the relative merits between platforms, stacks, but I would be interested in hearing about objective comparisons between different development platforms, although keep in mind I'm a Windows guy.
If anyone wants to change the tags around, feel free - I wasn't quite sure how to tag this.
TIA!
Try Euler Project
Project Euler is a series of
challenging mathematical/computer
programming problems that will require
more than just mathematical insights
to solve. Although mathematics will
help you arrive at elegant and
efficient methods, the use of a
computer and programming skills will
be required to solve most problems.
I had this problem a while back, I chose to find a cool open source project.
I chose Chromium.
It was really interesting, and all C++
They have a vast number of small bugs which can be fun to fix, I ended up fixing about 4 in a few evenings/weekends. Check it out (pun intended)
You don't need to leave .NET to program for the iPhone, unless you want to...
http://arstechnica.com/open-source/news/2009/01/open-source-mono-framework-brings-c-to-iphone-and-wii.ars
If you're into the iPhone, grab the openGL demo for it and get modifying.
It's fun, you can show people and it's kept me busy for the last 3 months.
I'm about release my first app.
While Project Euler or related sites are cool, for me they just don't hold my attention very much. I find the best way to start using a new technology (or refreshing an old one) is to find a project that scratches an itch that I am genuinely interested in. This is the only way I can maintain interest while learning something new.
I haven't gotten around to doing this yet, but a friend of mine recommended building an ircbot. for me this doesn't really scratch an itch since I don't use IRC a whole lot and when I do I'm trying to talk to people.
I've thought about modifying his recommendation and instead building a web crawler. Though I'm not sure of the particulars of this sort of project it seems like a good one as it would teach you a lot of libraries at once, it might not exactly scratch an itch though.
How I DO currently get projects to learn a language is make a game. The game dev club at my school is small and holds periodic challenges for individuals/small groups to make a certain genre of game. This works for me, as it's somewhat competitive.
I would definitely recommend finding such a group, even if you're not going to school any more, a school dev club is always eager to have a professional around. And depending on the area you're in there are also groups that are not associated with any school.
Ok lets start off with info about myself.... that way there is no stone unturned.
I am a adult, 27 years old. so this isnt a joke or a passing fad. Im into computers, how they work and how apps and games are designed from the ground up and made.
I have ZERO programming back ground. I went to college for the wrong thing. I love video games since i was a child and should have went that route.
I just picked up a book called C++ without fear. i already have went thru the first 3 chapters and im not having an issue yet on self teaching myself this subject.... yet... lol.
I have a few game ideas written and drawn out on about 3000 pages. i took one of my games to a few website developers and the cheapest offer i received to make the game was 16k and 3 months time. Now im not now super duper genius or a brilliant mind kind of guy.... but come on... 16k? i figured... ok time to teach myself how to make these games.. and yea it might take 2 to 4 years but at least i will learn how to code myself and never ever have to pay for this kind of service.
So i asked around at what i should learn and i was told C++ was a nice starting point.... Is this correct?
2... 2 of the games i have written down and played with all the math issues are kinda in this games fashion. www.goallineblitz.com. if someone here could sign up and look that game over and let me know what tools you would need as a coder to make a game in that style... i would thank you greatly for the info.
Where else do i go from here? what would you do and plan out?
I know a have a huge mountain in front of me. and i look foward to every step, stumble, fall and bloodied knee i will endure during this venture...
=)
thanks in advance!
I wish you the best of luck, but you have to realize you're the 1238471920847th person in this exact situation, of which approximately 3 manage to figure out what they're doing. there are even previous questions like this on stackoverflow. The most useful answer is "reconsider whether you're interested in coding or game-design -- the two are not equivalent"
Also, you have to realize 16k is an unreasonable number. Not because it's high, but because it's low. Consider Braid for an example of an "indie" game that was pretty successful. It cost $200k, and the developer started off already knowing what he was doing.
There is so much to learn, you would be surprised.
What I think you should do is find a bright young web developer who's interested in investing some time into a business startup for a certain % of share of the business. You can contribute the intellectual property of the game and the creative direction. I imagine this would let you get up and running for significantly less than $5k including incorporation fees, web site costs (minimal), trademarks, etc. You could save money by doing the business stuff yourself, and by your partner doing the programming himself.
It's win-win. You get your game built, and the developer gets a lot of great experience for their resume (and a share of any profits).
I think you've got a very low estimate of how much work is involved, frankly. Going from a spec to a finished web product in 3 months sounds quite good to me, counting things like quality assurance (a very important thing here) and graphics and sound, and $16K also sounds very good for three months' work. (Seriously, this is $64K a year, as a contractor, assuming only one person. Anybody who can do this sort of thing can make more money than that.)
That being said, doing it yourself will teach you a whole lot. Just don't count it as a likely source of income.
If you're interested in web-based games, you will need to become familiar with more than C++. At a minimum, you'll need to know web design and Javascript. This strikes me as a lot to bite off at one time, so I'd suggest starting with a simple screen-based game, and learning about the web stuff when you're confident of the basic game programming. (Don't just write the game you want on the screen and then think you'll just port it to the web; write to get some familiarity with C++ game programming, learn the web stuff, and design your game based on that.)
This sounds like a good way to learn programming, but don't get your hopes up too high. That's going to be a loooong road.
Also, I agree that C++ is probably not the right language to do this. Maybe you should start to learn programming with a smaller, less ambitioned project first and use a more beginner-accessible language.
A turn-based strategy game is basically a business application with a glossy front-end.
I'd recommend SQL Server for data storage and rules engine. You're going to have to learn how to model a database. I don't want to shit on your hopes, but the other guys are right: you've got a long road ahead of you. Here's some help to get started:
An introduction to turn-based gaming and what it means
Source code for a turn-based war game you can browse and modify
The Torque 2D gaming engine
I wrote the beginnings of a turn-based space combat/strategy game in MSAccess(!) over a decade ago (ugh I just did the math and it's been almost 20 years actually) that I never finished. Here's hoping you get farther than I did. Good luck!
Java, Flash, PHP, ASP.NET, all are languages that are commonly used to implement web-based games.
You're also going to need to introduce yourself to SQL most likely, since data will have to be stored in some manner.
First, I'm gonna answer your technical question.
You will need 3 things.
1- Display things in the user's browser so that he can use your application. This means using languages best suited for programming. Most likely PHP (or its Microsoft equivalent : ASP.NET, less used, and requires more expensive tools) or maybe Flash. There are others, less used options, but that's beside the point.
2- A database, to store your data. The language here will be SQL, and you will probably start with a free open-source database. Most people choose MySQL in this case.
3- An engine to do something with the data you have in your database and the input of your user. Here, since you don't know anything about programming, the easy way is to use the same language you used for your GUI : PHP/ASP.NET. Later on, if you manage to be a code guru and need some performance improvement, you may try something more powerful like Java or C++, but then you will have to interface your PHP front-end with your C++ back-end which is gonna be tricky.
Now here is why i think you're going to fail :
All i said means that, at the very least, you need to learn basic programming concepts, 2 languages (PHP + SQL), and all the associated tools (MySQL, an IDE for PHP, ...). Moreover, you will also have to learn how to set up, configure and use a web server. That's quite a daunting task to do all this by yourself in a few months or even in two years.
Actually what worries me the most, is that you say you have no programming background. This means you don't even know whether or not you will like to do this kind of thing. Programming can be quite frustrating and many people hates it. You should start by building small apps as a hobby, and see whether this is the kind of job (because yes it's a job, that requires skills) that you would like to do. Only then you will be able to think about making this your line of business.
If you want to make web-based games C++ is probably the wrong language. You should look into PHP, SQL database programming, and Perl.
Welcome to the world of programming. It's lots of fun but takes a while to learn.
My advice: start small. Really small. There are a lot of basics you need. C++ may actually be a good way to get the basics down solidly, though you won't likely be using it for your final web product (see other answers for web language options). As you go through examples, think of small parts of your project that you could do with what you know, even if it's just choosing a name and displaying it, or adding up a score. Processing.org is a fun language-- again not what you'll need in the end, but it's aimed towards beginners and lets you get into graphics right away (which is fun, though probably won't be your main focus with this game).
Bonus advice: if you want to make money off this or become a professional game developer, don't release your best ideas on the web right away. My husband created a really innovative game in college, which became somewhat popular on a java game site. A few years later an almost exact clone was released for the Playstation. The Playstation developers weren't ripping him off directly, it turned out the idea had spread widely. While in some ways that was really cool, if you want money or credit as a game designer obviously that's not going to be what you want.
You could approach this from another direction. Instead of implementing these large designs you have in mind, aim at starting with a Facebook app instead. That way you can get some very small ideas implemented. If you try to do something large first, you'll end up in a tar pit.
Be careful of large game designs. Get good at implementing small ones first. You can always build on top of them.
C++ is a good language for learning how to program computers; however, for the specific task of programming turn based web games, C++ is probably not the tool you will want to use for that task. You may want to continue learning the C++, to get a grip on the underlying programming; it may take a while, though. You may also want to look into other programming languages for implementing your games on the web; PHP is good for scripting. C# has a lot of similarity to C++, and has good integration with Microsoft's web servers; ASP.NET is pretty easy to comprehend, as well. You should do the research into each of them concurrently with learning the C++ to figure out which one seems like it's going to give you what you need.
Others have already said this, but PHP is going to be the best starting place for you. For a turn based, web based game I would say use PHP and mySql for sure. After coding much of your game using PHP, you will have a good enough understanding to start moving to other languages if you so desire.
Setup an apache server with php support, and a mysql server (they can easily run from your own machine). Then just start playing with the code. Look at other examples, modify them, mix them, learn.
You can find lots of free tutorials on both php and sql on line.
I started learning C++ fairly recently, also with "Without Fear". The best thing you can do once you have the basics is dive into a simple project, but REALLY simple (like tic-tac-toe).
I don't think you should be learning to program just for this one idea of yours. Learn to program for the fun of it, see how you get on, see what floats your boat. A year from now, think again about your project, whether it seems feasible, whether you want to do it, how you want to do it. But don't think about it till then, because all you'll be able to think about is how you don't seem to be getting any closer to having thousands of customers lining up.
Just keep on coding, and you'll get where you want to be. Where you want to be may not be where you think you want to be now though! Good luck.
It may be of no use to you but http://archverse.sourceforge.net/ is an open source C++ turn based web game. Its not finished but all the basics are there and it actually does quite a lot (though it has no client just a server with unit tests right now). Its BSD licensed so you're welcome to do what you want with it aside from claim you wrote it from scratch.
Contrary to suggestions from others here im not a fan of RDBMS for semi real time games so I'm using BerkeleyDB as a data store it allows me to have ACID and still be massively faster since I never search on anything but a key field and everything is in process. Don't really want to start a flat file vs rdbms flame war but the non open source project this is related to used MySQL and paid for it quite painfully.
The learning curve for C++ can be tricky for beginners. If you can get through the chapters on references and pointers without severe mental damage, you'll probably be fine. Otherwise, you may want to pick up something a bit higher level to start out with. As others have stated, C++ is a great programming language for game development, but it's not particularly suited for web-based applications.
Regardless of your language of choice, there's only so much you can learn from books. Programming skill is very much dependent on experience -- program, program well, and program always.
At some point, you'll probably want to study up on object-oriented analysis and design. If your games have any significant degree of complexity to them, the ability to break them down into easily manageable chunks is invaluable.
Check out gamedev.net, they have a number of resources for game developers.
Game development involves a lot of different aspects other than the programming itself. Depending on the game, you'd also have to worry about sound, music, graphics, animation, user interface, play balancing, story, dialogue, and database design. All of which has to work on a variety of hardware and software configurations. Oh yeah, and it probably has to be fun as well.
Start small.
Good luck.
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.
Last term (August - December 2008) me and some class mates wrote an application in C++. Nothing spectacular, it is an ORM for Sqlite3. We implemented some stuff like reflection to make it work and release the end user from the ugly stuff. Personally, i think we made a nice job, and that our ORM could actually be useful for someone (even though its writen specifically for Sqlite3, its easily adaptable for oter databases).
Consequently, i`ve come to the conclusion that it should be published somewhere (sourceforge most likely) as an open source project. But, as it was a term project, there are some things that need to be addresesed before doing that. Namely, it has some memory leaks that should be fixed, and some parts of the code could be refactored to make everyone´s life easier in the future.
I would like to know more experienced C++ programmers opinion on some issues:
Is it worth rewriting some parts to
apply new techonologies (for example,
boost).
Should our ORM be adapted to latest
C++ standard? Is there any benefit in
doing this?
How will we know when our code is
ready for release?
What are the chances that this ORM
will be forgotten into the mists of
the internet? (i.e is it worth
publishing it beyond personal pride
as a programmer?)
Right now i can`t think of many more questions, but i would like to read on similar experiences.
EDIT: I should probably translate my code + comments to english right? (self question)
Thanks in advance.
I guess I am "more experienced" with regard to your particular question. I co-developed an open source web application language & template system a lot like ColdFusion back in the early days of web design before Java or ASP were around. You can still see it at http://www.steelblue.com/ if you are interested. It's still used at the company I was at when it was developed, but I don't think anywhere else.
What I found is that unless you are already well connected and people are watching what you are doing, getting people to use your open source code is just about as hard as selling somone your closed source program. You really need to advocate for your project and it should have some kind of unique selling proposition that distinguishes it from the compitition.
So, that's the unsolicited advice. Here are some specific answers to the questions you had...all purely my opinion, of course.
I wouldn't rewrite any code unless you have a featuer you want to put in. That feature might be compatibility with a specific platforms or compilers. It might be to support a new db datatype or smarter indicies or whatever. If you are going to put some more serious work into the applicaiton, think about a roadmap of what you can realistically accomplish in the next iteration and what choices will make the app the "most better" at the end of your cycle.
Release the code as soon as it is usable for a specific purpose, any purpose. Two reasons. First off, there might be someone who wants it for that purpose right now. If it's not available, they will use something else. Also, if it's open source, they might contribute back to the project. Second, the sooner you find out how much people want to use the code, the better. Either it will be more popular than you expect and you can get excited about continuing the development....or....you will find that no one is even visiting your web page to see what you've got. In either case, better to know sooner than later what people really want from your project so you can take that into account when planning new releases.
About the "forgotten into the mists." I think most projects are. I don't want to be a downer, but looking at Wikipedia, there were 5 C++ ORM tools popular enough to get mention and they were all open source. As I said above, unless you can sell your idea to people, they are going to go with another proven open source solution. For someone to choose you over them, three things have to happen: 1. They need a feature you have that the others don't. 2. They find your project web site and it demonstrates the superiority of your code. 3. They trust your code enough to give it a shot.
On the other hand, if you are in this for the long haul and want to continue development thigns get easier over time. Eventually the project will get all the basics covered and you can start developing those new featuers that aren't in the other solutions. Also, the longer you are in active development the more trustworthy the project will seem. Finally, you will get more experience in the nitch. 2 years from now you will be better positioned to say where your effort will have the most impact on bettering the project.
A final thought: If you are enjoying it, learning from it, and it's not getting in the way of you keeping food on the table, it's a good use of your time.
Good luck!
-Al
Regarding the open source part:
If you really want to make it an open source project, you really should publish it regardless of it's current state - fully working and debugged - or half working and full of memory leaks.
Just, if it's state is bad, make sure to document it, and give it a suitable version number (less than one?). then others may view your code, suggest improving, join your team, etc...
My--rather random--thoughts on the matter (in the order I think is most important):
How will we know when our code is ready for release?
Like Liran Orevi said: if you're going open source release early. Document it reasonable well, and take the time to provide a road map of planned or hoped for future improvements (these are a invitation for people to help you, so note which ones have no one working on them).
Is it worth rewriting some parts to apply new technologies (for example, boost).
Should our ORM be adapted to latest C++ standard? Is there any benefit in doing this?
SQLite relies on a fairly limited base. Maybe you don't want your tool to demand a much heavier environment. If the code in not currently a tangled and unmaintainable mess, you might want to avoid boost and newest frills. Once you have a stable release (1.0 at least) you can starting thinking about the improvements that can be made for version 2.
What are the chances that this ORM will be forgotten into the mists of the internet? (i.e is it worth publishing it beyond personal pride as a programmer?)
Most things end up in the big /dev/null in the sky, and there is only one way to find out... If it goes anywhere at all, you win. If it doesn't it was a modest investment, and maybe you learned something while you were at it.