|
Gotta be honest with you... you are almost certainly never going to get a serious job writing AI in C#/VB/Java, probably not in C++ and likely not even in C. This kind of thing is usually done at the assembler level for the sake of speed. This is one of the reasons the games industry is so hard to get into.
C#, for several years at least, will probably largely be used in Rapid Application Development environments. This is where customers come in with a specific idea in mind and you need to develop it quickly.
It will probably come in big in network transmission and internet programming as well.
You'll certainly be able to write a nice game in C# and when the DirectX Development Kit comes out, that will become even more true. But I don't see the games industry being even remotely interested.
Sorry to be a pessimist and all that, but I think you might be a bit hopeful. Certainly use C# as a way to learn programming, certainly expect to be able to get a job in it if you're any good (or from some of the programmers I've worked with, even if you're not ) but don't expect to learn programming in 5 weeks and be able to move into a job writing AI.
Paul
|
|
|
|
|
The short answer is yes, get C# standard and learn C# in preference to C++. Arm yourself with a good book on object orientation, then a second dedicated to UML. Then you can decide where you want to go next.
If you want to write true AI (neural nets etc) then you want to use a dedicated language. Look around, do your research, you may even find a language that has a version which can run on .NET framework. Who knows, it might even run in the IDE!
I'm writing an exceptionally ambitious AI designed to analyze human actions, pinpointing weaknesses in their skill levels, coordination etc.. I'll have to leave you to guess exactly what it is! The current state of AI development for games is exceptionally weak so you are entering a market where, if you have the maths, you could do well.
For low level AI I have to recommend C# because it has less overhead than C++, is more object oriented than C++, and is much easier to learn. An additional problem with C++ is that it does not, in any way, force you to write object oriented programs. So if you are starting out you can pick up far too many bad habits with C++. C# is much better suited as a starter language for object oriented thinking.
People argue about the best object oriented language, but for my money the best of breed is either Smalltalk or Eiffel. Search on the web and you can find free downloads for both. Even IBM is giving away a download version of Smalltalk. For prototyping the most productive tool I've ever seen or used in Smalltalk for VisualAge.
I was brought up on C then C++. After Pascal I thought that C was great, and C++ was even better. But now I program in C# I get far more enjoyment out of writing creative code, and I am orders of magnitude more efficient.
C# is not perfect, but it offers a viable compromise between the speed of C++ and the power and purity of Smalltalk or Eiffel. I imagine that like Cobol, C++ is going to linger for a long time, principally in applications where real-time is critical (eg. games) however the writing is very clearly on the wall.
For telecommunications I write in C++ but never use dynamic memory allocation, because we cannot afford any memory leakage whatsoever. We also have several dedicated languages, especially for database manipulation where realtime is critical.
For banking, financials, and models which change on a daily basis (stocks and shares for instance) I prefer to use Smalltalk for VisualAge or similar.
For many business applications I use a work flow package with a nice visual designer, and something like Oracle for database.
But the one I try to avoid is C++ because like assembler it is labor intensive. The mechanisms it provides are also very weak, especially in regard to object orientation, so I find myself relying on infrastructure (code), patterns and templates. None of which are especially friendly to the newcomer like yourself.
Only change is constant
|
|
|
|
|
Alastair Stell wrote:
For low level AI I have to recommend C# because it has less overhead than C++,
WHAT ? You're not aware of the size of the CLR then ?
Alastair Stell wrote:
is more object oriented than C++,
I disagree. Having everything derive from one base class is often clearly dumb. static main is one example of a hack that is needed by making OO a straightjacket.
Alastair Stell wrote:
An additional problem with C++ is that it does not, in any way, force you to write object oriented programs.
No, that is a strength.
Alastair Stell wrote:
if you are starting out you can pick up far too many bad habits with C++.
Only if you do it badly. Once you know how to program, you'll find yourself fighting C# as it conspires to treat you like an idiot.
Alastair Stell wrote:
C# is much better suited as a starter language for object oriented thinking.
I don't get why you think this. For starters, C++ has multiple inheritance, C# does not. C# is not MORE OO, it simply forces it onto you at all times. This is one more reason C++ is more powerful and flexible.
Alastair Stell wrote:
After Pascal I thought that C was great, and C++ was even better. But now I program in C# I get far more enjoyment out of writing creative code, and I am orders of magnitude more efficient.
I can't imagine why. What sort of code do you write ? Did you use C++, or did you use C++ as an OO C ? Because so long as you used C++ style file access, containers, strings, etc., I can't imagine there being much difference except that C++ containers are orders of magnitude nicer than C# ones, which suck in every direction.
Alastair Stell wrote:
But the one I try to avoid is C++ because like assembler it is labor intensive.
I can't begin to express the degree to which I disagree with this. C# is actually more verbose than C++, and as I said, if you use C++ properly, it's rarely that different from C# and certainly not labour intensive.
The one area in which I would agree is writing GUI stuff, but that has a lot to do with the IDE and with MFC, nothing to do with C++ itself.
Christian
Hey, at least Logo had, at it's inception, a mechanical turtle. VB has always lacked even that... - Shog9 04-09-2002
Cats, and most other animals apart from mad cows can write fully functional vb code. - Simon Walton - 6-Aug-2002
|
|
|
|
|
You are welcome to your opinion. I honestly don't know where to start regarding your comments, because what you regard as a virtue I consider a vice, and you no doubt reciprocate the sentiment.
Programmers have argued for years over this kind of topic, and I've never seen anyone persuade anyone! All I can say is that after fourteen years of programming in C++, I found C# to be a breath of fresh air. And at my age I would expect to be resistent to new ideas (I'm 46 tomorrow).
So, rather than disagree with you, I thought I would make a few observations for anyone out there who knows about object orientation, yourself included:
Data has a lifetime. We all know this, and as an analyst I consider data lifetime an important aspect of modelling. However what is not always realized is that data does not die, it simply becomes time-expired. Why is this you ask? Because data is history. If you keep it around and date-expire it, then you can always 'wind back the clock' to see what happened at a particular date and time. It turns out that everyone in the business world likes this sort of thing. Of course we often shunt the data off into shadow database, but it's still there and SQL generators can always recover it.
But data is only a part of the story. Messages between business objects are also a part of history. The sequence in which they flow, their payload, also reflects the history of events.
Which of course leads us to the notion of State. State not only determines what actions an object responds to, it also determines how the object responds. Some people think that State is a simple, ordinal value. Sometimes it is, but that's rare. More often it is a consequence of internal data and external associations. And if you understand all this, you also understand why a method is not the same as a function!
So, all objects, all associations, all methods have implied or actual state, all data and message have an active lifetime, they time expire but they do not truly die.
If this is true in the business world (and I find after twenty four years that it is) then wouldn't it be nice to have a language which models actions and data, state and messaging in this same way? Well, sadly their really isn't. Smalltalk is not bad and can facilitate many of the essential axioms. So too can Java (although I'm not especially fond of the Swing II engine etc). But C++? Yik! It brings nothing to the game except infinte possibilities to succeed... or fail.
C# does not solve all (or indeed many of) the shortcomings of C++, but it is fun to use, simple, and has several embedded object oriented principles such as the Interface pattern and class metadata (reflections etc). You don't have to duplicate your function templates into endless header files, you don't need multiple inheritance ever, not ever at all, and you don't have to worry yourself over endless memory management issues.
For games I imagine that C++ will remain the tool of choice for quite sometime to come, but for anyone in 'experimenting mode' I recommend C#. You can always rewrite the code in C++ because there are patterns in C++ which corrspond closely to the embedded C# mechanisms. But I would be startled if a newcomer could write reliable code, well structure, faster in C++ than in C#.
In the business world I'll try my best to avoid C++ from now on. I can read almost anyone's C# code, no matter how complex, but I've seen case of 34 way multiple inheritance in C++ (telecoms, VOIP) which it took me three months to truly figure out. I don't want to go back there, and I'll gladly cede you that domain.
And no, although we use C++ in telecoms, we always preallocate 100% of worst-case memory requirements because we simply cannot allow any memory leaks. For this reason we cannot use any version of MFC because this library has more holes than a camel has fleas. So we use STL, STL2, ATL etc., and for speed, coding efficiency and some beautiful virtual abstractions of communication protocol layers, we use every technique that C++ offers. Especially, it seems, multiple inheritance.
Only change is constant
|
|
|
|
|
So if you are starting out you can pick up far too many bad habits with C++.
This reminds me of what we were told about becoming blind out of too much masturbation.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
When you are writing games, your audience is the mass consumer. Do you imagine the mass consumer downloading and installing between 20MB and 120MB of MS run-times before being able to run a simple .exe ?
I am afraid that at the very least you'll have to wait the .NET framework, plus all satellites runtimes, is embedded in the OS.
May be offtopic, but never forget that a .NET .exe is not executable code, but IL code. It needs to be compiled before it runs, and this takes 5 seconds usually in the small apps I've written so far.
No need to say that these apps can't be put in the Startup registry key, because it lengthens startup time by 50%.
So it goes with screensavers and so on...
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site. Support for development will ship at the same time as the Windows XP Service Pack 1 (SP1) release.
|
|
|
|
|
5 seconds?!?! My machine must be blessed...
|
|
|
|
|
Some more direct advice if you're starting out. While programming in this country will take a down turn until this recession (or whatever it is) has ended, you can still get work in multimedia stuff. I recommend you get your teeth into Macromedia stuff (you can get a 30 day license on a free download of Studio MX 8.5). You should also take a look at DirectX if you want to go low level. This is essential for game writing (along with OpenGL).
The primary language for game writing is C or C++, but you can experiment in all sorts of languages, even Visual Basic! However until the official release of DirectX 9 SDK for .NET, I suggest you might want to get yourself a copy of C++ from Studio 6 (Standard edition should do I think). In fact if I were writing a game today I would consider Studio 6 ahead of Studio .NET (that comment may raise some controversy!)
I think in the long run that programmer salaries are set to fall a long way. We cannot compete with WiPro in Indian, and coders in China or Thailand. So if you are here in the USA you want to aim to get out of low-level programming as quickly as possible. Analyst, specialist, or something which requires close customer interaction. These domains are more difficult for overseas companies to dominate!
Gaming engines are really powerful and you can download any number of them. Most support C or C++ interfaces, some have their own associated language. Many of them are free (although if you want to use the engine commerically you may have to pay).
And finally, if you're bored, there is Cg from NVIDIA. This is a free download (C for graphics) and I have used this myself. It is fun, insightful if you're starting out, but I doubt it has a long term future (I might be wrong however as gaming is just a hobby for me).
Incidentally, if you check out your bookstore, there are many books on game writing and on AI for games. Personally I would like to find an AI which can adapt to my style of playing. Because I can easily wipe out the enemies at SOFII at the maximum setting, but everytime I go online I die!
Only change is constant
|
|
|
|
|
Vipermmx wrote:
Im REALLY new to all this and want to start programming. I want to start on either C++ or C#. My friends have told me to go for C# as it will be used more often in afew years and its easier to get started on and has good support.
I found by learning C# i pickup on C/C++ to the point where i code easily (not always) read C/C++. Java didnt have this affect on me.
DirectX9 does contains managed functions, but this not managed DX, this is merely a managed wrapper for DX. According to sources, this will have about a 5% preformance overhead.
I would really recommend starting on C# (speaking from own experience, and multiple failed attempts at C++) and then once you have formed a solid base, move on from there. Like said above, dont expect miracles. You will need at least 6 months solid experience in C# before moving on.
Hope this helps
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Thanks all for the helpful advice. I will start out on C# and move on from there. I just need to get my head in the door and understand how programming works. If I get skilled in C# it should be possible to move on to others alot easier then not knowing.
Ill go with C# then once fully skilled see where I go from there. Ive always wanted to go the Assem route of programming. Lots of skill and a very powerful language.
|
|
|
|
|
So I am a total newbie. Tell me why this doesnt work. I dont know what to do anymore. notice; the second time I click this button the calling App closes and the instance runs anyway
please help
private Mutex m_myMutex = null;
private void button1_Click(object sender, System.EventArgs e)
{
bool blnGotIt;
m_myMutex = new Mutex(true, "aa", out blnGotIt );
if (!blnGotIt) this.Close();
Process aa = new Process();
aa.StartInfo.FileName = "C:\\Winnt\\System32\\calc.exe";
aa.StartInfo.WindowStyle = ProcessWindowStyle.Normal;
aa.Start();
//aa.WaitForExit();
aa.Close();
}
|
|
|
|
|
The first time you click, your m_myMutex gets set, the second time, it tries to get it again but fails as it already exists; that is the Mutex already exists. I don't know what you're trying to do but an "if (!m_myMutex==null)" around the assignment and bool check would stop that behavior. Or you may just want to "return" instead of "this.Close()".
|
|
|
|
|
thanks. looks like you did it (return; tip). alltho now I can only start it once. Each new click doesnt start the app again even if I closed the first instance down.
|
|
|
|
|
is it possible to find out the names of the controls on a form. e.g.
TextBox tb = new TextBox();<br />
this.Controls.Add(tb);<br />
<br />
..<br />
<br />
<br />
<hr noshade="" width="100%" color="#80BFFF"><p style="margin: 0; padding: 2px; font-size: 8pt; text-align: left">:suss: Email: <a>theeclypse@hotmail.com</a> URL: <a target="_blank" href="http://www.onyeyiri.co.uk">http:
|
|
|
|
|
Object.GetType()
using System;
public class MyBaseClass: Object {
}
public class MyDerivedClass: MyBaseClass {
}
public class Test {
public static void Main() {
MyBaseClass myBase = new MyBaseClass();
MyDerivedClass myDerived = new MyDerivedClass();
object o = myDerived;
MyBaseClass b = myDerived;
Console.WriteLine("mybase: Type is {0}", myBase.GetType());
Console.WriteLine("myDerived: Type is {0}", myDerived.GetType());
Console.WriteLine("object o = myDerived: Type is {0}", o.GetType());
Console.WriteLine("MyBaseClass b = myDerived: Type is {0}", b.GetType());
}
}
MS quote (http://www.microsoft.com/ddk) : As of September 30, 2002, the Microsoft® Windows® 2000 DDK, the Microsoft Windows 98 DDK, and the Microsoft Windows NT® 4.0 DDK will no longer be available for purchase or download on this site. Support for development will ship at the same time as the Windows XP Service Pack 1 (SP1) release.
|
|
|
|
|
Hi , you are answering your question
foreach (Control control in this.Controls)
{
Console.WriteLine(control.Name);
}
Is this what you mean
MYrc : A .NET IRC client with C# Plugin Capabilities. See
http://sourceforge.net/projects/myrc for more info.
|
|
|
|
|
Declare it as a public or protected member.
Mazy
"If I go crazy then will you still
Call me Superman
If I’m alive and well, will you be
There holding my hand
I’ll keep you by my side with
My superhuman might
Kryptonite"Kryptonite-3 Doors Down
|
|
|
|
|
Hello all!
I have the following problem: I have some properties that must not be null. Therefore I thought I should throw an exception in the set accessor if a null value is passed. But what exception? I thought to throw ArgumentNullException but is this a good approach? It's intended to be used in methods after all...
Cheers
and any help appreciated
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
I'd consider a value passed to a property to be an argument.
I tend to think that if you're giving a class invalid information, it's an Argument[Null/Invalid]Exception. If the class already holds invalid information based on what you're trying to achieve, it's an InvalidOperationException.
Paul
|
|
|
|
|
Thanks for the reassuring information !!
Cheers
have a sunny sunday
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Martin,
If you're not already, I would suggest following the conversation that extended in this thread - there's some interesting points being raised on both sides.
P
Paul
|
|
|
|
|
Yeah thanks, codeproject didn't "work" for about one day for me..
Cheers
Martin
"Situation normal - all fu***d up"
Illuminatus!
|
|
|
|
|
Someone else (or maybe you) was talking about this earlier in the Lounge (or maybe the Soapbox). CP has gone down, for an hour or so at a time, several times lately and then there's problems with losing the DNS entries but I didn't really follow it. It's not happening to me and my eyes tend to glass over when I hear anything about DNSes, so I phased out.
Paul
|
|
|
|
|
Exceptions are for exceptional conditions - conditions that are unexpected during normal circumstances. Exceptions are relatively expensive and aren't that great for stuff like this.
I personally would write the class to have a constructor that accepts all required arguments in addition to returning an error (or true/false) on execution of a method that finds a required field that contains null. Perhaps go as far as exposing a public read-only IsValid property and have your internal methods call it - exposing IsValid may also help developers understand how your class works since they can check the object's validity anytime they like.
If you insist on using exceptions, don't throw CLR exceptions(like System.ArgumentNullException - these are CLR-sourced exceptions. You can create your own application-specific exceptions based on the System.ApplicationException class - it exists for people like us to create our own exceptions. Just create your own class and derive it from System.ApplicationException - you don't have to add any members since the catch statement works based on the exception's type.
Erik Westermann
Author, Learn XML In A Weekend (October 2002)
|
|
|
|
|
Erik Westermann wrote:
Exceptions are for exceptional conditions - conditions that are unexpected during normal circumstances.
Wouldn't you say that trying to set something to null that shouldn't ever be null is an exceptional circumstance? The application setting the property SHOULD check for null before setting. If it doesn't then there's nothing wrong with throwing an exception.
I would agree with you that applications shouldn't simply live inside a try/catch structure, just in case. But if a class/component/control receives something it doesn't expect from an app then it should throw an exception.
Erik Westermann wrote:
If you insist on using exceptions, don't throw CLR exceptions(like System.ArgumentNullException - these are CLR-sourced exceptions. You can create your own application-specific exceptions based on the System.ApplicationException class - it exists for people like us to create our own exceptions.
Why would you do that if one already exists that meets the criteria you're looking for? Do things in the Microsoft namespace avoid throwing exceptions from the System namespace?
I'm not meaning to sound argumentative, I'm genuinely interested in people's opinions of good programming practice. The .NET languages are new enough that there is room for discussion; while some things will carry naturally from older languages, I'm not sure exceptions do. They have existed before but not in the same manner they do here.
Paul
|
|
|
|
|