• Content count

  • Joined

  • Last visited

Community Reputation

199 Neutral

About GnomeTank

  • Rank
  1. WildStar CREDD System Explained

      No. Not even close. EVE's PLEX's work exactly like CREDD. There is no magic fairy NPC introducing them, only players introduce them via the in-game market. There is ALWAYS real cash, paid for BY A PLAYER, involved in PLEX transactions.   If you're going to make big sweeping "declarations of fact", make sure your facts are correct. Especially when you start accusing people of not reading the article, when we read it just fine.
  2. You Don't Need to Hide Your Source Code

    As soon as you said code wasn't art I kind of tuned you out.. The best programmers in the world will all tell you that programming is part science and part art. Writing clean, beautiful code that functions at peak efficiency with minimum amounts of code is absolutely 100% an art form. This isn't structural engineering, there isn't some book we can use to look up the "strength of concrete" as it were. Every software solution has to be crafted from a toolbox of a million tools, no different than a painting has to be made from a million colors. Sure there are theories and best practices and methodologies that help give some structure, but art has all of those as well. Go look up art theory sometime, it's an incredibly complex and scientific subject, yet it doesn't mean that art stopped being art.   The best programmers in the world are absolutely Van Gogh's with a text editor.
  3. Why your Games are Unfinished, and What To Do About It

    I mostly like the article, but #6 might be the worst advice you could ever give someone writing a game they expect to maintain. While you can certainly go overboard, just going wild and writing the sloppiest code you can is not only not simple, it creates a maintenance monster you have to deal with if you ever plan to support that game.   You can say "Well these are just throw away games", but you should practice how you play, so to speak. You say it yourself in #4: Make it a habit. That includes not writing crap code because "meh who cares, we're throwing it away".   Design patterns don't exist to stroke someones ego about how smart they are, they exist to create code that isn't a monster to deal with later. People not treating games like real software is what has gotten us in to some of the bug ridden hellscapes we've seen in games before. No one cares how fun your game is if it's a buggy mess.
  4. Unity Irrlicht any good?

    I've used them both quite extensively, and they are both capable tools. I would say that for a true 3D game, wanting to use the most modern rendering techniques, Ogre is probably a better choice. It has a much more flexible material system, and supports deferred rendering out of the box (as of Ogre 1.8). Some people dislike the use of singletons or it's reliance on a scene graph, but those are minor quibbles when you're trying to make a game. It's not a religion, it's an engine. Irrlicht is a slightly different beast. It's much less feature rich, but it's very tight, and it provides some higher level functionality that Ogre does not (though Ogre CAN provide that functionality, it just requires coding from the developer). This is mostly in the 2D space, where Irrlicht comes out of the box with an entire orthographic drawing library. I am currently using Irrlicht (via the IrrlichtLime .NET wrapper) in my project, because it's 2D and I like the easy to use built in 2D functions of Irrlicht. That said, they are [b]rendering engines[/b], not game engines. If you want a [b]game engine[/b], you're better off going the Unity or UDK route (I'm not sure why you don't want to learn C#, if you know C++ you basically already know C#...I sense some bias there).
  5. Unity Solid 2D engines worth considering?

    I rarely, rarely ever recommend this...but in the 2D space, you should probably roll your own. There just isn't a lot of movement in the 2D engine space, and through my own research, most people will just point you to a 3D engine and tell you to use it with an orthographic projection. That's fine, I guess...but in many cases those engines will be saddled with tools and processes that are completely unhelpful for 2D development. I was surprised to find that the actual [i]tools[/i] to create 2D content were readily available (things like Mappy, Tiled, Paint.NET), but the [i]engine[/i] to use them just weren't around, had terrible licensing terms, were too focused on one bit of technology, or weren't feature complete. In the end, I ended up rolling my own using IrrlichtLime as a very simple wrapper around DirectX and OpenGL. I have access to the fully hardware accelerated pipeline if I actually need it, but I'm not saddled with a bunch of tools I can't use and hoops to jump through. I use IronRuby as my scripting environment, as it allows me to embed Ruby (my favorite scripting language) very easily in a .NET app, even allowing me to sub-class native side engine classes directly from the Ruby code. I've integrated Tiled in to my pipeline for creating maps and I use Paint.NET for all my art. From engine start to "making a game" took me about four months. Mind you I'm an experienced programmer who has been writing code professionally for 12 years, so writing large complex software is not a daunting challenge for me. Your mileage may obviously vary.
  6. How does C# handle pointers internally?

    They aren't "pointers" in C#, they are references. This sounds like a non-important distinction, but it is important because C# has [i]actual pointers[/i] as well. .NET does not use reference counting, it uses a generational garbage collector where objects are moved along the generations as they are no longer rooted to another non-collected object. You'll hear the terms "anchored" or "rooted" a lot when dealing with this kind of GC. You'll also hear terms like "gen1 object" or "gen2 object", and this just has to do with where in the GC process the object is. Note that this is all true for the reference implementation of the .NET framework. It's quite possible that projects like Mono have their own implementation, though I am almost positive that Mono uses a very similar generational GC. That said, your understanding of what's going on from a high level is correct. When you put a reference to your object in to that list, the list now holds it's "root" (or one of them anyway, you may have references in other places). The fact that the variable the reference was assigned to is local means nothing. That local variable will fall out of scope, but the reference it was attached to will not be swept by the GC because you have it anchored in that list.
  7. I can't test this, because I don't have GCC readily available, but I'm pretty sure you don't need typename in your deceleration. Just do typedef forward<_node_data_type> _node_type;
  8. Redundant Scripting?

    Since I think you are both writing MUD servers, and scripted objects in a dynamic environment are important in that arena, you may want to look at some of the other OO MUD servers like DGD and ColdC. DGD is an LPC server with some modern programming concepts sprinkled in. They both may give you guys some interesting ideas.
  9. Redundant Scripting?

    I am doing something similar to you (creating a generic first person RPG engine), but I am using C++ and Python. That said, when I was considering using C# (as I still enjoy coding it in more than C++ :P), I was going to use IronPython for my scripting. In my mind, scripting should be as easy to do and as simple as possible. Expecting your "scripters" to learn C#, which can be a daunting language for non-programmers, is not going to win a lot of fans. Allowing them to use something that is much easier to grasp, Python, is probably preferred. The way I am doing it in my engine, is that I expose a very minimal set of C++ base classes through Boost.Python, and I then sub-class my Python game objects from the relevant C++ objects as required. This allows me to use those objects through the C++ interface contract in C++, and allows me to write speed critical components in C++. For instance, in C++ I expose a class called Thing, which is the base class for every game object in the system that requires game interaction (monsters, doors, treasure chests, etc). I've kept that class as generic as possible, but in Python, I sub-class from it to create the more complex game objects. Boost.Python allows me to expose pure virtual and virtual member functions to Python, so I can fully sub-class and overload my C++ defined Thing class in Python. I know for a fact that IronPython allows you to do basically the same thing from C#, but without the need for a wrapper library (as IronPython has access to all of C#'s class meta data via reflection). So if you have an assembly that defines your base C# classes for the game world, you can reference that when dynamically compiling your IronPython code, and then sub-class from it, use those objects and utilities, etc.
  10. Playstation Home

    I really have no problem calling it a fail at this point. Two years, and this is it? This is Home after two years? Second Life with not even a fraction of Second Life's functionality, full of 12 year olds running around trying to boof me in the arse with their avatar?, it's a total fail at this point. I mean really. Virtual lines at the virtual bowling alley...for real? Do I get a virtual quarter to put on the virtual arcade machine so I can save my place in the virtual line? Maybe others are more forgiving and/or optimistic than me, but I am really tired of Sony's BS. This is just another in a growing pile of PS3 foul ups.
  11. So this is sort of a broad question and topic, but in my eternal state of "lets play with this new shiny thing!", I want to put together a DX10 engine that I can play with some advanced techniques in. From a scene management point of view, I'll probably go with your standard scene graph and call it a day, but what I am interested in is how you guys handle the fully programmable pipeline. Obviously it will be handled through .FX files, but do you tend to have one gigantic monolithic .FX for drawing 90% of what's in your engine, or do you create individual .FX files for every possible object? The latter method seems very cumbersome. Coming from an OGRE background, I am used to a pretty robust material management system, but I am not sure if DX10 effects can be used in the same way. Is it possible to create, lets say, a VP/FP combo that can cover 90% of the engine (as most objects are drawn pretty much the same way) and just reference those programs in the various .FX files? Is this how most people do it? Obviously every object in the scene should be able to dictate what effect it's drawn with, but I am more curious about the organization of the effects themselves. There isn't exactly an overgrowth of DX10 code out there, and what you do find tends to be very test bed code and doesn't contain what many would consider "proper" structure.
  12. Quote:Original post by Kylotan They recently changed their IO system however, so that problem may have alleviated somewhat. I'm still hoping for a response from drakostar though. :) Turning arbitrary strings of Python into functions that can be run on a per-instance basis seems a bit tricky in Python (and trivial in Lua, irritatingly). Yah, it simply moved the lag around. Instead of 45 minute load times, you get more consistent 3-5 minute load times, which, I guess is better overall, but it really just moved the problem around, it didn't alleviate it. To be fair, EVE has much deeper problems than just Stackless Python. For instance, their network I/O is based entirely on TCP, and they send huge 8 meg mega-packets that are just stupid. If even a byte of that mega-packet gets lost, the whole thing is sent again. So you have to take the whole system in to account, but Stackless Python IS an issue in that environment. Now, for a single player game, where you're not going to be managing 500 players, plus 5000 AI drones/fighters, in a single system, it's probably fine.
  13. Quote:Original post by KulSeran Quote: The only real drawback, as far as I'm concerned, is performance. If you have some kind of simulation with thousands of agents, creating a microthread for each one is not a practical approach. But if you're only dealing with hundreds at a time, it's not an issue. Tell that to eve online. They use it because it is the most performance friendly way for them to manage all the thousands of agents in their game. Using EVE as a benchmark for how efficient Stackless is, is a terrible idea. Having been a long time EVE player, I can tell that EVE basically chokes when more than 200-300 players are in a system, attempting to fight. I've literally been in fights where the client to server lag was measured in hours, because the servers would choke because of all the Stackless microthreads they spawned.
  14. Kernel threads in Linux are nearly the same as processes, but there are user lands threads in Linux that are lighter weight. Some OS's don't differentiate, but Linux does, so does Windows. FreeBSD, if I recall, does not make a distinction. All threads are kernel land threads (which was a major point of confusion some years back when pthreads was first being made to work on BSD). Apache was changed to connection-per-thread, asynchronous I/O, because it's flat more efficient than connection-per-process, blocking I/O. It scales much, much better than the previous method, and basically has an unlimited scale ceiling in terms of new hardware.
  15. Indoor our scene distance will be short, outdoor it will be very large (think Oblivion). Which is why are thinking of using cascaded shadow maps, otherwise our shadow draw distance is going to be pretty limited. I will look in to TSM, thanks for the suggestion :)