Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 02 Mar 2007
Offline Last Active Sep 07 2012 03:57 PM

#4803504 Slightly concerned about my programming style

Posted by on 27 April 2011 - 06:08 AM

Computing Science degree is not supposed to make you memorise everything to the letter and sing it out when called upon. The one most important thing you learn at the university is problem solving and flexibility in using available resources to your advantage to solve problems in a given area (in this case CS). Of course, you are expected to be fluent with certain concepts, but no one expects you to know every single data structure by heart. If you haven't heard of the skip lists - no problem, as long as you are able to learn about them quickly and use them appropriately.

It doesn't matter if you learn about it from books or Google. In some ways searching the Internet is preferable, as it is faster, way faster. There is of course the overhead of the risk of finding an incorrect explanation, but you should be able to reliase that soon enough. Plus, you still need to make sure you are able to navigate books and papers - their language might be more complex in some instances, but they offer deeper insight and sometimes the Internet isn't there to save the day.

So - be a flexible, quick learner. Also don't hesitate to ask questions if you don't know something or are unsure about something. Some may perceive it as a weakness or lack of knowledge, but it is neither. Sometimes it is better to ask a senior colleague, than google something - the answer is almost certain to be correct and fit the context of your work and hence the question you asked.

#4798709 Creating a unique id for each unit

Posted by on 15 April 2011 - 03:12 AM

Definately go with a const dword id concept, rather than toying with memory addresses and I suggest you consider saving the ids, instead of re-generating them - it just makes things easier and avoids problems that you may encounter if trying to recreate entities with their ids in a specific order. It'd also allow you to store references to other entities via their ids, rather than pointer handles or another representation that'd have to be re-evaluated upon loading the game.

#4797053 C, C# or C++?

Posted by on 11 April 2011 - 05:32 AM

From my experience with university and self taught programming, I'd strongly recommend that you start by learning C. I mean pure C, not C++. This way you start with a simpler, structural language and without the overhead of oop you can focus on learning how to use a language properly in its simplest form and also how to be reasonably efficient and save in regards to memory handling. As a lower level langauge than C# or Java or even C++ (in some ways) C also forces you to learn more about how compilers work and what they actually do to the code you write and how to make the most of their capabilities. I wouldn't recommend using C for anything practical, apart from some training, instead - think of it as if it was Latin - a dead language (not true in case of C, but just bear with me :)), but also the foundation of most of European languages. You can't really chat up foreigners with it, but it will make it easier for you to learn any modern, European language. In case of C - modern oop languages, of course.

Once you get there, jump over to C# or Java. I'd recommend C# for a variety of reasons, but it is my personal choice - some people prefer the latter. C# is definately a good language for learning oop, easy to get into and manipulate, enjoyable and most of all it is ready for production - grab XNA (or SlimDX or whatever) and you can start writing games. If that fulfills all your needs, I'd stick with i - If it ain't broke, don't fix it. If that's not the case (you want more efficiency, use only C++ compatible engines etc.) only then progress to C++.

However, as proven by a number of replies, there are different schools of thought on the subject. You will probably end up finding your own way, just remember not to be sceptical about anything - some people will tell you that C# and Java or Z [input another modern programming language of choice here] are rubbish, for X and Y reasons. In the same manner, C programmers used to bash C++ and C was loathed in its time, as well. Just give whatever interests you a go and don't get disencouraged, because of other people's opinions - sure, they might turn out to be right, but they may also turn out to be simply ignorant, arrogant or both.

#4797043 C++ Books?

Posted by on 11 April 2011 - 04:54 AM

I'm surprised no one has mentioned (unless I've missed it, in that case apologies!) Effective C++: 55 Specific Ways to Improve Your Programs and Designs by Scott Myers. It's not a tutorial, though - it targets people with intermediate knowledge in C++ and helps in improving your code in many (55 actually) ways. It's a definite must read for C++ programmers. I was first told to read it by my colleagues at my first game dev job - I've been a better C++ coder ever since ;)

#4791631 Engine Programming

Posted by on 29 March 2011 - 02:16 AM

Hi, I read through that article and I understand it completely. I've been wasting my time trying to figure out the ugly innards of OpenGL 4.1 and Direct X 11 with no real sense of achievement.

I didn't understand the last part of the article however. Do I choose a pre-existing engine such as UDK or Unity and write a game or make a game from scratch building on the foundations of the game engine as needed?

Both ways are perfectly valid. Since the article article attempts to encourage a shift from engine-first development to writing games, their suggestion is more of the second option. Write a game and get the next one running on some reusable parts of the first one. And so on, until you end up with several reusable systems that you can bundle together and call them an engine. However, unless you want to challenge yourself or are really hell-bent on writing an engine, it's probably better to pick an existing engine, with some kind of track record and community, and use it to make great games.