• 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.

Dauntless-v2

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

125 Neutral

About Dauntless-v2

  • Rank
    Newbie
  1. Try making your inner object public or protected. If that doesn't work, you might have to make it final.
  2. The error message you are getting is indicating that the linker (ld.exe) can't find a library (SDLmain.dll). I am not familiar with CodeBlocks, but see if there is a way to put in search directories that contain your libraries. The other possibility is that when you built/installed libSDL, it didn't create or put SDLmain.dll in a "well known" location (for example, in linux, a well known location is usually /usr/local/lib, /usr/lib or /opt/lib)
  3. I second Editra. It's still a wee-bit buggy, but it's pretty nice nonetheless. Since it uses wxPython, if you want to get better at wxPython, you can look at the source code for ideas or examples. Another wxPython based GUI IDE is SPE, which is nice if you want to integrate your python code with Blender. And there's also Eric, which is nice if you want to integrate your code with PyQt. As you might guess, it's built on top of PyQt. Komodo Edit isn't bad, but I didn't like not having a symbol table browser. Right now, I mostly use Editra for my python coding, but Eclipse + Pyclipse isn't far behind (I like it for the bazaar integration). If I ever get seriously into my little blender project however, I'll probably switch to SPE.
  4. Creating a language, even a "scripring" language isn't trivial. If you don't believe me, start looking at yacc and lex, or maybe bison. Start reading up on EBNF's (Extended Backaus Naur Form). Make sure you know your automata and compiler theory. For example, know the difference between lexers and parsers. Start reading up on different grammar types (for example, LALR), and it would also behoove you to understand recursive descent parsers. At my last job, I was tasked with beginning to write a domain specific language for one of our embedded products. The only reason we went this route was because we couldn't get python to compile on our devices processor (which was actually an ADSP, not a CPU). If you can, you really want to use an existing scripting language. And it's not just because it's easier than writing a language from scratch. Also think of all the thousands of programmers that already know some language like python, (jython, ironpython), ruby, (jruby, ironruby), lua, erlang, or some other of dozens of languages out there.
  5. As you mentioned, Python doesn't really enforce data-hiding in the way that you mention. Remember that Python is a dynamic language and that you can add attributes or methods dynamically on an object. class A: pass a = A() a.x = "something new" Python's sense of encapsulation means that you don't have to worry about implementation details, not whether or not an attribute has public or private access. Although python doesn't explicitly support access modifiers, you can "fake" it. A leading double underscore means that an attribute is private in the sense that if you try to access the attribute directly (via it's name), you won't be able to. Python does this by secretly name-mangling the variable with a leading underscore, the name of the class, and then the name of the variable. For example, if you have something like: class Example: def __init__(self): self.__hidden = "Don't access me directly" def get__hidden(self): return self.__hidden e = Example() e.__hidden Traceback (most recent call last): File "<input>", line 1, in <module> AttributeError: Example instance has no attribute '__hidden' e.get__hidden() "Don't access me directly" dir(e) ['_Example__hidden', '__doc__', '__init__', '__module__', 'get__hidden'] A single leading underscore is simply an indicator to other programmers that they really shouldn't be directly accessing a variable (or method). It also means that when you do a 'from mymodule import *', anything with a single leading underscore doesn't get imported. Python has a feature similar to .Net Properties (and in fact, python calls them Properties also). If you are using new-style classes (ie, inheriting directly or indirectly from object, or use __metaclass__ = type somewhere in your module), then you can use the property protocol. Basically what this means is that python will use accessor and mutator methods that you define, but they are called implicitly for you depending on the context. You can sort of implement your own protection scheme by using the magic methods of __getattr__ and __setattr__ respectively. If these magic methods are implemented, whenever someone accesses (any of) a class's attributes, then these magic methods are called. class Example: def __init__(self): self.__hidden = "Don't access me directly" def get__hidden(self): return self.__hidden def __getattr__(self, name): if name == "__hidden": print """You really shouldn't be using me directly""" else: raise AttributeError e.__hidden You really shouldn't be using me directly The larger lesson here is that python does things differently. For example, instead of having interfaces like Java or C# that are bonafide types, python uses what is called "duck-typing". If it walks like a duck and talks like a duck, it is a duck. It took me a little while to get used to dynamic programming, but now I love it. Granted, it does require a little more diligence, but I find that this enforces documentation (and docstrings are cool). And when things are dynamically typed, it actually forces you to think more polymorphically, because you may not exactly know what might get thrown in (or out). There are ways to check this at runtime through introspection, or using functions like callable (which is to be deprecated btw), but this is as ugly as using RTTI in C++.