• 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.


  • Content count

  • Joined

  • Last visited

Community Reputation

121 Neutral

About sankrant

  • Rank
  1. I might rather wait for Rust. I don't have guts to bet on Go. Actually I don't have guts for automatic garbage collection. I will wait for Rust. Till then there's nothing wrong with C++. It just takes time, Much like haskell.
  2. It's like chicken-egg situation. Start using go for non trivial parts. But as you move ahead, you will find that some things are close to impossible You drop to C, and end up using C++.
  3. [quote name='MichaBen' timestamp='1354963602' post='5008459'] Personally I don't mind using something else then C++ for game development, as long as the language has a decent support in terms of tools and libraries, and the language itself is decent enough. I wouldn't mind having a language that doesn't feature any undefined behaviour (everything is either defined or an error) and with pointer safety (dangling pointer protection and leak detection). However, the garbage collector system that several languages introduces is in my opinion not the way to go, as it's a counter-productive method to conceal the symptoms of pointer errors, rather then fix the problems itself. The technology behind garbage collectors is interesting, but it does not belong in a release version of an application, but as part of a debugger, to tell the developer when exactly you are leaking memory, and using a dangling pointer should trigger an assertion you can debug to fix the actual problem, rather then obscure the problem. [/quote] Totally agree. The day there is a real alternative, I will jump ship, but there is not today, and I don't think there is any will to bring up an alternative. People are just fine using C++, if they use it. The fact is, there is no real alternative, and nothing will come up as mid level language, if not counting rust or D, which are far from mature.
  4. I urge the moderator to close this thread and give the conclusive post if possible. I have got the answer, I will use C# for games, but C++ will remain strong in the Engine and Backend development, for long time in the future. That's clear.
  5. [quote name='3Ddreamer' timestamp='1354955479' post='5008433'] kunos, I see that you are quite skilled and adaptive, so you will be just fine with future changes. In 5 to 10 years - more like 3, what you used and issues you faced recently will be gone forever. With all due respect to your abilities and so forth, you seem to have no idea about the revolution coming fairly soon in game development technology. It will be years before the most common languages used in gaming today finally fade into oblivion. However, I am letting people know that immense tech changes are coming on the horizon. Wait until Apple becomes twice or thrice as large as Microsoft with the other tech animals yapping and snapping at the heels of Windows platforms. Microsoft has strength in software innovation and this is what will save them, since they are increasingly outnumbered. Middle level programmers are to a large extent going to be replaced by software and hardware advances. Among the corporate goals is to end the need for much of the line by line coding, once the huge advances arrive. Many current professional programmers think that their C++/C experience is job security. The innovations in automation and code completion, including in C#, will reduce much of the demand for line by line coding and debugging. A new framework in C# must surely be on the horizon which will deliver such innovations if Microsoft is to avoid a collapse. In that case, C++ will prove far too cumbersome for the agile artificial intelligence in the development software of better suited languages for such innovation such as C#. This core .NET Framework language was created with this long range vision from its start as an eventual replacement for C++ in the 21st century. The next framework for C# (based on .NET) will introduce the revolutionary technologies which were conceived in the minds of leading software engineers even before C# was conceived. Didn't you see that XNA was used as a test platform for extending their technology goals to far greater innovations in the next generations? Here is a classic case of people not seeing the forest because of the trees before them. Everybody will forget that 3Ddreamer warned of massive corporate, market, and technology upheavals in game development in the coming several years, but many game coders will be glad that they were inspired somewhere in the mist of time to be ready for the tech storm. However, as credit to you - like I said, your adaptiveness will keep you working. Clinton [/quote] Yeah, OK.... For some reason you think that, C# is the future mega tech. But why C#? Why not lisp? Or haskell. They have the same possibility of displacing C++. Why only C#? Why not Clojure? Or Obj C? Why only C#? Whats so special about C#. Game scripting can be done in Lua too. And engine development has no real alternative other than C/C++. There will be no alternative for a long time. That's clear.
  6. Can you enumerate the game languages of the past please? Assembler? Assembly was left by the Game Devs because we changed the way, the game's were developed. We introduced the concept of game engines to write games. C took the crown. C? We started using C++ because C++ emmerged as a superset, and we could use any C library from C++. C++ : Here the codebase increased to massive momentum. It was adopted as the industry standard for game engines. Fringe languages : Pascal? Well pascal was more productive than C and as fast. Compare it to C#. Basic? Compare it to python. Never intended for game dev. C++ will always (for a very very long time) remain the industry standard for writing game engines. (C++ is much much more stronger in case of the AAA game engines) Practically speaking, C++ is here to stay for enourmously long time, and majorly used, perticularly in the case of development of game engines, if not any other areas. Note : By game engine I mean renderer, physics, script and sound infrastructure which does the heavy lifting. I love C# when writing the actual game (not engine). Don't bother about creating game engines. Create good games with C#. Enjoy.
  7. '' As the hardware gets more powerfull... We will not require fine grained control. Down with C++! '' As the hardware gets more powerfull *OUR Needs will GROW*, and everything now which is called graphically intensive will be called crappy.... '' There will be a time when C++ geeks will be no more. '' Believe me, Earth will be destroyed some day. That's a universal fact. C++ will only die, when we start creating gamse withought a game engine. And microsoft (C++), apple (obj-C) will make sure, that there is a supply of young C/C++ programmers, who will than take charge of the game engines in the future. That's 30 years minimum. C++ is changing all the time, it will get more functional. As platforms like Google Glasses come into play, C++ compilers will be the first to get hands on. Libraries like openGL/DirectX are writern in C/C++. Do you know why? Because most languages have a C API. What about C#? If you use C#, you get locked in to the CLR. Suppose, hypothetically I write my Engine in low-level C#. My team wants to use LUA for scripting. They cannot. This will always be like that till John Carmack is alive. 50 years more maybe? Till there are console games, till we create game engines to program a game C++ will remain the Industry standard, for game engines only. Create games with C#. Use an existing game engine if you somehow hate C++.
  8. [quote name='kunos' timestamp='1354876585' post='5008079'] [quote name='3Ddreamer' timestamp='1354857369' post='5008002'] What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it. [/quote] sadly I don't think it'll go that way. C++ is a very closed relative of C, the 2 can mix in the same codebase and the boundaries between the 2 become quite blurred. C++ allowed C "engine" developers to slowly get use to it without throwing away what they had and was working.. they could experiment with a little of C++ flavor here and there without compromising the structure and without feeling unsafe about it,because they knew they could just switch back to C if and when cornered. The problem with C# is that you can't "inline" C code into it. The boundary between the "native" side and the "managed" side is VERY defined.. devs from one side can't "play" moving stuff here or there.. everything is much more "frozen"... plus you have the marshaling cost to consider every time you want to move something around. To make C# (or any other language) a viable option to replace C/C++ in the game engine realm you need to create a compiler that can seamlessly include .c, .cpp or .cs files IN THE SAME PROJECT. I have more hopes for a C++ evolving into something more C#-ish (add modules and optional GC and you're there) than the entire world to adopt C# for everything. [/quote] C++ getting more C#-ish, is IMHO far from being a reality. Adding optional GC, will make it more like Rust Programming Language. C++ is now stealing ideas from functional programming languages. The world requires and always will require, one and only one mega multi-paradgrim language. I don't see C++ going away anytime soon, from the realm of game engines, and C++ going away is unimaginable in case of AAA game engines. I say, don't bother much. Make beautiful games with C#.
  9. Nobody will bother to make 'a C++ out of C#'. C# is primarily meant for the enterprise, and will be developed in that capacity. C++ is meant for creating underlying high performance infrastructure and low level code. It will be developed in that capacity. So for the future, I will be choosing C++ to make the heavy lifting infrastructure/base of my software (game engine), and C# or my favurate language to make the real part (the game). As an indie, you might be loving to code in C# (as I do), but indie developers do not create game engines for that matter!! (be happy)
  10. Game Engine in C#? Humans are greedy creatures. Every inch of performance counts, and technically C++ will always outperform C#. Its one time investment! System programming != Low level programming. The day someone writes a C++ compiler, as optimised as the present ones, 'in C#'; that day I will say 'welcome new C++'. Why would anyone want to create unmanaged C#? It will give the world another C++. Believe me, we won't switch from C++ in case of Game Engines any time soon. Focus on creating games and use C# if you like. PS : One day, the earth will end, and we will live on mars. But we will still remain human beings.
  11. [quote name='3Ddreamer' timestamp='1354857369' post='5008002'] That is true in general about C++ for engines and C# (or other) for games, but in the case of the languages used for scripting a game, the experience of the game developers will increase, will it not? Since game developers far outnumber game engine developers, the very skilled programmers with slowly but surely find ways - a few of them - of soaking deeper into the previously frozen tundra surface of game engine development. The same thing happened with C++ when it was younger than its lower level siblings being used for engines. We see another set of languages today competing for higher level function in principle just like the previous period of C++ evolution did. What I am saying is that C# and support is evolving to some day replace C++ to a large extent but must go through the same basic vetting process that happened in C++. I expect that C# will do it better in its life cycle than C++ is doing it. If you really think deeply about it, C# is being directed by industry leaders to indeed become the game development leader to surpass C++ some day. Even if they fail at that vision, C# will almost surely be a heavy weight someday in the same ring with C++. It is a matter of growth and training - literally. Remember to think big picture and in terms of the very real industry cycles of technological development. In the non-game world, C# is gigantic. The development software for C# is comprehensive and improving. The massive crop of C# programmers will grow to maturity, ready to harvest someday in a big way in program development. A mass that large will have a large effect, just like real world physics. Clinton [/quote] C++ isn't going anywhere till we use/create game engines. Do you want to know, why we switched from assembly? Productivity was only one of the reasons. The main reason was, that we changed the way we changed the way we created games. We introduced the concept of *game engines*. We started using C/C++, and we are going to use it for game engines until we see a radical change in the way we create games (maybe games withought game engines). Till then live happy. (very very long time). Looking at a larger picture, only a *systems programming languages* like Rust or D can replace C++, if ever. Till then (what? Eternity?) use C++ to write game engines, and use C# or your favurate language to write a cool game. I am doing that, and I do not/will not regret it
  12. [quote name='ranakor' timestamp='1354797916' post='5007739'] What's funny is that 3 little additions to C# (maybe more, but 3 i can immediately think of) could keep all the C# advantages and remove the needs for the bits of C++ - Bringing support for new instruction sets faster - Support for compiler intrinsics in C# code - More control over CG management (ability to manually manage the GC arrays / ability to defragment the LoH) [/quote] I agree to this point, but it's highly unlikely. Also, it will give you another C++, which is not required. C# is looked upon as an enterprise solution by the majority. No Chance. The ring has only one master, and that's C++. If the ring gets to C#, it will lead to the rise of *yet another dark lord* Let C++ and C# remain the best tools in their own domain. (game-engine and game respectively) Edit : Creating Game Engines require low level programming, thus C++ is the haven and heaven there.
  13. [quote name='ranakor' timestamp='1354791845' post='5007720'] [quote name='sankrant' timestamp='1354791063' post='5007717'] Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche. Creating a Game is a different matter, and C# can be efficiently used in that domain... [/quote] And unity's been proving that pretty well. [/quote] Yeah, That's how it is done. And I don't see this changing any time soon... The game engines will have to get more fine tuned (thus C++), and the game itself will need to get better productively engineered (thus C# or more productive things). People will use the right tool for the job, and will have fun. PS: Game Engine != Game. Both are engineered differently and require different kind of skills. (C++ and C# respectively in this case)
  14. Game engines are not created everyday. This is a long time investment, and thus requires really good fine tuning. C++ isn't going anywhere from this niche. Creating a Game is a different matter, and C# can be efficiently used in that domain...
  15. [quote name='Dynamo_Maestro' timestamp='1354355612' post='5005988'] [quote name='sankrant' timestamp='1354331415' post='5005927'] After a kind of resistance in microsoft C# feels like a lag [/quote] What? [quote name='sankrant' timestamp='1354331415' post='5005927'] Nothing matches C++ when CREATING a game-engine [/quote] Maybe for you this is the case, but others have quite happily created their engine either mixing C++ in their code or created purely in some other language WITHOUT issues. [/quote] Other than C++? I like Haskell. Working on mastering it