SatharisMember Since 18 Oct 2007
Offline Last Active Dec 10 2013 01:50 PM
- Group Members
- Active Posts 271
- Profile Views 1,989
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Satharis hasn't added any contacts yet.
Posted by Satharis on 02 December 2013 - 02:39 AM
Using a game like WoW for example, you gain absolutely nothing from having multiple accounts even if they were free, seeing as you only profit by actually doing something in the game. If you game is based on gathering resources over time or something than the obvious thing to do would be to design it so that you can't simply give resources away to someone.
Being realistic, there's no good way to identify people on the internet, even banning people is essentially completely impossible since it takes little more than a proxy or changing the ip or mac address and using different information for you to have no clue it isn't a completely different person. That's the world we live in, and honestly it shouldn't be that big a deal.
Posted by Satharis on 30 November 2013 - 05:35 PM
Older games were designed to run at a certain FPS, lets say, 30. When the game was created they designed the way objects move(for instance how much a worm moves) to be based on 30 update iterations every second. So if they wanted the worm to move say, 30 units a second, then all they do is make the worm move one unit every update frame.
That worked fine for the time period, but on faster machines that weren't using the same hardware always, that inevitably meant everything started moving at super speed. You can do a similar thing these days by using a fixed time step, which basically means artificially limiting your update to running so many times per second.
But honestly in most cases you want to make your movements based on time, not on update iterations. This depends on the object, for instance a 2d ball moving across the screen would probably benefit(graphically) from moving based on time, easiest way to do that is to get a decimal value of the time that passed out of a second and multiply your movement units by it. If you have a physics engine, the physics engine probably moves in steps because physics is much more accurate with round numbers, depending on the engine it may have an update function that either grabs the time or asks you for the delta time. Then it just sits there and does nothing until a certain amount of time has accumulated.
For implementing a timer class in a non-fixed timestep game, you can pretty easily just take the delta time passed from the game loop, and add it to an internal timer. You can even make countdown timers, say you start it at ten seconds, then you just subtract the delta time. When it goes to zero or under zero, you fire your event.
Posted by Satharis on 30 November 2013 - 03:41 AM
Posted by Satharis on 30 November 2013 - 12:51 AM
Okay?.. Whats your point? What kind of libraries are we talking about?
The libraries whch Java can access lead the industry in many categories.
If we're talking about native libraries, Java would be, if anything, just adding overhead to their performance. If we're talking about Java specific libraries like the standard library then.. what advantage do they have over other standard libraries?
You're being really vague.
Posted by Satharis on 29 November 2013 - 03:23 PM
General rules of thumb I use are:
- If it's a pointer or a reference, forward declare it.
- If its something complex like a bunch of typedefs(as Microsoft is famous for) just give up and include the file.
- If the class/struct is a member, include the file.
That fixes most issues.
In your case I would question why both the scene and the object list need to know about entities as well as the former including the later of the two. Of course if your object can exist without a scene then you probably should have the scene as a pointer, which you do. So declare class Scene;
Treat header files as vague, treat cpp files as where you include the meat of how to work with objects.
Posted by Satharis on 29 November 2013 - 01:54 PM
Yes I'm well aware the business world is still pretty steeped in Java but that is a different sort of ballpark realistically, industry tends to be very slow to change to new languages and Java has been kind of the "awkward mainstay" fora very long time. It's the same reason extremely dated languages like fortran are still used in quite a few areas.
For his server side comments, Java for servers is very common in the business world, and I have seen it used in backends of several games. Look on job search boards like Dice or Monster for JSP developers, and thousands of jobs looking for Java+SQL experience.
To be honest I would consider phones to be a unique variant, for a lot of phones Java may have been the ONLY choice available, for Android, Google has pushed the language far above others and so most people default to it, even then C# through mono has a rather devoted following. I wouldn't really compare languages when you flat out get more out of using one on a certain platform, that's a bit silly.
There really are thousands of games written in Java. Most of the 'dumb' cell phones starting in the late 1990s through today, aka feature phones, have the apps developed in Java, and there were LOTS of them. They still have a market and games are being made for them. Today, in addition to the feature phones, the Android environment is Java-centric. Many games do provide minimal Java code preferring to develop in C++, but quite a large number are written entirely inJava. Then there are still Java applets on the web (visit sites like Pogo for many active examples), and Java-built PC games like the ever-popular Minecraft.
Yes and mobile is a gigantic industry now, that said cell phone games are rarely performance centric and even simple 3d is pretty rare in a market dominated by 2d puzzle games and other 99 cent distractions. My personal opinion is that I really don't see how something being a used a lot means it has much merit as a language, keeping in mind the entire discussion here is viability for games(in which the OP specifically mentioned feature sized games like AAA industry.)
So with Android being out for five years and recently hitting the one million app mark, saying many thousands of games per year are written in Java seems like a small number. I would say that the current rate is several tens of thousands of games per year use it. (Again, yes, many do jump quickly to C++, but I believe they are in the minority.)
Again, I'm not saying Java "can't do this or that" I'm saying "there's no real reason to do this or that with Java." Of course that argument changes based on platform, on Android there actually is merit to considering Java as your language because its so often used.
I wouldn't say they're vanishingly small, in my opinion the same number of big games are coming out as before, if not more. If anything the game industry is just expanding because things like mobile games have started to capture all the "normal" people out there. But we're talking about things that are galaxies apart here really, a game like Battlefield 4 does not even entail remotely the same decisions as a bejeweled clone on a cellphone. The bigger you get, performance tends to become more of an issue as well.
While it is true that you won't be able to completely optimize everything at the lowest level with a Java code base, the number of games that need to do that are vanishingly small. Java is more than adequate for just about any game an individual developer or even a small team of developers is able to create.
My main issue was that was he says is superfluous, he makes the language sound like its amazing and used for everything and a direct competitor to languages like C++ or even C# while in reality, as a language, I still don't see much merit to it being used on PC in particular, or even on consoles unless its the preferred language.
So yes, Java can realistically do everything you need for a game. It is safe to estimate that hundreds of thousands of games already use it successfully.
My opinion is that C# is very similar to Java but it makes a lot more design decisions that are intuitive, and as a language it just feels better developed. Obviously mileage may vary there. On the flipside I would say a language like Java or even C# is going to have an extremely hard time being able to optimize down to the metal. If you do make those optimizations they will likely take longer, and for less payoff. Java is just kind of the ugly duck in the room when it comes to games, but then again why shouldn't it be! Java was designed to be totally generic.
Posted by Satharis on 28 November 2013 - 11:44 PM
To me this sounds like a lot of really superfluous "Here's why Java is shiny."
World class games and simulations continue to be made based on Java, but often in conjunction with another language for specialized development needs such as gameplay scripting language (sometimes invented in house), hardware cross-platform, operating system cross platform (actually targeting a major Runtime such as .NET, Java, or Mono), or as an excellent development environment for mobile device games. Java is also used sometimes for scripting gameplay or for GUIs and UIs over another language for lower level coding.
Do you have any actual proof of these claims? So far I'm just reading a lot of "Java is super amazing and better than every other language!"
Java has multi-threading and multi-core capabilities via libraries, can go high or low level coding, and is often preferred for server heavy software development. It plugs well into OpenGL (better than some languages) and has mature libraries to support any level of software development. Some developers find it more efficient in cost and labor to develop in Java than C or C++, for example. Java just in time (JIT) and post processing libraries combined with the previous mentioned cause the performance gap between Java and C++ or C to be more a matter of skills than the language.
What is "good" and "bad" code? This is extremely vague and could be taken as true in any language, I could pretty easily write a generic looping function in C++ that performs terribly and probably do the same thing correctly in Python and get better results. You might as well be saying that "remember our gun is still a gun if you're terrible with other guns!" When comparing languages you should be assuming competency.
" Good code written in Java performs better than bad code written in C++ "
I'm starting to feel like I'm reading an advertisement for the language instead of discussing actual merit of i.
Military and corporate developers in the many thousands settle on Java for the above reasons. They create some simulators in Java which are more complex than the biggest entertainment games written in C++, but with competitive performance with the C++ games.
More vagueness that honestly doesn't even make much sense.
Some libraries of code, such as C++ game engine components, can be ported to Java or work inter-operatively in a virtual machine such JVM or a game engine.
I have to say this is probably one of the more hillarious and totally baseless lines I'm reading. In terms of serious games developed for Java I could name three off the top of my head: Wurm Online, Minecraft, and Runescape(which I believe isn't even Java anymore client wise, and their server likely hasn't been Java for awhile.
Many thousands of games per year are developed based in Java.
Even in terms of small web games made by individuals Java is almost completely extinct and the market is completely dominated by Flash or even html 5, I've found it unusual to even find anything on the internet that requires Java anymore.
If you're looking for graphical performance using Java is like hooking a ball and chain to your ankle to run a marathon, sure you can optimize quite a bit with it, I'm not saying its an impossibility but the effort involved is definitely not a time saver. You don't use a friendly language when you need speed you use a friendly language when you need quick development.
The main languages to handle low level graphics with excellent performance are C, C++, and Java, in my opinion. Since skill and preference weigh heavy in the quality of the end product, these are more important than the language itself.
EDIT: Pardon if I'm coming off as rude or anything but I really think you're being a bit overzealous on Java's merits here, especially in the realm of game development. It simply really annoyed me to read a huge paragraph of "Java does everything" without even giving any actual base to the claims.
Posted by Satharis on 26 November 2013 - 05:33 PM
Usually when people start off with games they tend to do the "hard code" approach, i.e. you make a function that displays the text for one room and you write the description right into that function. While it works, its a lot of wasted code whether you're doing functional or OOP. Sure you could make a function for every room but the rooms are all so similar, instead why not consider the things that the rooms share to be data and have the function operate on that plain data.
Now you probably already know this quite a bit but I'm more emphasizing the principle behind it, because it basically works for everything you're going to do. Example being rooms, what might you do in a room? "look?" well what does that do really? Thinking of it logically we can deduce the look function probably needs to grab the room title, its description, and check its exits to display which exits are open to you. So how can we do that? Well we'll need a collection of rooms for one, as was stated above you can use something like an array or a collection to contain a bunch of "room" data objects. What else do we need? Well we have to know which room the character is in so we can grab its information, there's a few ways to do that as well. For instance you could create a number index system, i.e. your player has a variable saying it is in room 7 and room 7 either is an index into the room array or maybe an id number that you search for. You also could just have a "room" variable for the player object that will be a reference to the room they are currently in.
Sorry if that was a lot of text, since this is homework I don't want to give too much concrete examples, but if you think about the logical deconstruction of the "look" function, you can apply that to other things, items, monsters, doors. It's all basically the same.
Posted by Satharis on 26 November 2013 - 03:36 PM
Basically what I'm saying is that if you think you'll get something out of C++ then don't be afraid to dip your fingers into the language, I can guarentee you that it won't -hurt you- to learn another language, especially one thats about as bare metal as you can go without being assembly. My personal experience with learning has been that one book, one language, one library, one project, none of them teach you everything about them, you learn a lot of the most important information by accident while learning something completely different sometimes. At he very least it may help something "click" in another language, "Oh THATs why they do that in C#!" sort of thing.
Pogrammers tend to have this little problem(myself included many a time) that they learn so many little things in order to understand a concept that when they have to explain it to someone or direct someone they don't remember those thousands of little things they had to accidently learn in order to understand it. Knowing anything in coding is usually a -lot- of information, like there's a difference between knowing pointers and really KNOWING pointers. These things are often best learned by ones self.
Posted by Satharis on 26 November 2013 - 03:27 PM
Posted by Satharis on 20 November 2013 - 08:32 PM
I really do not recommend Java, although I'm sure some out there will disagree with me, as a language it doesn't offer much over C# other than the fact you'd have to use Mono to target all platforms like Java does. In terms of game development it has some of the least support of any mainstream language, even Python with Pygame would probably be way better than Java quite frankly.
Anyway just pick something that looks interesting and get to work, you learn a lot more by experimenting than asking whats the best thing, imagine how many hours of code you could have written in the time you might sit there worrying about if you picked the right thing.
Posted by Satharis on 17 November 2013 - 09:57 PM
If anything if you get to the level where a simpler MMO is within grasp you'll probably already be able to plan out the massive amount of work you'll need to do to get it running, there's a reason for AAA starting an MMO is like declaring to your fellow rod fishing captains you're going to go buy a cruise liner.
Personally I would pick what aspect of it interest you the most and start learning that. Do you like the multiplayer aspect? Maybe look into that, or if the RPG gameplay interests you, look into that.
I myself have an idea for an MMO i'd like to go after some day but I'd have to take a long time to collect my thoughts on it and plan it before even starting such a big project by myself, help would be invaluable.
Posted by Satharis on 24 October 2013 - 03:41 AM
I think that for production Java is already a joke for game development as evidenced by the rather miniscule amount of game dev related libraries for the platform, not to mention ones kept up to date.
I'm a fan of C++ but I think that for production Java and OpenGL will lead for compatibility/readability advantages of both.
You have LWJGL, that's about it. C# is already beating Java in every way possible just with XNA/Monogame. There hasn't been any reason to use Java for a long time, originally it was used for web embedding but that turned out to be one of the biggest nightmares of all, and it has basically been completely obliterated by flash. Without that selling point it just doesn't offer anything to gamedev that another language doesn't do /better/ with the exception of naturally built in cross platform ability. But Mono gives that to C# pretty easily, that's if you're even interested in developing for something besides Windows.
I would say C# is definitely a lot more "fun" to use than C++, it's definitely a lot less hassle, but it has tradeoffs of course. It's good enough for most games but a company trying to bring out the next generation of graphics or something will probably fall back to the dinosaur C++ is and ride it through town smashing down walls C# gets stuck at potentially.
Posted by Satharis on 22 October 2013 - 08:16 AM
I'm not really sure what your point here is, you make it sound as if as performance increases we will have "a bunch laying around" and can simply switch to less optimizable languages just as a time saver. Even as computing performance goes up there is always more to add, especially when it comes to triple A games, there's always more to add with physics, lighting, world size even, quality is always going up to keep pace with hardware. I mean really, animated films demonstrate we can make even better looking graphical effects for games but it just isn't feasible to do a lot of their techniques currently.
With so much being offloaded to the GPU and if physics cards ever take off, and with the CPU speeds, the question has to be asked, "is C++ really needed for anything else?" AAA companies also have budgets and timelines and I have to think at some point the hardware will be specialized and fast enough to where engines can be written without C++. If gameplay is the only thing remaining then managed languages/scripting is far easier and cheaper and more flexible than C++.
tl;dr: Regardless of machine performance, C++ is just the industry favorite "middleground" for a language. It's not as specific and ridiculous to code with as assembly but not as high level as something like Python either. That "difficulty slider" will always be there, it may just swap out contenders.
Posted by Satharis on 22 October 2013 - 02:30 AM
Frankly, although I'm a huge advocate of languages like C# and they're -always- more fun to work with, the fact is that for fast, no hands holding code C++ doesn't have much competition. Realistically most companies have used C++ for a long time, they have code for it, their programmers are trained in it, and for gameplay scripting or anything of the sort that doesn't cause catastrophe if it loses any speed, C++ is already being defeated.
No real way around the fact it's here to stay unless something better comes along, even if computers get more powerful, AAA companies always strive to be like Hollywood, bigger and badder, so that kind of requires sticking with C++ for the time being.