Posted by Sacaldur
on 11 September 2013 - 11:12 AM
You could try Mono (.NET for other platforms) and MonoDevelop (an IDE). If you're familiar with C#, you might want to have a look at Unity, too. Using Unity you're able to create 3D (and also 2D, but many people doesn't like Unity for 2D) games quite fast.
Posted by Sacaldur
on 06 September 2013 - 05:44 AM
jbadams and David Ga11agher already pointed out the important things so I don't have much to say about the possibility of these projects. But I want to add one point: don't focus to much on the genre! The genre says some kind of nothing about the final game as mentioned in one of the Extra Credits Episodes (I'm not sure about which one it was, but you could have a look at Extra Credits: Combining Genres). In an other episode if not the same they mentioned the difference between genres in film and literature. When you see a movies genre you know quite exactly if the movie is interesting for you while game genres focus on a specific mechanic or the point of view (_first person_ _shooter_, _plattformer_ (btw: in other locations referred to as "Jump'n'Run"s) and so on). I'll have a look fore the right EC video later...
As mentioned: the content will take a lot of time so you should not make a game which depends on much content. Shooter, RPGs and adventures (also action adventures) need much content to some extent. (Local) multiplayer games doesn't need much content or much mechanics in general to be very enjoyable. You may could have a look at these games. ;) And don't forget about the sound and music!
Oh and by the way: Zelda is not an RPG, it's an action adventure! (Except for Zelda II maybe...)
Posted by Sacaldur
on 05 September 2013 - 09:08 AM
(I have to admit I didn't read everything...) There are some slightly different statements which should not be mixed up.
1.) Global variables are bad. They infringe the object oriented design, no one likes them, and they don't have any friends! 2.) Dependencies should be validated during the objects initialization by passing corresponding objects as constructor arguments or by initializing them inside the constructor. There should be no initialization Method to be called from the outside after the object was created. The object already has to work. 3.) Other stuff, the object ist not dependent on should not be passed to the contructor.
In my opinion the 1. statement is true. There are in most cases other different and better solutions. While talking about the 2. and 3. statement it's important to know what is an object depending on and what it is not depending on. A player may need to know his environment (map/level/world/...), but a wizard wand or warrior sword refining machine doesn't depends on these objects the same way. Thats why the world may should be a players constructor parameters, but a weapon should not be a refining machines constructor parameter - instad it should be the "refineWeapon"s method parameter.
An other example for a dependency could be Character and the CharacterState's subclasses. A character always needs to know his state - what the character is doing. "Nothing" could be one of the subclasses so a null pointer would be an invalid state. The constructor should set an initial state no matter if there is a parameter for the state or not (the questen would be: is there a default character state in your game?). A SetState Method would still be a valid possibility, but it's not a setters job to initialize the object.
In my opinion passing an object to the constructor and passing an object to a method are suitable for different cases. Both should be used, but not exchangable.