Game Programming: Part Two - Page 3

On March 05 2012 01:32 PaqMan wrote:
I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.

On March 05 2012 01:32 PaqMan wrote:
I want to start programming and eventually programming games, but only as a hobby. I saw your recommendation about python and I've been reading one of the books on it, but I ran across something else today. Love2D is a framework to make 2d games in LUA. Do you have any experience with it?? I wanted to know if I should keep learning Python or pick up Love and try that out.

On March 05 2012 07:04 CecilSunkure wrote:

I'd recommend Python and PyGame, as I've used it before and loved it. I have never used Lua, but from what I know it's not commonly used on it's own to create games.

On March 01 2012 23:47 nimdil wrote:

I sort of agree.
Flash is already outdated and death is waiting for it. HTML5/JS is basically removing it from the market. Steadily.

Python is excellent language and there are many examples of software written in C/C++ that can be extended with Python so it's worth to take a look.

As for C and C++. I disagree that there is no disadvantage in learning C++ first instead of C. For the following reasons:
1. C++ is fast. C is faster! At least that's how Visual Studio makes the end code - not sure about gcc/g++
2. If you learn C++ you won't learn C specific approach to programming. Namely you will focus on creating/removing objects instead of allocating/freeing memory. That's actually significant difference in terms of performance. Also you won't be that used to using pointers. C background may very well let you implement algorithms more efficiently.
3. If you start with C++ you will probably never revert to pure C - in some way you will never know C. The other way around is not true - however - as surely (especially in programming games) you will want to start using OOP - so C++.
4. Finally - C is easier. There is less stuff to learn. If you want to learn some architecture specific stuff (like parallel programming) you should go with C. Once you are proficient with C you can expand with C++ - this way you can always fall back on C experience.

On March 05 2012 08:54 sluggaslamoo wrote:
I've been on the big programming thread and met quite a few python fanboys here and there but I don't know what everyone's fascination with python is, most if not all people who love python have also not been very knowledgeable programmers in my experience. Most python fanboys don't even know how the GC works, which I believe at least understanding the cyclic referencing problem is important (although no longer a problem apparently). I mean its alright but I just see Python as pretty weak with nothing really special about it, it barely even classifies as a multi-paradigm language these days.

I would prefer to write in any other dynamic language over Python. Haskell, Ruby, Lisp, Smalltalk, Lua, Javascript, any. Okay maybe not PHP but you get the picture.

Though I see Coffeescript (using V8 Javascript engine) as the best language for making games in this day and age. V8 Javascript is very very VERY fast compared to other dynamic languages, and Coffeescript is like Ruby syntax with Python-style context sensitive whitespace and Javascript's beautiful functional paradigm at the core. Just seems like a language with a lot of potential.

http://coffeescript.org/



Lua is a great language, I don't see anything wrong with it for hobby game making. Its is widely used for non-performance-intensive stuff, and not for core engines because 1. C++ libraries already exist for it and 2. its slow compared to C++. If you are not coding Mass Effect 3, then Lua is definitely a viable option.



You don't use a lot of the OOP features of C++ for games unfortunately because of performance, every nanosecond counts, and that includes micro optimisations.

Really you are writing uglified C in C++, purely for speed reasons. I love C, but I really don't like C++ heh.

On March 05 2012 19:01 nimdil wrote:
What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.

On March 05 2012 19:01 nimdil wrote:

What kind of games are we talking about? I can't imagine anyone coding game like Hom&m without some OOP. And if you don't use OOP why bother with C++ - ISO C seems to be a lot clearer and more efficient.

On March 06 2012 08:44 ShadowWolf wrote:
Most game engines are written in C++ with some of the more performance critical parts written in ASM or C as is required. E.g. Source, Unreal Engine, Unity, etc. There are very few engines still written entirely in C and more engines are farming off the less critical pieces to C# and other more RAD oriented languages (LUA and Python also very popular I hear - not sure on that one).



C unquestionably becomes a lot harder to read as compared to other languages as the complexity of the application increases and the efficiency increase is not necessarily always even there. The whole reason C++ was invented has to do with improving maintainability while representing a business problem with a higher degree of accuracy. In general, outside of specific circumstances that should be obvious, C and C++ are basically around the same performance level. On a Desktop PC you're not exactly dealing with a situation where a template class or something is appreciably killing your machine.

I mean, compare the Quake 2/3 (written in C) source to the ID Tech 4 (written in C++) source code.

On March 06 2012 13:21 ShadowWolf wrote:
C++ is a powerful tool and like all powerful tools it has the potential to let yourself walk in to huge pitfalls - incidentally C and C++ share common ground here. I personally believe that C++ makes it a lot harder to shoot yourself in the foot as long as you're familiar with how a language that isn't pure works - i.e. careful use of overloads, RAII for life, sensible design patterns, thought about the direction of your systems. Admittedly, a the worst examples of C++ are far more obtuse than the worst examples of C, but that's because there's nearly no limit to how many coding patterns you can combine together at any point in C++. I mean, you can (to some extent) see this if you follow a lot of C# code - between LINQ and some of the new stuff plus the DLR you can do some pretty nonsensical stuff. But I mean, I don't think there's anywhere near sufficient evidence to say that the language is designed poorly. There are features of the language that are designed poorly, e.g. Exceptions; however, I don't feel that's sufficient that you can paint a broad brush.

C++ became the de-facto standard in many places because it's easier to make sense of than C code. I'm not sure your source of experience, so I'm not going to comment about your specific situation; however, in general it stands that C++ code is more maintainable and more accurately represents in a clear-cut manner the problem being solved as compared to straight-C. That said, there are several modern, maintained compilers that support C99 and some even already adding support for C11.

C was used in games for quite a long while after C++ was standardized. The reason I suggested you to compare is because the Quake2/3 source code is messy and repetitive whereas the ID Tech 4 source code uses OO concepts to eliminate and specialize classes - you should see some of their internal helper's migration to use of templates and what-not. The point was it's a decent example of how migration helped clean up their code. It's not like it's a pinnacle of quality - there are classes with over 100 members in there, but it definitely does the job at a level that most games cannot.

Also, if you look at basically any commercial game's source you'll see design patterns all over the place. Dynamic Arrays (you used ArrayList, I think you meant this?) are commonplace anymore with specialized allocators for the objects that require them. A lot of times you'll see re-implmenetations of STL library stuff because the STL can be a little too heavy-weight for many types of games (or you need more granular control).

The major reason that all the APIs might look C-like in Galaxy is because C-style functional syntax is arguably easier to create. I know if I were creating a scripting engine then emulation of either C or Javascript is where I would start just cuz it's simple, bare-bones, and the few commercial lexers I've seen come with support out of the box. But I'm not familiar with Blizzard's development on Galaxy so I'm guessing here.

The point I'm trying to make is that C++ isn't a panacea but it's not a pox either. C and C++ both suffer from many of the same pitfalls, but I (and many others) feel that the increased type-safety, objects, and generic programming concepts improve the design of your code and help express your concepts in a more robust, maintainable, and functional way. And, really, that's what it's all about because even in a single-release game cycle you better believe at least some components of your code are going to be re-used - especially as models like F2P and whatever you call "social media" style games like the ones you see on Facebook become more profitable. Or even just consider franchises like Call of Duty and whatever - those games aren't made from scratch every time. Going back to my own example: There's holdovers from ID Tech 3 in ID Tech 4.

That said, some really interesting insight on the topic can be gleaned here: http://www.team5150.com/~andrew/carmack/ Though I don't think he ever did write his .plan on migrating from C to C++.

A lot of times you'll see re-implmenetations of STL library stuff because the STL can be a little too heavy-weight for many types of games (or you need more granular control).

The major reason that all the APIs might look C-like in Galaxy is because C-style functional syntax is arguably easier to create. I know if I were creating a scripting engine then emulation of either C or Javascript is where I would start just cuz it's simple, bare-bones, and the few commercial lexers I've seen come with support out of the box. But I'm not familiar with Blizzard's development on Galaxy so I'm guessing here.

Admittedly, a the worst examples of C++ are far more obtuse than the worst examples of C, but that's because there's nearly no limit to how many coding patterns you can combine together at any point in C++. I mean, you can (to some extent) see this if you follow a lot of C# code - between LINQ and some of the new stuff plus the DLR you can do some pretty nonsensical stuff. But I mean, I don't think there's anywhere near sufficient evidence to say that the language is designed poorly. There are features of the language that are designed poorly, e.g. Exceptions; however, I don't feel that's sufficient that you can paint a broad brush.

On March 06 2012 15:32 ShadowWolf wrote:
I don't know why you can't believe a list wouldn't be the proper choice. I'm not sure what you're imagining, but a vector that's sized out is quite efficient and access to items on the vector are quite reasonably fast. I think you're imagining a lot of complexity to exist that doesn't actually exist. The list is a perfect choice and optimizing it to be effectively just as fast is trivial in the gaming domain. The impression I get from your writing is the last complete exposure you had to C++ was circa Visual C++ 6.0, which, if true, totally justifies your views. If that's the case then they are dated and should be updated. If that's not the case then you seem to have a lot of misguided impressions about how inefficient C++ really can be, which totally makes sense because most people don't re-check their assumptions - especially if you're talking to game developers. I know and have discussed with a few of them myself and a lot of times they do the things they do because they know they work, they have worked in the past, and they (basically) always will work. It's a completely sensible viewpoint, but in terms of discussing with people just learning you'd probably want them to learn the new skill set in additional to familiarizing themselves with the old one so they have a more marketable set of skills.

I think you misunderstood my point about Galaxy. Functions that look and feel like C functions are just plain easier to write. Arguments are more simple, there's no real complex data structures that need to be passing, and you're probably going to be able to augment the language more easily. I didn't mean to suggest that they used C or even C-interfaces. Just that using things that look similar to C is extremely common in my experience. SMFL is a library and doesn't seem to be relevant to proprietary external scripting interfaces and why they might look very C/JS-ish. That said, a couple of google searches confirmed Galaxy is 100% based on C style syntax.

Eh, I mean, Ruby is a cool language. It also has limitations. It's probably a superior entry-level language to C++. It's also unquestionably slower, less flexible, and possibly has fewer core-language enhancements in its future. From what I've learned of Ruby, it's probably one of the better languages (up there with Python) in terms of getting stuff done well in not a lot of time with decent quality. That said, I'm not sure what you mean by your complaints about C++.

I mean, I have a million gripes about the language of C++, but some of that stuff you listed off is naught more than personal preference and doesn't make a strong argument for why C++ is awful, just why C++ is worse than Ruby in some specific areas. And that's fine - I mean, the fundamental concept of application development and improving hardware is that we can abstract ourselves from low-level concepts like what C++ requires that you focus on.

But that's neither here nor there. The exception I had to what you posted was that C++ produces generally inefficient code when put side-by-side with C and is harder to maintain than C. I'm interested in demonstrating that neither of those, again emphasizing the "in general" part even in a game - you'll probably have some straight-C code around very select portions of your engine for a while longer, is true. There's a sort of weird C > C++ perspective that I don't quite understand and it seems to be based on things that haven't really been true for a while.

Also side-note: if you're developing on MSVC then that's the equivalent of saying "I know car engines really well because I work on a '94 civic." Yeah, it's definitely still a Car (C89/90) and you'll probably pick up the necessary bits to figure out an '09 Civic (C11), but it's so old and dated that you're missing a lot of cool stuff.

void swap(int *a, int *b)
{
  int t=*a; *a=*b; *b=t;
}
void sort(int arr[], int beg, int end)
{
  if (end > beg + 1)
  {
    int piv = arr[beg], l = beg + 1, r = end;
    while (l < r)
    {
      if (arr[l] <= piv)
        l++;
      else
        swap(&arr[l], &arr[--r]);
    }
    swap(&arr[--l], &arr[beg]);
    sort(arr, beg, l);
    sort(arr, r, end);
  }
}

<<partition>>=
template<typename IT> 
IT partition(IT begin, IT end, IT pivot)
{
	typename std::iterator_traits<IT>::value_type piv(*pivot);
	std::swap(*pivot, *(end-1));
	IT store=begin;
	for(IT it=begin; it!=end-1; ++it) {
		if(*it<=piv) {
			std::swap(*store, *it);
			++store;
		}
	}
	std::swap(*(end-1), *store);
	return store;
}

qsortOneLine s = case s of{[]->[];(x:xs)->qsortOneLine [y | y<-xs, y<x] ++ x : qsortOneLine [y | y<-xs, y>=x]}

On March 07 2012 19:06 opsayo wrote:
Cecil do you recommend anything for python besides pyGame? I love python but pygame looks pretty ghetto (installing it for a 64-bit Mac OS is not elegant).

On March 07 2012 19:06 opsayo wrote:
Cecil do you recommend anything for python besides pyGame? I love python but pygame looks pretty ghetto (installing it for a 64-bit Mac OS is not elegant).