TIGSource Forums

Hi,

I've been using Löve for some months, I did a whole prototype/working core game with it and it went pretty well.

But today is the day I start needing advanced stuff such as advanced UI with charting capabilities and I'd need much more object-oriented programming features that Lua unfortunately doesn't give me.

The problem with this is:
I don't know where to start exactly. I started writing my basic game engine using SFML and everything is going fine. But there's one thing I'm afraid of: getting bored.

I mean my prototype has about 3000 lines of code and now I need to rewrite them in another language, which is fine to me. But rewriting what I already done sounds a bit boring and I really don't want to dump the project after a month of rewriting. (I hope it won't take a whole month).

So now I'd need tips, advices. Where should I begin? How should I begin? Any past experiences to share?

Thanks and have a nice day!

I'd see if you cant continue to use Love or maybe Moai which is also LUA based.

I doubt porting 3k lines is going to take all that much time, but getting an actual framework and all the other basic functionality in place to be able to port those 3k lines may indeed take quite a while.

Don't use C++. Unless you already have a lot of experience with it (which doesn't seems to be the case according to your post, but maybe I got it wrong) then you really shouldn't make your game with C++. Yes it's a very good and powerful language (and my favorite by far), yes it's very good to make games, but it's a monster. Game programming with C++ will make you run into problems you won't be able to solve if you don't have a strong experience of it already.

What is it that you need that Lua doesn't have ? What do you hope C++ will bring you ? Object oriented programming ? Lua can do that just fine.

Also, creating your own game engine from scratch is MUCH harder than it seems at first.

My advise is as follow : Choose.
You want to finish your game ? Then stick to Lua and Löve.
You want to learn about C++ and game engine architecture ? Then make you own game engine in C++ and be prepared to get your ass handed.

3k lines of code is nothing... Especially considering that most of the work will consist of just rewriting the code to C++ syntax and changing types here and there to the SFML ones. Don't worry, just do it ;)

Thanks for the advices! It's very appreciated.


I totally agree with you on this. Building the engine is going to take a while. It's the part people seems to forget about. I can't simply "convert my code to C++" there's lots of technical differences between the too language. Lua is more of a scripting language so there's no interfaces, class inheritence, etc.

No 3k aren't that huge to rewrite.

I'm still a bit lost, but I'm now thinking more about staying with Löve...

That makes it even easier IMO.

If you don't need C++ then this is probably a good idea ;)

Class, inheritance, multiple inheritance, polymorphism, list, set, arrays... if you can name it then lua can do it with tables. Lua does everything and anything with tables.
http://www.lua.org/pil/16.html (http://www.lua.org/pil/16.html)

All you need is Löve.

Thanks everyone, I decided to keep on going with Löve and instead of reinventing the wheel I will simply try to find alternate way of achieving my goals.

Thanks again!

this.

Lua is much object-capable than C++ as with it you can do true message passing, reflection, composition, and automatic de/serialization.
All things defining "true" object-based models which C++ lacks (well, kludges apart).
C++ is just more Object Oriented, meaning that the syntax wants you to use objects and classes. That's it, more or less.

"True" object models suck... Have you ever used Smalltalk? Absolute crap. It's only really usable for theoretical models of systems.

Why that ? (just curious)

It's quite unreadable, used totally unlike any other programming language used today, you have to use special Smalltalk IDEs written in itself which at least from my experience are not much pleasant to use (maybe Pharo is, but I didn't try it) and using it for any practical applications is IMO out of question.
It can probably be used to prototype some high-level business logic stuff (like bank systems) but seems to be totally unusable for anything else (games, editors and creative apps of all kinds... well I could write here almost everything except business systems). It is just so unintuitive to use.

Every other "bad" language seems to me to be much better - ActionScript, JavaScript, PHP, BASIC, bash, perl... Even assembler is more intuitive to use...

:offtopic

Yeah I remember trying out Squeak (one of these smalltalk ide/environments) it was horriby designed (graphically) and I couldn't understand it at all.
I don't really agree however that that is sort of the only representation of a  'true' object model. It is very strong though on encapsulation and its messages

what about python/ruby/objC ? All of these languages are less academia-only and truly OOP ?

Is OOP really a well defined concept to say that some language is truly OOP?

There is quite a healthy approach to demystify objects, it is even rather entertaining:
ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/pubs/swob.txt
(and this is too http://www.okmij.org/ftp/Scheme/#pure-oo )
Hope, you don't mind reading some Scheme code in those articles  :epileptic:

It looks like Lua's tables are doing something similar to those implementations in the links.

In C++ everything is harder, because everything must be typed properly, with classes, friends, and all other overhead. So, probably, this is why OOP in C++ looks kinda scary.

There are of course other object languages, like "self" or older languages like "Simula" etc. but I doubt they are much better.

Python and Ruby are great but they aren't "true" object languages. They are only object-oriented. They have classes and objects but that's all. In every other way they are structured imperative languages and at least Python also has functional features (dunno about Ruby).
Objective-C is what the name says - C with objects (and messages).

That's hard to answer.

Maybe. But it definitely isn't object-oriented.

But it's immediately clear what is what in the code and which thing does what. And you also get compiler which warns you about everything, finds errors etc.

Exactly. This ends up being much easier in the long run, because you deal with the difficulty up front rather than having to wait until a particular code path is executed a particular way (often by a real-world user) to find out which part of your code is broken.

That's true. I actually agree with both of you guys about the adavantages of static typing. Probably, I did not say it very clear, thanks for emphasising this good side of things.

I didn't say that static typing is better than dynamic typing. Both have their uses. The problem is in the language. Python has dynamic typing and as a result, working in it is very nice and fast (much faster than C++, Java or C#). Smalltalk is something completely different though.

Ah man, I had to take a class in Smalltalk in college.  Least favorite class ever.  At least getting exposed to its syntax came in handy when I learned Objective-C.

Personally, I've never found loose typing to be of that great an advantage.  Maybe I just don't think about the typing speed benefits of having a more compact syntax a la Python.