vleugel

You should start by defining what you actually want to achieve, as soon as you have this clear you can ask more specific questions.

For instance, do you want to produce apps for the iPhone? In that case Objective C is the way to go and I would advice to get yourself a mac and use Apple's tools for the production. For Android, Java is the way to go and Eclipse is a good tool (IDE) to use. For Windows/Linux programming, I would advice to start with something like Python and perhaps move on to C/C++ later on. If you want to focus purely on Windows and especially applications and not games, I think C# is by far the best choice for a language in combination with the excellent Visual Studio IDE.

Although these are rough generalisations and are open for debate (better not ), I just want to point out there is no such thing a 'the' best language or tool. It totaly depends on your requirements.

You cannot produce an 'abstract object' at all, abstract classes are used for inheritance, as interface for a concrete class derived from it.

If Object and Goods are in fact not abstract, just use 'Target = new Goods()' and 'Actor = new Objects()' into the constructor or something if thats what you want (although I would probably just use static objects by deleting the asterisk if thats your plan).

Well I voted you up KnolanCross, simply because I don't think you deserve negative points.

I too think Python isn't the right choice for a project like this. I'm not saying it cannot be done, but I simply think there are better alternatives.

Although I would not advice him to use C++ either. Why not using C# for both server and cient? Its easy to learn and it makes interaction with the C# client easier too.

I think it will increase productivity and performance in the end. Just download Visual studio 2012 express and play around with the language. I think on a project of this scale it really doesn't hurt to spend some extra time figuring out the alternatives, you can easily learn the basics of C# within a couple of hours. If you really mastered the Python language it might be a different issue, but my intuition tells me its not like you're using it for years too. It never hurts to learn and use a new language in my opinion, and if it doesn't work out you can always drop it and go back to Python.

I don't think a beginner is really considering all kinds of low-level stuff when he talks about a game engine. And telling him to just code the game without thinking of the engine, might let them think they should rush into programming the game logic and skipping a good game design. But I tend to agree to most points of the last posts here and in the end it might actually be a good thing if you let the beginning programmers find out their code is not re-usable, so they can learn from their mistakes

Servants post very cleary states the opinion of most people here: make a game not an engine.

Although I agree with most of its points, I personally think it is a good idea to start with the engine.

The question to ask yourself is; what is an engine?

I like Servants definition; reusable components fromt the game.

Although everyone has its own programming style, I personally don't think you should start with the game logic of the game without getting any visual output.

I like to start setting up the core components in order to draw a screen, implement all input/visual/audio APIs in an easy to use manner, setting up a basic gamestate system, entity manager incl. messaging etc. etc. I think this is actually a good programming behaviour, start by making a planning and design of what you actually need for your game. For instance in the first game you make you could decide to leave out the audio and you could just use if-statements for handling the gamestates.

Later one when you make another game, you can then re-use these core components of your game for the next game, while slowly introducing something new (if you feel that you actually need it or makes development easier), such as a scripting language. If you implemented something in the engine and you don't need it for the next game, you can just leave out these code files.

I got the same advice when I started: make a game not an engine. But after finishing a couple of games I felt like I realy couldn't re-use much of my code.

Mostly because I thought things weren't done efficiently or weren't easy to use. At that point I started doing things the way I described above, using carefull design and starting from the ground up and now I can just use this framework I made and start coding the game almost right away.

So to summarize my advice: spend some time making a good design, if you write a very good reusable piece of code it'll safe time in the end by avoiding having to recode everything again. But don't try to implement all kinds of features you're not going to use in the current game, you can easily implement those features as soon as you write the game you'll need it in.