Related
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 9 years ago.
Improve this question
I'm looking to teach my kids programming, and it looks like I've narrowed it to two options:
jMonkeyEngine 3 (jME 3)
Unity 4.3
I couldn't find any "current" comparisons, and so I thought I'd ask:
Which is better jME3+ or Unity4.3+ for Teaching Programming vs Engine Benefits?
I'm not a game developer, but as a corporate & control systems developer I have experience in both C# and Java.
I'm currently leaning towards Unity4.3+ because:
From a Programming perspective, I think C# is a little cleaner than Java, though this means little if the Engine Coding & Object model encourage poor programming
Engine Benefits: Unity4.3+ will "supposedly" have upcoming support for both XBox One & PS4
Note: in fairness to jME, I will make note of this "pre-alpha state" iOS option for jME which is better than a marketing "supposed" perhaps: (http://hub.jmonkeyengine.org/wiki/doku.php/jme3:ios)
If they are equal in all other regards, which one has better Service integration?
Glad that you interesting in JME3.
I’m also working for a project that target making education programs (youngs and adults) in gaming enviroment.
If you going to let your children learn programming via game developing, it’s a good idea. But both JME3 and Unity are far more complicated to start with ( I assume your children are still young )… There are also few projects suitable for children to learn programming visually.
Greenfoot ww.java.com/en/java_in_action/alice.jsp
Alice ww.greenfoot.org/door
Kojo ww.kogics.net/sf:kojo
Those things (languages come with IDEs) have short learning curve and easy to get with, require minimum knowledge and suitable for children and starter. That’s the education side.
For the engine side. [This is my personal opinion]
I prefered JME.
I’m also left Unity ( did about 4-5 commercial games in unity my self) to go to JME. Before Unity, i also worked in Ogre, UDK, Torque and a lot other engines ( 10 more). I also worked with commercial engine in daytime job in C++, which code dirty as hell but run extremely smooth and cost millions dollar.
The reason is: Those engine tied you up with its limitation and pre-made sollutions. Of course that’s also half of the reason why you choose and engine at first. But when you hit that limitation, for example the license fee or the closed technologies. You will hate them as much as i did.
So that’s why i come to JME in a search of “complete” game developing and entertaining technology.
If you are an experienced Java and C#, in association with JME and Unity developer, i will name you a few things that can be *strong text*compared between the two:
License : free open source vs free / commercial
IDEs : Netbean – an open and extensible platform ( leading quality) vs MonoEdit (the most buggy IDE you can find on earth)
** The based technolgy:**
Graphics: OpenGL v2+ vs Modified renderer ( openGL compatiable v3+) Unity win in this one i suppose :( . It’s sad for a long term java developer like me seeing this. But we can improve the graphics from time to time i hope.
Data management: You choose ( H2, HyperTable, Neo4j …from Java world 100+ of those) VS Unity database
Data oganization: You choose (ES, OO, COD, data driven …) VS ES and data driven only.
Networks: You choose ( Java rocks in this one) VS Unity network ( high performance but never… ever defeat Java)
Cloud and distributed: You choose (Storm, Hadoop..) VS home grown "cloud techs”
Note that i still usually using Unity and JME3 at the same time, for my job and for my hobby. I used Unity 4 with fancy mecanim animation, sub stance material … at day, and using JME3 for research and improve it at night. IMO, JME3 is the game engine which worth to learn, and it will rocks and shine in the future!!!
Hope this help!
It's hard to make a comparison when I have never actually used Unity. I have seen demo's and it's interface however. But having used the jMonkeyengine for about 2 and a half years, I can say I am a happy customer :).
Unity probably has a bit more of everything: developers, users, bells and whistles, but there is a cost associated to that.
Similarities between the 2:
- Big communities (Unity is bigger)
- Many free tutorials
- Rapid development (here's a link to a couple ludum dares I've been involved with using jME http://www.ludumdare.com/compo/ludum-dare-28/comment-page-3/?action=preview&uid=16152, http://www.ludumdare.com/compo/ludum-dare-24/comment-page-1/?action=preview&uid=16152)
- Easy to distribute to Windows/Mac/Linux/Android
The jMonkeyEngine is completely free and all open source (New BSD License). So you can see all the inner workings of the engine, and even change it if you do not like something (of course you are welcome to commit the changes back :)). So you will learn a lot more by delving into the jME source code.
C# and Java is a debate that can go on for ages, but I don't think it should be a defining factor, they are very similar in nature. There doesn't exist a usable iOS version in jME, and I don't think there is any immediate plans for Xbox One and PS4, so Unity will win there.
JME is a bit more hardcore engine than Unity.
JME:
- strong community (english language mostly)
- OpenSource and free to use.
- has many cool tools. But Unity has much more i guess.
- Simple to compile and code with all platforms.
- Supports Linux. You can develop games in Linux OS.
Unity:
- Strong community (with many local communities and languages)
- Non free. But it has professional tools.
- Has javascript support. You can add scripts inside of the editor.
- Has really cool world editor. But coding is better in JME SDK.
I use JME. But it's hardcore in many cases.
It really depends on what you aim for.
The pro on unity is especially way to get assets into the engine (via the shop).
With jme3 you need to be able to at least partly work with blender/3dsmax or similar. Or use a graphic style where it does not matter (eg 2d or blockworld)
Also it has better state of the art features in terms of lighting and shadowing.
But you kinda need to pro license sooner or later, as even basic stuff as lod is tied to it
http://unity3d.com/unity/licenses and it is not that cheap.
The pro with jme3 is that it does not limit you. It is only a core engine but also not tailored for some use-cases.
As far as I understand Unity uses a kinda Entity-component system but without separate systems. (The components contain the logic)
In jme3 you are free to use whatever you want, and are encouraged to make a clean split between logic and graphic. You are free to use whatever programming type you prefer (eg ES,OO) As jme is jvm based you also have access to other jvm languages, eg for functional programming via scala.
So it depends on what your target(and budget) is, more about developing and their specifics, or more about making a own game.
Regarding the version controll,
JME3 works fine with git and svn and kind everything else. As there are no special files or logic tied to any of them.
I can't say I've ever used Unity but here are some things I love about JME3:
Completely free & open-source under BSD license
Awesome SDK based on awesome NetBeans
Deployment to Linux, Mac & Android (as well as windows) with 1 click, I have no idea if Unity can do this
Amazing active community, constantly creating new plugins and features (IOS deployment coming soon, possibly), they will also help you with any trouble you run into
Networking is awesome
Can use other Java libraries or features alongside
As far as features of the engine go, Unity probably has more. However, I highly recommend JME, it is a great engine. Somebody else said you need knowledge of blender, whereas with Unity they have an asset shop. While Blender knowledge is (very) useful, there are hundreds of websites online that sell or give away for free assets (for instance www.turbosquid.com).
I have to ask, is whomever you're teaching actually ready to program for a game engine?
If the first thing that has to be taught is a hello world script followed by learning what variables are, then both options do nothing but over-complicate what needs to be a simple learning environment.
Even if they have the basics of programming down, they should know what the basics of game programming are. They should know what a vector is and how matrix math works with some underlying understanding of how an engine operates.
I don't know about jME, but with Unity, this would be the point where they could actually write code that does something in which they can earnestly say they understand why (which should be the most important part of teaching someone). I describe Unity as the simplest, big boy toy out there. That still means they have to be ready for the big boy toys in the first place.
Oh, and stick with the free version of Unity. Most pro features are graphical elements like bloom lighting that don't effect a programmer's capabilities.
Guess no new project is implemented in languages like Modula, Ada , Oberon .. anymore (right?). But still there are legacy systems floating around, popping out here and there looking for their creators. They cant find them because they might be retired sitting at a beach somewhere enjoying themselves.
Serious:
1) I am wondering if there are still active (experienced) Modula programmers around ?
2) Anyone experience with porting Modula code to a new hardware generation ?
3) Does anyone know about a tool that can re-engineer, means map Procedures and Mod-files in a graphical way. These tools are available for eg. C programs.
Sure, Modula Syntax is not that breathtaking in comparison to todays .net and Java API's with 1000's of methods, but if someone drop about 100.000 lines of almost undocumented sourcode at you (nicely mixed with some 8000 lines assembler), you better know if you better reject it. I have this request and I am very resistant. (Option: port and keep modula source or migrate to other language in 9 months!)
cheers
1) I am wondering if there are still active (experienced) Modula programmers around ?
There are plenty of them, but you have to do a bit of web search to find them. If you search for "Curriculum Vitae" (or "Resume") and "Modula-2" there should be plenty of hits. Also, anybody who has experience in Oberon, Pascal or Delphi will be able to handle Modula-2.
Also there are active Modula-2 projects, most notably:
GNU Modula-2 at http://www.nongnu.org/gm2
Modula-2 R10 at http://modula-2.net/m2r10
Modula2JCC at http://code.google.com/p/modula2jcc
Modulipse at http://modulipse.sourceforge.net
Schwarzer Kaffee http://sourceforge.net/projects/schwarzerkaffee
2) Anyone experience with porting Modula code to a new hardware generation ?
Ask on the GNU Modula-2 mailing list. Many GNU Modula-2 users have Modula-2 code from 16-bit DOS systems they like to port to modern platforms. The GNU Modula-2 website lists this as one important motivation for GM2. The GM2 mailing list is at:
http://lists.nongnu.org/mailman/listinfo/gm2
There is also the Modula-2 Usenet news group, you can reach it via the Google interface at
http://groups.google.com/group/comp.lang.modula2
Last but not least, there is a Modula-2 IRC channel at Freenode
irc://irc.freenode.net/#modula-2
3) How to assess 100.000 lines of Modula-2 source code
"if someone drop about 100.000 lines of almost undocumented sourcode at you (nicely mixed with some 8000 lines assembler), you better know if you better reject it. I have this request and I am very resistant. (Option: port and keep modula source or migrate to other language in 9 months!)"
You may want to contact Rick Sutcliffe, a well known Modula-2 scholar and book author who is also the maintainer of the Modula-2 FAQ in which he states that he does get hired to do consulting work for assessing Modula-2 source code in company take-over situations. It seems to me that your situation might be similar enough to justify hiring an expert to establish the value of the software that is offered to you.
The Modula-2 FAQ is at http://faq.modula2.net
1) I am wondering if there are still active (experienced) Modula programmers around ?
Yes, I'm one. But I already have a job :-)
2) Anyone experience with porting Modula code to a new hardware generation ?
Not clear if you meant porting code or porting a compiler. Porting Wirth's Modula-2 compiler (or Oberon compiler) should be easy. Ada and Modula-3 are another story.
3) Does anyone know about a tool that can re-engineer, means map Procedures and Mod-files in a graphical way. These tools are available for eg. C programs.
I don't understand the question. If you are looking to visualize the import graph of a Modula-2 program, you could easily write something to emit dot. Visualizing call graphs is another story.
Here's my bottom line on Modula-2 and Oberon:
Any C programmer worth his or her salt can quickly learn enough Modula-2 to maintain a large legacy application. Oberon's another story; its model of exported names and type extension is not like the object models found in other OO languages.
Wirth's genius as a language designer was to make things easy for the person writing the compiler. So if you need tools, any good compiler writer can produce them. Wirth's compiler should be available and easy to port.
Ada does not deserve to be mentioned in the same breath with Modula-2 and Oberon.
Ada is still an very active language. I use it in my own research since 1995 and in my lectures since last year at a university.
I myself don't know much of Modula, however I worked at a research center in Brazil that had a packet switching network project (Compac) that was entirely created in Modula-2. If I'm not mistaken they even developed the compiler/linker themselves. Since I don't feel at liberty to point you to specific persons, I would suggest you do a google search for "compac" and "cpqd" and I can pretty much guarantee you will find names of people involved in it. It should come as no surprise that references to it are quite old, from late 80's.
Modula-2 is architecturally not that dissimilar to C. A programmer familiar with C should have little trouble figuring out Modula-2. Given that your application has a significant body of assembler code then you will need someone with low-level skills anyway.
IIRC Modula-2's grammar is LL(1) or nearly so, so writing a parser to generate call graphs for a Modula-2 code base is not beyond the wit of man. Graphviz is your friend if you want a quick and easy way of visualising the call graphs. Again, this suggests that you're up for employing a 'real programmer' to do the porting work.
If you need a reasonably viable Modula-2 compiler, you could look at the Amsterdam Compiler Kit which does have a competent Modula-2 compiler that can target a wide variety of platforms, although it doesn't support Win32 IIRC.
I would suggest that documenting and porting the existing Modula-2 code base is probably easier than attempting to re-write it in C. However, if you need to move to a different processor architecture then you will have to re-write the assembly language bits anyway. This does rather change the value proposition of porting.
If it is you doing the porting then you might consider doing it in two steps.
Arrange with the customer to do a utility to generate the call graph and give them a feasibility study recommending what to do and some estimate of the scope.
Do the port, either porting the code base or re-writing it. Bear in mind that you may not need a low level language for the entire code base if you're running it on a modern computer. You may be able to do it in a mixture of (say) Python and C with less effort than would have been needed for a rewrite purely in C.
Yup.
I realise that you asked this question quite some time ago but I also know that projects that nobody like to handle get kind of delayed...
I built several large systems in Modula-2 over a span of ten years and have this insane habit of taking on impossible tasks.
I have not touched it for about ten years but am absolutely certain that I can port your system for you to almost any other platform. Why not get in touch with me if you are still interested?
Oh yeah - better still, we are both in Singapore :-)
ADW Modula-2 has now been released as freeware. http://www.modula2.org/adwm2/ Since it's free and supports 32 & 64-bit Windows applications (and I know Modula-2), I've picked it up and am using it for small utility work that I want to be a 64-bit Windows binary (most of my work is in Java and .Net, which are fine but sometimes a pure binary is best. I use MASM32 for 32-bit binary Windows apps already).
edit
There's also a project in the works (still very early on, not yet usable as of the date of this edit) now to compile Modula-2 on the JVM (with a transpile to Java option). https://github.com/m2sf/m2j
Sorry if this is a broad question, but other than Objective-C, Cocoa, and OpenGL ES, what technologies or concepts would you suggest I read up on before writing a game for the iPhone? I'm a beginning game developer and need all the help I can get :)
MATHS - I would advise this topic
Some example areas of interest for applications in Game Development
Calculus, Geometry,The Cartesian Co-ordinate System, Vectors, Matrices, Transformations etc...
Sorry, my answer is not computing related.
A game tells a story, a great game tells a great story. So I would suggest to learn principles of storytelling.
Not going as scholar as Aristotle's Poetics, I recommend more modern Story by Robert McKee. It focuses on movie making, but I am pretty sure that many of the concepts he develops can be applied to game making.
You should read some articles on GameDev. Obviously, learning some of the fundamental concepts in computer graphics would be very helpful. But really, once you get to where you can write Objective-C and understand the APIs, go ahead and get started. You will learn a lot in the process; of course, keep learning and reading about these things I mentioned, but start coding. Find some books on game programming, particularly AI and so forth. Go ahead and get your feet wet programming though. Of course, be sure you learn your language thoroughly.
Quite frankly, I have found that I never know what I need to know until I actually get my hands dirty. That's why I suggested here that someone looking to jump into designing a 3-D iPhone game start with some simpler, targeted projects. These targeted projects can teach you core concepts as you put them to practical use. OpenGL seemed like this impossible-to-understand black box until I made myself perform some simple tasks with it. In a few weeks, I had an application based on it.
In college, I would spend weeks trying to understand the theory behind an aspect of thermodynamics, but then I would see one practical application for it and the whole thing would fall into place. Since then, I've focused on finding specific applications for concepts before spending too much time with the pure theory behind them.
A solid understanding of what makes a good gaming UI especially on the iPhone would be key, especially with the options it provides, be it accelerometers, or onscreen touch inputs.
I'd be sure to try out existing games and see what works, what doesn't, and what gets good feedback. You may also want to look at Flash and DS based games to see what works on other small screens/devices.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I just found out about Alice and Scratch. I will be implementing those pretty soon. But, I wonder, what would be good material for kids from 1st grade thru 4th/5th?
Toontalk is something to look at. I used it successfully with group of ten- to eleven-year-old children, and it's been used with much younger kids. Of course, I think Scratch has too. But Toontalk is specifically built to feel more like a game. It's essentially a 3D world that kids can explore and interact with, and in which they create programs by training robots. Highly recommended.
http://www.toontalk.com
http://playground.ioe.ac.uk/ABOUT.HTM
http://playground.ioe.ac.uk/games.htm
The Toontalk 3d environment ingeniously operates as a metaphor for sophisticated programming concepts. There are quite a few academic papers linked on Toontalk site about the educational theory behind Toontalk. Here's one interesting paper that describes how the Toontalk 3d objects map onto abstract programmming concepts.
I'll admit, I'm not a professional educator. And my info on kid's programming education may be too obsolete, but my mom was as close as they came to a computer educator in the 1980s, and here's some tricks from her book.
When I was 8, she had no problem teaching me logo
I would think that before reading skills are somewhat developed, it would be hard to teach the semantics of any programming language - however simple. And the first "aha!" for programming (to me) would be realizing that if you give really simple commands to the computer, it will do neat stuff for you.
If I had to teach kids that were still working on reading fundamentals, I'd probably focus it on games that are not directly connected to a programming language, but which do involve logic development. Things like:
Assigning letters to codes and translating from letter to code
Games where you follow simple rules to move things around, emulating data structures.
Puzzle games making use of computer science concepts - like shortest path algorithms. Not in analyzing the algorithm, but in developing it in the first place.
I'm afraid I don't know of a pre-built set of material for this sort of stuff. But I think that you might be able to create your own.
The limits would be the cognitive abilities of the kids -- I know that there are certain points where the theories say that kids can't do certain types of abstract concepts. For example, I was just listening to an example that mentioned that pre-schoolers can't handle the idea that something may have more than one name. Not quite knowing where those points of cognitive growth typically occur, I'm not 100% certain of what game would be right for what age group -- it might be trial and error.
I use Alice to teach children ages 11-14. It works well for them, but I would not use it for children much younger than that unless it was a one-on-one situation. I can't speak for Scratch.
One thing I can speak for though, is Lego Mindstorm programming. There is a cost to it, unlike Alice and Scratch, but it is very approachable for 1st through 4th grade. See if the First Lego League has a group near you so you can join up with others to help with costs.
Scratch is the simplest programming language I have found for kids. You can use it like logo, but it is much nicer.
I think Alice is too hard for kids of age 8 years.
Microsoft has also Small Basic and shipped v0.2 recently.
This version also includes a cool new
feature that allows students to easily
graduate from Small Basic to Visual
Basic with the touch of a button.
Check out the full release notes in
the Small Basic blog.
Small Basic is a project that's aimed
at bringing "fun" back to programming.
By providing a small and easy to learn
programming language in a friendly and
inviting development environment,
Small Basic makes programming a
breeze. Ideal for kids and adults
alike, Small Basic helps beginners
take the first step into the wonderful
world of programming.
Download and for more information : MS Small Basic v 0.2
When I was really small we were taught things that have similarities to programming but aren't quite programming, games with puzzles to solve, tangrams, and even choose-your-own-adventure writing programs. Later we learned LOGO.
There are some systems like toontalk, but to do anything like programming, you need to cope with sequence - this follows that, follows that, follows that - and basic arithmetic. Which is why 8+.
Younger, you want the children you work with to either have a good sense of what sequence might be - say from following instructions - and to be supported by a good interface, where drag and drop isn't as fiddly as scratch.
RoboMind is a simple educational programming environment with an own scripting language that allows beginners to learn the basics of computer science by programming a simulated robot.
In addition to introducing common programming techniques, it also aims at offering insights in robotics and artificial intelligence. RoboMind is available as stand-alone application for Windows, Linux and Mac OSX. It is free and open source.
Worth to give a try!
www.robomind.net
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 last month.
Improve this question
Summary:
Can I program a "thick
client" game in C without reinventing
wheels, or should I just bite the
bullet and use some library or SDK?
I'm a moderate C programmer and am not
afraid to work with pointers, data
structures, memory locations, etc. if
it will give me the control I need to
make a great "thick-client" game.
However, I'm thinking of eschewing
high-level languages & frameworks for
the sake of power and control, not
ease of use.
I'm interesting in tinkering with a 2D fighting/platforming game as a side project sometime. I'm primarily a Linux server-side programmer with experience in Python, Ruby and PHP. I know that there are excellent frameworks in some of these languages, like PyGame. I am also aware of the success people have had with stuff like Air and .NET... but I have some concerns:
Performance: Scripting languages are notoriously slow. If I'm making a real-time game, I want it to be as snappy as possible.
Huge binaries: Using frameworks like .NET or scripting languages like Ruby often result in big CLRs or libraries that you wouldn't otherwise need. The game I want to make will be small and simple--I don't want its CLR to be bigger than the game itself!
Extra stuff: Honestly, I just don't like the idea of inheriting some big game library's baggage if I can wrap my head around my own code better.
I'm asking this question because I know I'm very susceptible to Not Invented Here Syndrome. I always want to program it myself, and I'm sure it wastes a lot of time. However, this works out for me remarkably often--for example, instead of using Rails (a very big web project framework with an ORM and GUI toolkit baked in), I used an array of smaller Ruby tools like rack and sequel that fit together beautifully.
So, I turn to you, SO experts. Am I being naive? Here's how I see it:
Use C
Cons
Will probably make me hate programming
High risk of reinventing wheels
High risk of it taking so long that I lose interest
Pros
Tried & true - most A-list games are done in C (is this still true today?)
High level of control over memory management, speed, asset management, etc., which I trust myself to learn to handle
No cruft
Use framework or SDK
Cons
Risk of oversized deliverable
Dependent on original library authors for all facets of game development--what if there isn't a feature I want? I'll have to program it myself, which isn't bad, but partially defeats the purpose of using a high-level framework in the first place
High risk of performance issues
Pros
MUCH faster development time
Might be easier to maintain
No time wasted reinventing common paradigms
What else can I add to this list? Is it a pure judgment call, or can someone seal the deal for me? Book suggestions welcome.
I believe you are working under a fallacy.
There are several frameworks out there specifically for game programming --- written by people with much experience with the complication of game design, almost certainly more tha you do.
In other words, you have a "High risk of performance issues" if you DON'T use a framework.
My current thinking is:
If you want to learn to program, start making the game engine from the base elements upwards (even implementing basic data structures - lists, maps, etc). I've done this once, and while it was a learning experience, I made many mistakes, and I wouldn't do this a second time around. However for learning how to program as well as making something cool and seeing results I'd rate this highly.
If you want to make a proper game, use whatever libraries that you want and design all of the game infrastructure yourself. This is what I'm doing now, and I'm using all of the nice things like STL, ATL/WTL, Boost, SQLite, DirectX, etc. So far I've learnt a lot about the middle/game logic aspect of the code and design.
If you just want to make a game with artists and other people collaborating to create a finished product, use one of the existing engines (OGRE, Irrlicht, Nebula, Torque, etc) and just add in your game logic and art.
One final bit of wisdom I've learnt is that don't worry about the Not Invented Here syndrome. As I've come to realise that other libraries (such as STL, Boost, DirectX, etc) have an order of magnitude (or three) more man-hours of development time in them, far more than I could ever spend on that portion of the game/engine. Therefore the only reason to implement these things yourself is if you want to learn about them.
I would recomend you try pyglet.
It has good performance, as it utilizes opengl
Its a compact all-in-one library
It has no extra dependencies besides python
Do some tests, see if you can make it fast enough for you. Only if you prove to yourself that it's not move to a lower level. Although, I'm fairly confident that python + pyglet can handle it... at worst you'll have to write a few C extensions.
Today, I believe you are at a point where you can safely ignore the performance issue unless you're specifically trying to do something that pushes the limits. If your game is, say, no more complicated than Quake II, then you should choose tools and libraries that let you do the most for your time.
Why did I choose Quake II? Because running in a version compiled for .NET, it runs with a software renderer at a more than acceptable frame rate on a current machine. (If you like - compare MAME which emulates multiple processors and graphics hardware at acceptable rates)
You need to ask yourself if you are in this to build an engine or to build a game. If your purpose is to create a game, you should definitely look at an established gaming engine. For 2D game development, look at Torque Game Builder. It is a very powerful 2D gaming engine/SDK that will put you into production from day 1. They have plenty of tools that integrate with it, content packs, and you get the full source code if you want to make changes and/or learn how it works. It is also Mac OSX compatible and has Linux versions in the community.
If you are looking for something on the console side, they have that too.
I'm surprised nobody has mentioned XNA. Its a framework built around DirectX for doing managed DirectX programming while removing a lot of the fluff and verbosity of lower level DirectX programming.
Performance-wise, for most 2D and 3D game tasks, especially building something like a fighting game, this platform works very well. Its not as fast as if you were doing bare metal DirectX programming, but it gets you very close, and in a managed environment, no less.
Another cool benefit of XNA is that most of the code can be run on an Xbox 360 and can even be debugged over the network connection was the game runs on the Xbox. XNA games are now allowed to be approved by the Xbox Live team for distribution and sale on Xbox Live Arcade as well. So if you're looking to take the project to a commercial state, you might have am available means of distribution at your disposal.
Like all MS development tools, the documentation and support is first rate, and there is a large developer community with plenty of tutorials, existing projects, etc.
Do you want to be able to play your game on a console? Do you want to do it as a learning experience? Do you want the final product to be cross platform? Which libraries have you looked into so far?
For a 2d game I don't think performance will be a problem, I recommend going with something that will get you results on screen in the shortest amount of time. If you have a lot of experience doing Python then pyGame is a good choice.
If you plan on doing some 3d games in the future, I would recommend taking a look at Ogre (http://www.ogre3d.org). It's a cross platform 3d graphics engine that abstracts away the graphics APIs. However for a 2d project it's probably overkill.
The most common implementation language for A-list games today is C++, and a lot of games embed a scripting language (such as Python or Lua) for game event scripting.
The tools you'd use to write a game have a lot to do with your reasons for writing it, and with your requirements. This is no different from any other programming project, really. If it's a side project, and you're doing it on your own, then only you can assess how much time you have to spend on this and what your performance requirements are.
Generally speaking, today's PCs are fast enough to run 2D platformers written in scripting languages. Using a scripting language will allow you to prototype things faster and you'll have more time to tweak the gameplay. Again, this is no different than with any other project.
If you go with C++, and your reasons don't have to be more elaborate than "because I want to," I would suggest that you look at SDL for rendering and audio support. It will make things a little bit easier.
If you want to learn the underlying technologies (DirectX, or you want to write optimized blitters for some perverse reason) then by all means, use C++.
Having said all that, I would caution you against premature optimization. For a 2D game, you'll probably be better off going with Python and PyGame first. I'd be surprised if those tools will prove to be inadequate on modern PCs.
As to what people have said about C/C++/Python, I'm a game developer and my company encourages C. Not b/c C++ is bad, but because badly written C++ is poison for game development due to it's difficulty to read/debug compared to C. (C++ gives benefits when used properly, but let a junior guy make some mistakes with it and your time sink is huge)
As to the actual question:
If your purpose is to just get something working, use a library.
Otherwise, code it yourself for a very important reason: Practice
Practice in manipulating data structures. There WILL be times you need to manage your own data. Practice in debugging utility code.
Often libs do just what you want and are great, but sometimes YOUR specific use case is handled very badly by the lib and you will gain big benefits from writing you own. This is especially on consoles compared to PCs
(edit:) Regarding script and garbage collection: it will kill you on a console, on a recent game I had to rewrite major portions of the garbage collection on Unreal just to fill our needs in the editor portion. Even more had to be done in the actual game (not just by me) (to be fair though we were pushing beyond Unreal's original specs)
Scripting often good, but it is not an "I win" button. In general the gains disappear if you are pushing against the limits of your platform. I would use "percent of platforms CPU that I have to spare" as my evaluation function in deciding how appropriate script is
One consideration in favor of C/C++/obj-C is that you can mix and match various libraries for different areas of concern. In other words, you are not stuck with the implementation of a feature in a framework.
I use this approach in my games; using chipmunk for 2D physics, Lua as an embedded scripting language, and an openGL ES implementation from Apple. I write the glue to tie all of these together in a C language. The final product being the ability to define game objects, create instances of them, and handle events as they interact with each other in C functions exposed to Lua. This approach is used in many high performance games to much success.
If you don't already know C++, I would definitely recommend you go forward with a scripting language. Making a game from start to finish takes a lot of motivation, and forcing yourself to learn a new language at the same time is a good way to make things go slowly enough that you lose interest (although it IS a good way to learn a new language...).
Most scripting languages will be compiled to byte code anyway, so their biggest performance hit will be the garbage collection. I'm not experienced enough to give a definite description of how big a hit garbage collection would be, but I would be inclined to think that it shouldn't be too bad in a small game.
Also, if you use an existing scripting language library to make your game, most of the performance critical areas (like graphics) can be written in C++ anyway (hopefully by the game libraries). So 80% of the CPU might actually be spent in C++ code anyway, despite the fact that most of your project is written in, say Python.
I would say, ask yourself what you want more: To write a game from start to finish and learn about game development, or to learn a new language (C++). If you want to write a game, do it in a scripting language. If you want to learn a new language, do it in C++.
Yeah unless you just want to learn all of the details of the things that go into making a game, you definitely want to go with a game engine and just focus on building your game logic rather than the details of graphics, audio, resource management, etc.
Personally I like to recommend the Torque Game Builder (aka Torque 2D) from GarageGames. But you can probably find some free game engines out there that will suit your needs as well.
I'm pretty sure most modern games are done in C++, not C. (Every gaming company I ever interviewed with asked C++ questions.)
Why not use C++ and existing libraries for physics + collisions, sound, graphics engine etc. You still write the game, but the mundane stuff is taken care of.
There are alot of different solutions to the issue of abstracting and each deals with it in different ways.
My current project uses C#, DirectX 9, HLSL and SlimDX. Each of these offers a carefully calibrated level of abstraction. HLSL allows me to actually read the shader code I'm writing and SlimDX/C# allows me to ignore pointers, circular dependencies and handling unmanaged code.
That said, none of these technologies has any impact on the ease of developing my AI, lighting or physics! I still have to break out my textbooks in a way that I wouldn't with a higher-level framework.
Even using a framework like XNA, if most video games development concepts are foreign to you there's a hell of a lot still to take in and learn. XNA will allow you to neatly sidestep gimbal lock, but woe betide those who don't understand basic shading concepts. On the other hand, something like DarkBASIC won't solve your gimbal lock problem, but shading is mostly handled for you.
It's a sufficiently big field that your first engine will never be the one you actually use. If you write it yourself, you won't write it well enough. If you use third party libraries, there's certainly aspects that will annoy you and you'll want to replace.
As an idea, it might be worth taking various libraries/frameworks (definately make XNA one of your stops, even if you decide you don't want to use it, it's a great benchmark) and trying to build various prototypes. Perhaps a landscape (with a body of water) or a space physics demo.