|
Thread Rules 1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution. 2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20) 3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible. 4. Use [code] tags to format code blocks. |
On March 01 2013 09:23 tofucake wrote: No. Ruby is awful.
I wouldn't go that far, but it is subpar as a beginners language. A lot of weird edge cases and strange language idioms. Personally, I'm partial to Python as a beginner's language.
|
On March 01 2013 14:22 thedz wrote:I wouldn't go that far, but it is subpar as a beginners language. A lot of weird edge cases and strange language idioms. Personally, I'm partial to Python as a beginner's language.
As my friends would say, Python Master Race.
Java as a beginner's language is okay for being very functional, but it's held back by introducing all these magical paradigms that no beginner can understand. C# is about the same. C is okay if you have a good instructor that can teach you why things are why they are, and teach you the transition from C to C++. C++ is okay in general. Python has basically everything and no craziness except for spacing.
Scheme is okay I guess, except for how much recursion you to do. All these Lisp languages feel more like things you learn after the basics are over with.
Ruby feels very Pythonic, but with a lot weirder rules that make it less intuitive I think. Golang is cool, but a bit too weird with the formatter to start off with.
Everything else is a bit too out of mainstream that it can really hurt a programmer when he has to re-learn another language later before he can have more fun. That's why I recommend Python.
|
On March 01 2013 09:22 Savi[wOk] wrote: I was wondering if the programming language "Ruby", was a good language to learn for a beginner even If I don't plan on looking at rails. Ruby is fine as a beginner's language. Since you've asked a lot of similar questions in here, I'd really encourage you to stop thinking so much about how you want to begin and just do *something*. Whether you start with Ruby or Python or Javascript or C# or whatever else, you'll learn at least something and if you don't like it or have trouble with it, you can always try something else later.
|
I wouldn't recommend learning a weak-typed language to start. Try Java, C# or C++ IMO (C# would be my person recommendation, but it was the first language I learned so I'm a bit biased).
|
On March 01 2013 09:22 Savi[wOk] wrote: I was wondering if the programming language "Ruby", was a good language to learn for a beginner even If I don't plan on looking at rails.
Yes, Ruby is awesome ! I strongly disagree with others in this thread - Ruby is not complicated language, it is a programmer that adds complexity to programming. As for Ruby, it is just very, very rich language and you can learn many programming styles and techniques with the same language. You can do scripting with Ruby, you can do procedural programming, you can do object oriented programming (and Ruby is pure), you can do a bit of functional programming ... Plus, it is definitely beginner friendly, syntax is (in my opinion) most reasonable and nice from all other languages (I swear, all of them have their perks but Ruby) and it follows "principle of least surprise", which is true if you don`t expect Ruby to be your <fill in your favorite language>. Hell, you will even learn pointers, since Ruby doesn`t have pass by value.
|
On March 01 2013 17:02 killa_robot wrote: I wouldn't recommend learning a weak-typed language to start. Try Java, C# or C++ IMO (C# would be my person recommendation, but it was the first language I learned so I'm a bit biased).
Python is generally considered a dynamic strongly-typed language.
|
On March 01 2013 02:13 Tobberoth wrote:Show nested quote +On February 28 2013 23:22 FFW_Rude wrote:Hi, First time in this thread. Hope my question falls into it nicely because it's not really programming... So i just passed from mysql to postgresql and there is something that i don't really get. I have all of the "intranet" (at work) on mysql in different database (basicly i have a database with the intranet and i have a database for each of the application that are inside the intranet). But i was wondering on postgresql if it was better to do a BIG database with schemas ? For exemple a database "intranet" with schemas like "application1","application2" etc... instead of having 3databases labelled intranet,application1,application2 Don't know if it's really understandable and sorry for the bad english  I guess it depends on how interconnected those schemas are. If Application 1 and Application 2 really don't have all that much in common (such as users) or don't use each others data too often, it makes sense to me to have different databases, since that simplifies backups, restores, and even stuff like maybe needing different collations. Hell, you might want to split the applications up to different servers later, which will be hard if both applications are part of one big database. Isn't it more common to use schemas to "group" several individual databases anyway?
That's what i thought but i wanted a confirmation. Because i was asked to do all in schemas and i was not really agreeing to that. Now i know that i can contest freely 
Thank you good sir !
|
On March 01 2013 08:45 Ilintar wrote:Show nested quote +On February 28 2013 03:32 Tobberoth wrote: This is a more theoretical and simple question, but I'd love some input, it's something I've been pondering since I learned OOP principles ages ago.
Let's say I'm making a console-based adventure game. I have a world class which handles command inputs from the user. The world class has a map (2d array of room objects), a player object and obviously lots of other stuff. Now let's say the user inputs the command "south". Thinking object-oriented, I go "Ok, so I want my player object to do a move method". At first, this makes sense because the player has a struct with an X and a Y position. However, obviously I need to make sure that the player doesn't walk outside of the map. The conundrum is, the player object doesn't know about the map, which the world object has.
The are two solutions I can think of, and I sort of dislike both: 1. Let the player know about the map, by sending in a pointer to it in the players constructor. Now, the player can check for himself if there's a room at the end of the Go command, else return that movement was impossible. Problem of course being the stronger coupling between the player class and the world class. 2. Don't let the player move, let the world have a MovePlayer method which does the map-checking etc and then updates the player objects position. Now the player is completely uncoupled from the world, but following this logic, the World class will become a BEAST which will have to implement pretty much everything done in the game. To use an OOP term, the cohesion for the world class will become very low if it has to handle every other object in the game.
How do you guys feel situations like this are best solved? It seems like it's impossible to hold to strict object-oriented guidelines without making pretty much every class know about every other class. If you want to take the example farther, let's say you have so many commands that you want some form of command-parser class... now, should suddenly the command-parser be coupled to all the other objects it needs to handle when dealing with commands? There is a standard design pattern within the OOP world to handle exactly this type of functionality - events. Events are a way for the object-oriented paradigm to handle non-locality. The problem is exactly as you mentioned: you have local objects that want to possibly update other objects via some sort of common interface, but it's against the OOP paradigm to have objects know about every other interconnected object out there, because separation is a key part of the paradigm. The solution is to have a Controller object that specifically registers events. Events are objects that basically say "something happened". Then, one has event handlers. Event handlers are basically special function-like objects (delegates - another nice and useful design pattern) that basically take an event and do something with it. Event handlers are registered - objects let the Controller know that they would like to respond to things of type X (in your case, MovePlayer). Therefore, instead of a direct communication: * player moves, updates state locally * player messages all relevant entities that it moved you have indirect communication: * at initialization, the Map object registers a handler for PlayerMove events * player moves, signals a PlayerMove event * controller polls all handlers it has registered, seeing if any of them handles PlayerMove events * the Map object's registered handler says "yes, I want to do something about the PlayerMove event" The nice thing about events are that they live within the OOP world - for example, you can have an event type hierarchy. Say you have PlayerMove events, but you also have MonsterMove events - both of those might be a instances of the ActorMove event class (which might be handled, say, by the collision detection engine, who doesn't care if the Actor is a Player or a Monster). There are also subtleties about events (for example, the event calling queue - you can have handlers that override or cancel out other handlers, or modify their calling parameters, you can have events that themselves generate new events and so on), but there's a ton of literature out there on the topic, so you just have to read it :> Hmm, I never really thought about using events in a game like this, that's pretty interesting. I wonder what that will do to performance though, and how dangerous it might be, because you might become confused over in what order things happen when it's done using events, you'll probably get very long chains of events. Let's say there's a PlayerMove event, which monsters need to react to (maybe the game only lets monsters move when the player moves). So the player moves, which sends the event, and a monster moves... however, the MonsterMove ALSO sends an event, which some other object might listen to. Now you get a chains where player move -> Monster1Move -> object1 responds to event -> object2 responds to event -> Monster2Move -> object1 responds to event -> object2 responds to event. And so on. Question is how this will affect performance.
|
Poland794 Posts
There's no inherent overhead to using the event model. What you're describing here are just issues with your game's internal logic that came to light because you started thinking in terms of events. Imagine you instead did it by having a method in the Map object called playerMoved(). Then, the exactly same problem arises - if the game only allows monsters to move after the player, then you have a collection of Monster objects kept in the Map object and you have to send moveInResponseToPlayer() to each of those objects. Now, say each Monster object calls Map::monsterMoved()...
Generally, you have to free yourself from thinking that you're going to be able to make a game with a simple communication model. RPG games routinely handle hundreds of events at once - you are not supposed to tinker with each singular event chain, you're supposed to program it so that either the order is guaranteed (eg. by introducing handler priorities) or that it doesn't matter.
Also, about the order being confusing - in real time RPG games, there's no such thing as an "order" of events, as the events occur asynchronously from each other. The big benefit of this is you can use the multiprocessor architecture of the new systems by spreading the handlers onto separate threads, the problem is the same as always with multithreaded programs - you have to be wary of synchronization issues.
|
On March 01 2013 19:47 Tobberoth wrote:Show nested quote +On March 01 2013 08:45 Ilintar wrote:On February 28 2013 03:32 Tobberoth wrote: This is a more theoretical and simple question, but I'd love some input, it's something I've been pondering since I learned OOP principles ages ago.
Let's say I'm making a console-based adventure game. I have a world class which handles command inputs from the user. The world class has a map (2d array of room objects), a player object and obviously lots of other stuff. Now let's say the user inputs the command "south". Thinking object-oriented, I go "Ok, so I want my player object to do a move method". At first, this makes sense because the player has a struct with an X and a Y position. However, obviously I need to make sure that the player doesn't walk outside of the map. The conundrum is, the player object doesn't know about the map, which the world object has.
The are two solutions I can think of, and I sort of dislike both: 1. Let the player know about the map, by sending in a pointer to it in the players constructor. Now, the player can check for himself if there's a room at the end of the Go command, else return that movement was impossible. Problem of course being the stronger coupling between the player class and the world class. 2. Don't let the player move, let the world have a MovePlayer method which does the map-checking etc and then updates the player objects position. Now the player is completely uncoupled from the world, but following this logic, the World class will become a BEAST which will have to implement pretty much everything done in the game. To use an OOP term, the cohesion for the world class will become very low if it has to handle every other object in the game.
How do you guys feel situations like this are best solved? It seems like it's impossible to hold to strict object-oriented guidelines without making pretty much every class know about every other class. If you want to take the example farther, let's say you have so many commands that you want some form of command-parser class... now, should suddenly the command-parser be coupled to all the other objects it needs to handle when dealing with commands? There is a standard design pattern within the OOP world to handle exactly this type of functionality - events. Events are a way for the object-oriented paradigm to handle non-locality. The problem is exactly as you mentioned: you have local objects that want to possibly update other objects via some sort of common interface, but it's against the OOP paradigm to have objects know about every other interconnected object out there, because separation is a key part of the paradigm. The solution is to have a Controller object that specifically registers events. Events are objects that basically say "something happened". Then, one has event handlers. Event handlers are basically special function-like objects (delegates - another nice and useful design pattern) that basically take an event and do something with it. Event handlers are registered - objects let the Controller know that they would like to respond to things of type X (in your case, MovePlayer). Therefore, instead of a direct communication: * player moves, updates state locally * player messages all relevant entities that it moved you have indirect communication: * at initialization, the Map object registers a handler for PlayerMove events * player moves, signals a PlayerMove event * controller polls all handlers it has registered, seeing if any of them handles PlayerMove events * the Map object's registered handler says "yes, I want to do something about the PlayerMove event" The nice thing about events are that they live within the OOP world - for example, you can have an event type hierarchy. Say you have PlayerMove events, but you also have MonsterMove events - both of those might be a instances of the ActorMove event class (which might be handled, say, by the collision detection engine, who doesn't care if the Actor is a Player or a Monster). There are also subtleties about events (for example, the event calling queue - you can have handlers that override or cancel out other handlers, or modify their calling parameters, you can have events that themselves generate new events and so on), but there's a ton of literature out there on the topic, so you just have to read it :> Hmm, I never really thought about using events in a game like this, that's pretty interesting. I wonder what that will do to performance though, and how dangerous it might be, because you might become confused over in what order things happen when it's done using events, you'll probably get very long chains of events. Let's say there's a PlayerMove event, which monsters need to react to (maybe the game only lets monsters move when the player moves). So the player moves, which sends the event, and a monster moves... however, the MonsterMove ALSO sends an event, which some other object might listen to. Now you get a chains where player move -> Monster1Move -> object1 responds to event -> object2 responds to event -> Monster2Move -> object1 responds to event -> object2 responds to event. And so on. Question is how this will affect performance. This is exactly my problem with an event-based system. Events are excellent for loosely-coupled, independent behavior in subscribing classes. Parsing a move command, though, isn't loosely coupled like that: "move south" is always going to mean exactly "shift the player object's position one room southward from its current position." The only object that should respond to the command directly is the player (or whatever handles moving the player around). In my mind, that should be handled by a direct call, otherwise you've got a single-subscriber event that logically shouldn't get more subscribers, which decreases code readability to no advantage.
What would make sense to me for events would be "beforePlayerMove" and "afterPlayerMove", triggered at the beginning and end of player.move() so that, for example, a monster might automatically attack a player that walks into the room it occupies, or so that a door can slam shut as a player tries to walk through it.
I'm trying to think of a good way to describe how I see the difference, and I think it's this: Events should be used to inform the world that something has happened. Making the thing actually happen should be triggered by direct communication. So make a player move by calling player.move(), let the universe know about the player moving by triggering beforePlayerMove and afterPlayerMove.
|
Poland794 Posts
On March 01 2013 21:00 AmericanUmlaut wrote: This is exactly my problem with an event-based system. Events are excellent for loosely-coupled, independent behavior in subscribing classes. Parsing a move command, though, isn't loosely coupled like that: "move south" is always going to mean exactly "shift the player object's position one room southward from its current position." The only object that should respond to the command directly is the player (or whatever handles moving the player around). In my mind, that should be handled by a direct call, otherwise you've got a single-subscriber event that logically shouldn't get more subscribers, which decreases code readability to no advantage.
What would make sense to me for events would be "beforePlayerMove" and "afterPlayerMove", triggered at the beginning and end of player.move() so that, for example, a monster might automatically attack a player that walks into the room it occupies, or so that a door can slam shut as a player tries to walk through it.
I'm trying to think of a good way to describe how I see the difference, and I think it's this: Events should be used to inform the world that something has happened. Making the thing actually happen should be triggered by direct communication. So make a player move by calling player.move(), let the universe know about the player moving by triggering beforePlayerMove and afterPlayerMove.
You're talking about specifics here. Whether the event is named PlayerMove or you split it into BeforePlayerMove, DuringPlayerMove and AfterPlayerMove doesn't really matter that much. What matters is that this is the intended way in OOP to handle non-local stuff such as the Map responding to various things happening (such as the player moving).
Also, just to nitpick - you're wrong in that nothing should respond to PlayerMove events. For example, Trap objects might respond to PlayerMove events - a player might get damaged as he moves from one place to another.
The very idea about the event-driven model is to discourage thinking such as the one shown in your
In my mind, that should be handled by a direct call, otherwise you've got a single-subscriber event that logically shouldn't get more subscribers, which decreases code readability to no advantage.
In an OOP world, you (the object, that is) should not really know about who will respond to things you do. That is because such behavior hinders modularity - what if someone wants to take your RPG engine and implement it in a world where there are Traps (behaving exactly as I mentioned it before)? What if you later want to implement a multiplayer engine and want to not only handle the movement itself, but to send the info to a multiplayer engine so that other players can update their game state? Just because you're not imagining any subscribers right now does not mean you should hardcode it into your class.
Also, you're mistaking code readability for the clarity of the application logic. Code which says "now signal a Move event to whomever listens" is perfectly clear - of course, it does not say who responds to such an event, but that is because it shouldn't.
|
@Ilintar: Sorry, we're talking past each other a bit here. I misunderstood how you intended the eventing system to be structured, and thought that the player would itself be responding to a "move" event generated by the parsing engine. Looking back at your original post, you actually say that the player should trigger the appropriate events when it moves, so we're actually in agreement. I'm not sure what the point of your argument is, actually: I said the player should be moved by a direct call, you said in your original suggestion that the player would fire an event to notify other objects that it had moved, implying that the player moving was caused by a direct call. I suggested that the player could then fire events and gave examples, with my door example being very similar to your trap example.
|
May sound noobish but I was wondering if someone could explain to me how software design and produce a software in a team (as in is each person responsible for different header files that is saved together with .cpp files to produce one big program?). Pretty sure windows 7 wasnt created by one person.
|
On March 02 2013 09:31 heroyi wrote: May sound noobish but I was wondering if someone could explain to me how software design and produce a software in a team (as in is each person responsible for different header files that is saved together with .cpp files to produce one big program?). Pretty sure windows 7 wasnt created by one person.
Something like Revision Control? Sorry if I'm not understanding your question correctly.
|
If you mean how companies organize the work, then the details are probably different for each company, but usually you have project managers who tell each person/team what part they have to work on. Companies usually have their own agreed on "style"(formatting etc.) so code looks the same. But its common that you have the software structure down on paper before you start so everybody knows what his part has to provide and how it interacts with other parts of the software.
http://en.wikipedia.org/wiki/Software_development_process Shows most of the common models.
|
On March 02 2013 09:31 heroyi wrote: May sound noobish but I was wondering if someone could explain to me how software design and produce a software in a team (as in is each person responsible for different header files that is saved together with .cpp files to produce one big program?). Pretty sure windows 7 wasnt created by one person.
A game I worked on recently for PS3 has 761 header files and 801 cpp files for just the gamecode (does not include engine).
We had ~8 fulltime gameplay programmers working on the project. You tend to "own" a few modules and rarely collide with other engineers if your planning is correct. If there's a collision, source control will help you merge your changes with someone else.
|
Hey everyone! I am new to computer programming and have took an HTML class and currently taking my first Java programming class. We have a project due tonight and I cant figure out how to do this last task. I use Eclipse to write my Java code.
I am to: "Now, user JOptionPane's input dialog twice, first to set a percentage increase for the radius, then to set a percentage increase for the height(this means you will have two separate popup window). Then print out the new slant height and new volume, like:
The new slant height of the cone is: (value based on what user inputs) The new volume of the cone is: (value based on what user inputs)
Here is what i have so far as my code goes.
+ Show Spoiler +public class Cone {
// variable names public static double radius; public static double height; public static double slantheight; public static double basearea; // setting values to variables radius and height public static void main(String[] args) { radius = 0; height = 0; } // sets up radius to iniRadius and height to iniHeight public Cone(double iniRadius, double iniHeight) { radius = iniRadius; height = iniHeight; } // returns the current radius of the cone's base area double getRadius() { return radius; } // returns the current height of the cone double getHeight(){ return height; } // returns the current slant height of the cone public double getSlantHeight(){ return Math.sqrt(radius * radius + height * height); } // public double getBaseArea(){ return Math.PI * (radius * radius); } // returns the current volume of the cone public double getVolume(){ return 0.333333333 * Math.PI * (radius * radius * height); } // returns the current surface area of the cone public double getSurfaceArea(){ return Math.PI * radius * Math.sqrt(radius * radius + height * height) + Math.PI * (radius * radius); }
// changes the radius by a percentage public void changeRadius(double byPercentage){ radius=radius+(radius*(byPercentage/100)); }
// changes the height by a percentage public void changeHeight(double byPercentage){ height=height+(height*(byPercentage/100));
} }
and here is the tester class:
+ Show Spoiler +import java.util.Scanner;
//imports JOption Pop ups import javax.swing.JOptionPane;
public class ConeTester {
/** * @param args */ public static void main(String[] args) { // Creates a Scanner for inputing values of radius and height Scanner in = new Scanner(System.in); // prompts user to enter a value for the radius System.out.print("Please enter a radius for the cone:"); double radius = in.nextDouble(); // prompts user to enter a value for the height System.out.print("Please enter a heigh for the cone:"); double height = in.nextDouble(); // creates Cone object Cone myCone = new Cone(radius,height); // calculates volume of cone System.out.println("The volume of the cone is:"); System.out.printf("%5.2f\n",myCone.getVolume()); // calculates surface area of cone System.out.println("The surface area of the cone is:"); System.out.printf("%5.2f\n",myCone.getSurfaceArea()); // calculates the current base area of the cone System.out.println("The new base area of the cone is:"); System.out.printf("%5.2f\n",myCone.getBaseArea()); // calculates the current radius of the cone System.out.println("The current raidus of the cone is:"); System.out.println(myCone.getRadius()); // calculates the current height of the cone System.out.println("The current height of the cone is:"); System.out.println(myCone.getHeight()); // calculates the current slant height of the cone System.out.println("The current slant heigh of the cone is:"); System.out.printf("%5.2f\n",myCone.getSlantHeight()); // This prompts the user to enter a percent change for the radius String RadiusInput; RadiusInput = JOptionPane.showInputDialog("Enter a percentage to change radius: "); double RadiusPercent = Double.parseDouble(RadiusInput); myCone.changeRadius(RadiusPercent); System.out.println("The new volume of the cone is:"); System.out.println(myCone.changeRadius(RadiusPercent)); // This prompts the user to enter a percent change for the height String HeightInput; HeightInput = JOptionPane.showInputDialog("Enter a percentage to change height: "); double HeightPercent = Double.parseDouble(HeightInput); myCone.changeHeight(HeightPercent); System.out.println("The new slant height of the cone is:"); System.out.println(myCone.changeHeight(HeightPercent)); }
}
I'd really appreciate whoever helps me out and the textbook nor internet could help me.
|
On March 02 2013 09:31 heroyi wrote: May sound noobish but I was wondering if someone could explain to me how software design and produce a software in a team (as in is each person responsible for different header files that is saved together with .cpp files to produce one big program?). Pretty sure windows 7 wasnt created by one person. The team will work together to break down the software into multiple components, where each individual will take care of his portion. The APIs between the different components will be worked out so everyone understands what to expect from each other. Then the team leader yells "break" and everyone disperses and begins their work.
|
On March 02 2013 15:16 enigmaticcam wrote: Then the team leader yells "break" and everyone disperses and begins their work. It's true. We just stand around the Scrum room looking confused otherwise.
|
On March 01 2013 15:51 tec27 wrote:Show nested quote +On March 01 2013 09:22 Savi[wOk] wrote: I was wondering if the programming language "Ruby", was a good language to learn for a beginner even If I don't plan on looking at rails. Ruby is fine as a beginner's language. Since you've asked a lot of similar questions in here, I'd really encourage you to stop thinking so much about how you want to begin and just do *something*. Whether you start with Ruby or Python or Javascript or C# or whatever else, you'll learn at least something and if you don't like it or have trouble with it, you can always try something else later. As a beginning learner, and having just passed a ruby course/started a python one very recently, I will say this: start with a python course that focuses on algorithms. Ruby seems awesome, but there's just so much of the stuff I didn't understand that it was ultimately pointless. The little python I've gotten through so far is explaining so much about ruby, and then you can throw rails on top no problems.
|
|
|
|
|
|