• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

GnomeTank

Members
  • Content count

    198
  • Joined

  • Last visited

Community Reputation

199 Neutral

About GnomeTank

  • Rank
    Member
  1.   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. 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. 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

    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

    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. 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. 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. 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. 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? Yah...no, 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 :)