• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

JamesTheNumberless

Members
  • Content count

    19
  • Joined

  • Last visited

Community Reputation

121 Neutral

About JamesTheNumberless

  • Rank
    Member

Personal Information

  1. [quote name='superman3275' timestamp='1347820482' post='4980685'] I can't tell if this is a troll or someone who just woke up and decided to make a game. C# is a less complex language, however I wouldn't consider it harder. And there are more than 3 threads about this same thing on the first page of the beginners section. [/quote] nooooooooo, C# is a more complex language - it has much more in it than C++ and is growing all the time (even if half of what they add these days is confusing people about the best way to use it) But programs written in C++ are more complex out of the necessity of dealing with a lot of machine level concepts that are dealt with for you by the C# runtime. C# has features that are far beyond anything C++ by itself can comprehend such as support for dynamic typing, memory management and a completely different system of linking & compiling that's much faster, cleaner and more advanced. There's nothing stopping you from making all these things in C++, and there are low level things you can make C++ do that are unavailable in C# (without unsafe code or interop) but those are available by virtue of the language being simple, not complex
  2. [quote name='ATC' timestamp='1347848057' post='4980764'] I say just go ahead and learn C#. It's an essential skill for modern Windows programming to know C# (or at least [i]some [/i].NET language) and how to use the .NET Framework. C# will be much less painful to learn and you will be a deadly programmer when you learn it. Moving on to learning C and C++ will be [b][i]FAR [/i][/b]easier, as you will already understand programming and the languages are very similar in style, syntax and structure. But, in the end, you will need to know [i]both[/i] to be a really effective game programmer and be eligible for a wide variety of jobs in the games industry... I just think learning C# first will be much easier. Don't fall into the trap of thinking language A is "better" than language B. Most such claims are complete nonsense, unless we're saying BASIC and VB.NET sucks (just kidding! lol). Programming languages also do [u][b][i]not[/i][/b][/u] (I repeat, do [u][b]NOT[/b][/u]) have any attribute, element or property called "power". All Turing-complete languages are "powerful". Theoretically, any Turing-complete language can calculate the entire span of existence of the known universe. C# is not "less powerful" than C or C++, nor is the reverse true. Likewise, assembly language is not more "powerful" than C... Languages also do not have any sort of fixed performance. The performance/speed of code varies from machine to machine, API to API, programmer to programmer, etc... Some languages can be [i]theoretically [/i]faster than others due to physical limitations or advantages (e.g., JIT compiling or interpretation), but no programming language has a "top speed". Well-written C# code can easily outrun badly-written native code, and vice-versa. Managed languages, despite being theoretically slower due to JIT compiling, can sometimes be superior in performance to native code considering the gains in memory efficiency, reduced bugs, cleaner and better-written code, etc. While I can usually squeeze a couple more milliseconds out of C than I can with C#, sometimes complex algorithms can be faster in C#. It really all depends... just, like I said, never subscribe to any belief that any language is necessarily "better", "faster" or "more powerful" that any other (provided we're talking about practical, Turing-complete languages...not [url="http://en.wikipedia.org/wiki/Brainfuck"]brainfuck[/url] or anything impractical). If you start with C#, then you'll have the opportunity to learn the essence of Windows application programming (via Winforms) and the essence of DirectX (via XNA Framework). Both of these are easy-to-use APIs that are quick and easy to get started with but provide very deep, far-reaching and low-level capabilities. There's no reason you can't write a big, bad multi-million dollar Windows application with C#, just like you can with C or C++! There are plenty of them out there! When you feel you have "outgrown" the XNA Framework, which is like to happen when you want to write next-gen games for Windows, XBox or other platforms, then move on to learning SlimDX (the C# wrapper for DirectX and all its related APIs) and OpenGL. [/quote] This should be required reading for everyone before posting on a [name of managed language x] vs C++ thread
  3. Unity

    [quote name='EddieV223' timestamp='1347823971' post='4980694'] +1 irrlicht. I've used orgre3d and irrlicht. I like irrlicht the best, easier to use, the api is more consistent and easy to use. Speed is great, and it comes with a free level designer. It also compatible with LOTS of formats, ogre3d only supports its .mesh format. It also has an optional audio library too. [/quote] Irrlicht also gets my vote. Actually, it comes second to Havok's Vision engine (used to be Trinigy) but that costs money! However, I think possibly only UDK has the same sort of IDE approach as Unity does, and even then it's not quite the same. Where I work we've all (C#, Web and C++ developers alike) been blown away by Unity, both in how sensibly it works and the level of performance you can get out of it without even trying. If what you're after is a good way to learn C++ - don't start with a large 3rd party engine! Get yourself some good C++ books and try writing your own engine from scratch following the NeHe or directxtutorial.com (my favourite) lessons.
  4. Unity

    [quote name='Mizu' timestamp='1347758197' post='4980521'] [quote name='JamesTheNumberless' timestamp='1347749369' post='4980498'] C#, used by Unity, is a fully fledged OO language that has far more features than C++ and is therefore more complicated [/quote] Number of features of a language != how complicated said language is... [/quote] Yes it does ;) C++ is simple and powerful, and difficult to use properly when dealing with high levels of abstraction. C#/Java and the runtimes they are coupled to lend themselves better to software engineering because they are more advanced OOP languages that have concepts built in that the C++ programmer has to take time developing themselves. More complicated programs, less complicated language.
  5. Unity

    In case it wasn't clear from my last post. There is an engine similar to Unity 3D that supports C++ It's called Unity 3D You can write C++, compile it to C++/CLI DLLs, and reference those in your game object scripts. So if you have, for instance, all your AI routines written in C++. You can keep them in C++, and only need write enough C# to make calls to the appropriate functions. Manipulating objects in the scene graph will still be done with C# but that's ok because in any C++ engine you'd write 90% of such code in a scripting language anyway, You have the added advantage that (like Java) C# is a proper language that's very close in syntax to C++ and not restricted, or weird, in the ways that scripting languages often are.
  6. Unity

    [quote name='L. Spiro' timestamp='1347723579' post='4980403'] Scripts are simplified versions of programming languages, so that designers and other non-programmers—or programmers with extremely little skill—can work with them. [/quote] lol Not quite! C#, used by Unity, is a fully fledged OO language that has far more features than C++ and is therefore [b]more [/b]complicated. It isn't more complicated to [i]understand[/i], because it's better engineered. You can code in anything that compiles to CLI, including C++, and use that code in your Unity games, providing you don't mind using Visual Studio. Compile your code into C++/CLI. The DLLs can be dragged and dropped into your unity project as assets and then referenced by C# classes attached to your game objects. You will only have problems if you want your CLI code to interop with native windows code, and then only with portability to other platforms that Unity can target.
  7. [quote name='ic0de' timestamp='1347715365' post='4980362'] t if you are writing games the bulk of it is usually time critical and should be written in a fast language like c++, [/quote] Although, when you're writing a modern game, the stuff that's [b]really[/b] time critical is the stuff that's running on dedicated hardware. A GPU shader (whatever language it's written in) looks the same in a C++ game as it does in a C# game as it does in a Java game as it does in a Python game. What you then become concerned with, more than the algorithms running on the CPU, are the overheads involved in making graphics API calls. The worst benchmark I have ever seen comparing C++ to Java is one that concluded Java was bad at OpenGL because it took much more time to make a single immediate mode call to the GPU. People still often cite this benchmark and others derived from it as a reason why managed languages would perform badly for games, despite the fact that no modern realtime game would be making a vast amount of API calls per frame (much less using immediate mode!). In broader terms, all languages have their own pitfalls when used naively. Just as C++ programmers have to understand the platform their code will execute on, so Java programmers and C# programmers need to understand the JVM or the CLI to write well performing code. e.g. much the time when Java programs are a lot slower than their C++ equivalents, it isn't because of the overhead of the JRE per se, but because the way code is written is causing unnecessary extra work in that layer by invoking the garbage collector too often. Quite often, when C++ programs are less stable than their Java or C# counterparts, it's because the programmer is ignorant of the memory leaks they are causing, or of precisely what they're doing with pointers. etc, etc
  8. When I was a young lad in the early 90s - assembly code and C++ were still really the only things worth my time learning if I wanted to make games. But if I were starting today, C# would seem like the smart choice. Right now, if you want to be a AAA console developer, you still need C++ and I wouldn't expect that to change for the next console cycle. But current gen consoles and handhelds already support (and feature) smaller scale games written in managed languages including C# and Java. Android games are written in Java. 10 years from now, console development could look a lot different. I work for a PC developer that has had two games published in the last 2 years - one is built on a C++ engine and the other on a C# engine. When I started my current job a few years ago, I spent some time in the interview with the studio head looking at a demo video for Unity 3D, with him (a veteran programmer from the days when only assembly would cut the mustard for games) enthusing about it. Now we have two Unity projects in the pipeline. IMO Java and C# are superior to C++. C/C++ has long since been shunted to the sidelines for commercial software development and is already being voted against by indie and AAA game devs alike. I wouldn't bet against managed languages taking the place currently occupied by C++ in the industry in the near future. Performance already has a lot less to do with the language used than it did 5 years ago. The benefits of languages (like C#) that lend themselves better to software engineering principles, more rapid development, and fewer bugs, are getting more attractive to developers and producers alike.