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


  • Content count

  • Joined

  • Last visited

Community Reputation

174 Neutral

About lrh9

  • Rank
  1. Any design or methodology can be misapplied. It can be easy to criticize those misuses, especially when they are common. They should be, but good ideas should not be discarded because of bad practices.   In my idea of a good ECS there are no hierarchies. Do note that in your proposal to have separate hierarchies you don't avoid the issue you are concerned about. Instead you just move it to a different level of the hierarchy. A designer could want a goblin that can both fly and walk, or one that can both use a sword and cast spells.   To me, ECS is the end result of the thorough application of duck typing. Rather than thinking of entities in terms of Goblins and Attacks, and Melee and Magic, ECS requires the designer to think in terms of what they want their entities to consist of (components/data) and what operations can be applied to them (systems). In this way of thinking (properly applied) it no longer matters what the entity is, but what can be done with it.   Personally, I do favor the use of ECS for core/engine code and eschew it for entity logic. The engine is where ECS can be most easily applied. For example, you can have an entity with a position component and a velocity component and your physics system can do integration (Euler, RK4, etc.) to update that entity's components. A.I. isn't always so simple. In that case I favor scripts, which can easily be integrated in the ECS by having entities have a scripts component and a system that calls relevant script hooks during each logic update.
  2. Sounds like you are on the right track. Having a location or container keep a set or dictionary of contained entities is a perfectly valid way of organizing that sort of data. I'm a little bit concerned by the word "synced" because I have never heard that term used when describing this sort of problem. Anyway, I use what is called a publisher/subscriber model for events. Basically, entities that are interested in certain types of events will subscribe for messages about those events. When an event occurs, a publisher is instructed to publish a message about the event. Messages have a topic indicating which type of event occurred. This is how the publisher knows which entities to notify about the event.   Relating this to your type of game, say you have a room representing a shop. When a character enters or exits the shop, you could publish a message. Shopkeepers could subscribe for this message, and issue a greeting or farewell as appropriate. Let me see if I can scratch up a code example. import collections class Publisher(object): def __init__(self): self._subscriptions = collections.defaultdict(set) def publish(self, topic, *args, **kwargs): subscribers = self._subscriptions[topic] for subscriber in subscribers: subscriber(topic, *args, **kwargs) def subscribe(self, topic, subscriber): self._subscriptions[topic].add(subscriber) def unsubscribe(self, topic, subscriber): self._subscriptions[topic].discard(subscriber) publisher = Publisher() class Room(object): def __init__(self): self.entities = set() def on_enter(self, entity): self.entities.add(entity) publisher.publish(('on_enter', self), entity) def on_exit(self, entity): publisher.publish(('on_exit', self), entity) self.entities.discard(entity) shop = Room() class Character(object): def __init__(self, name): self.name = name def enter(self, room): room.on_enter(self) def leave(self, room): room.on_exit(self) player = Character("bheo") class Shopkeeper(object): def __init__(self, name, greeting, farewell): self.name = name self.greeting = greeting self.farewell = farewell def enter(self, room): room.on_enter(self) publisher.subscribe(('on_enter', room), self.say_hello) def leave(self, room): publisher.unsubscribe(('on_exit', room), self.say_goodbye) room.on_exit(self) def say_hello(self, topic, entity): print self.greeting.format(entity.name) def say_goodbye(self, topic, entity): print self.farewell.format(entity.name) cleric = Shopkeeper('Cleric', 'Blessings of the Gods upon you, {0}.', 'May the Gods light your path, {0}.') blacksmith = Shopkeeper('Blacksmith', 'Finest arms and armor, {0}.', 'Thank you for your business, {0}.') cleric.enter(shop) blacksmith.enter(shop) player.enter(shop) player.leave(shop)
  3. You can always use both. It's incredibly easy to extend Java with Python (or to use Java in Python) with Jython. Jython let's you use Java in Python, and you can use the Java Scripting API to script Java applications. But unless you really need both it's generally not done.
  4. For physics you might need to do some integration (antiderivation). Basic calculus, but nothing to be afraid of.
  5. Thanks Mole and Richard for the quick replies! Mole gave me an idea to look at some design patterns to see if any were applicable, and from the wiki it seems like the bridge pattern may be appropriate to use for this purpose. It even has an example in Java. Thanks again and keep up the great replies!
  6. Hey everyone! I'm working on implementing a 3D game in Java using LWJGL and the Artemis Entity System Framework. I've done the tutorials on the LWJGL site, and they have examples for older OpenGL (the term I use for OpenGL < 3.2) and modern OpenGL (the term I use for OpenGL >= 3.2). Even though the majority of my player base will be able to play games made with modern OpenGL, I'm wondering if I should support older OpenGL too. However, that's not my primary question.   Even if I decide not to implement a renderer for older OpenGL the possibility has raised what I consider to be an interesting design question. How would I implement a rendering system supporting multiple renderer implementations? My initial thoughts on the subject lead me to believe that by using well designed interfaces I can abstract the rendering process to a set of steps. Then it would be a simple matter of having different implementations of that interface for the renderer variants.   I'm implementing rendering within the confines of the Artemis Entity System Framework, and that basically involves systems processing a collection of entities using their components. So far I think that the minimum components needed to render a renderable entity are its position, scale, orientation, vertex data, textures, and shaders. This is kind of what a not yet implemented rendering system would like. import com.artemis.Aspect; import com.artemis.Component; import com.artemis.ComponentMapper; import com.artemis.Entity; import com.artemis.annotations.Mapper; import com.artemis.systems.EntityProcessingSystem; public class NotImplementedRenderingSystem extends EntityProcessingSystem { @Mapper ComponentMapper<Component> cm; public NotImplementedRenderingSystem() { super(Aspect.getAspectForAll(Component.type)); } @Override protected void process(Entity e) { /* * render using entity components: * position * scale * orientation * vertex data * textures & shaders * e.g.: */ Component component = cm.get(e); //do something with component } } Other people I've spoken to on IRC have shot this idea down. I'm not really sure how I would name each implementation, but I suggested Renderer20 (OpenGL 2.0), Renderer32 (OpenGL 3.2), etc. and that was panned as a horrible idea. The same people suggested abstraction, but they didn't say where I should put my implementations or what I should call them. Any advice, ideas, questions, guidance?   I've heard that the best way for an indie game programmer to make games is to get a minimal working framework as soon as possible and expand from that, and I'd really like to be able to get into a rendered world (even if it is just basic geometric primitives with vertex color) as quickly as possible. Thanks for reading!
  7. You can write 2D and 3D games in Python. I've played with Panda3D (perhaps the premier Python 3D game engine) and I'm writing a 2D game with PyGame. I spent some time learning the language, but everything you need to know to make games with Python and PyGame is in the Python tutorial and the PyGame documentation.   In my opinion the toughest part about breaking into game development as a solo developer is learning how the structure of a game program differs from the structure of other programs. Every game has a main loop that at minimum gets player input, updates the game state, and displays the results on the screen. This can be difficult to accomplish without the appropriate design.   http://www.koonsolo.com/news/dewitters-gameloop/ http://gafferongames.com/game-physics/fix-your-timestep/ http://lspiroengine.com/?p=378 http://www.valuedlessons.com/2008/04/events-in-python.html http://entity-systems.wikidot.com/   You'll also need art assets. To that end I recommend OpenGameArt.   I have no problems sharing the code that I have, so message me if interested.
  8. Have you ever played Final Fantasy X for the Playstation 2?
  9. I'd like to write a story about modern issues framed in a fantasy genre. If done well I think it would be a great way for players to explore ideas, experience situations, and grow personally. For instance, in my fantasy world all individuals and creatures would be grown forms of a single type of organism. If I had fantastical species or races like dwarves and elves, then they would both be grown forms of the same type of organism, but they would have differentiated based on different factors. Factors might include where the organism grew up, who its parents were, and other inherited and environmental factors. This would also apply to the benign and malignant creatures populating the world. Now in this world, conflict would arise between various groups over this base type of organism. One group could believe that all instances of this organism are sacred and must not be killed for any reason. Another group could believe that it is acceptable to kill this organism for any reason, and has members that regularly do so. And of course there would be various groups in the middle. The player would get to explore how this system works, what happens, experience the various situations that can arise out of this interplay, and select how to respond. Say a famine in an area causes the base type of creatures to differentiate into monsters that steal food or eat people. The player could witness the group believing in the sanctity of these organisms defend the base type of creature until it turns into the monsters and fight anyone who tries to cull these creatures. Or the player could witness the endangered villagers killing the creatures that - in different circumstances - would grow into regular people. The player would have to internalize this, and choose how to respond. They could protect the creatures and cause a village to be destroyed, but maybe a few people would grow out of the saved creatures. Or maybe they could cull the creatures themselves and have to live with their conscience. It's a idea I haven't really spent a lot of time on. I don't even have anything committed to paper.
  10. I've been reading about finite state machines, and - as I understand it - they can be represented by graphs. I wonder if FSMs implemented on a graph data structure would have any special or unique practical applications. I have a gut feeling that finding paths between two states and finding predecessors or successors of a given state might have practical applications, but I can't imagine any detailed use cases. I could see finding the shortest path between two states as a way to determine the minimal set of states an actor must traverse when going from one state to another, and I could see predecessors or successors used to enable systems to reason about the previous and next states of a system based on the current state. Thoughts?
  11. It's possible to use mappings to associate a state and symbolic input with the consequent state. A transition method would accept a symbolic input and return the next state based on the current state and the given symbolic input. This simple implementation performs no conditional logic. That would be implemented elsewhere. It is like a switch statement except the focus is on data rather than logic and both accomplish the same thing, but there are subtle style and layout differences.
  12. In a standard neural network, all neurons influence the neurons they are connected to. When a neuron is activated, it receives a series of inputs that map to a series of weights. The neuron sums each input multiplied by that input's weight ([url="http://en.wikipedia.org/wiki/Dot_product"]http://en.wikipedia.org/wiki/Dot_product[/url]), and then applies its activation function to the result. [url="http://en.wikipedia.org/wiki/Artificial_neuron"]http://en.wikipedia.org/wiki/Artificial_neuron[/url]
  13. I'm new at game development, and I have encountered a couple of the problems you have mentioned. I think that in any project - big or small - it is easy to get distracted by the monolithic idea and presentation we have in mind. Yes we want to make a game, but unless we stop thinking about that game as a single entity and instead start focusing on the individual components we cannot begin to create it. It would be like trying to step across a room in a single step; it can't be done. So what I am trying is decomposing my game into components. Instead of thinking, "I'm going to make a game.", I think, "First I need to play an intro movie, then I need to present the main menu, and in order to do that I need to..., then I need to..." and so on. I too keep a design and technical document, and I write down each "piece" or "step" in order. When I get finished I hope I have a document that lists everything that I need to implement to create a complete game. It sounds like you are on the right track. You keep a design document. It seems to me that you get off track when you code. It is possible for us to encounter the same problem I just described when we code. Instead of keeping source files small and focused on a single task, we can write monolithic blocks of source that are difficult - if not impossible - to understand and work with. I think there are two major contributors to this. The first is that we might not use language features that help us keep source files small and focused. In all languages I have seen, there are ways to divide source over multiple files and use them to create a whole program. In Python - my language of choice - we can create modules that we can later import and treat like a namespace - each one containing the functions, classes, and objects we created in them. In C++ individual source files can be compiled to an object file, and linked together using a linker. It is important to make use of this functionality. If I put the code for my project in one source file, I would have several pages of source just to play movies, display a main menu, and perform a few other tasks. That is probably less than 1% of everything a game has to do. However, if I put movie related code in one file and menu related code in another I can keep my main source file under a page at that point. Much easier to understand. "Here I'm playing a movie. Here I'm displaying a menu." If I design and code well enough, I can make minor to moderate changes in one file and the others will still work. The other major contributor to monolithic source is the lack of separation between code, data, and the way data is represented. We have all seen beginning efforts at game programming where each entity in the game is represented by a dozen variables, and each variable has a unique name. "//Goblin1; goblin1HP = 5; goblin1MP = 0; ..." The major problem with this is that it makes data difficult to change. We have to locate the specific thing we want to change in our source. In some languages, we might even have to recompile the entire game just because we changed one monster. The minor problem is that it clutters the source. "goblin1 = Monster.fromFile("goblinstats.txt")" is better than a dozen lines setting each stat. I have also considered the problems of adding visuals and sounds to my game. There is nothing wrong with programmer's art. If the lack of quality graphics and audio breaks our game's fun, we need to try to improve on our game content. Pacman would be the same [i]game[/i] if it consisted of a blob eating dots and evading squares and chasing triangles, and people would probably still play it and compete for high scores. Even Pong is enjoyable, and it's just a dot bouncing back and forth between two lines. A game's entertainment value is not linearly proportional to its graphics and audio quality. Increasing quality provides diminishing returns. I intend to use programmer's art myself. We can separate the data about how objects work from the data about what they look like and sound like. My game is set in space, but for my early work I am probably going to use a simple sphere textured with a smiley face to represent stars and planets, and a random model to represent spaceships. For all I know I might use a cow model to represent a spaceship. I could call my game "Cows in Space". The game will still play the same. If we lose a pawn for our chessboard, we can substitute a coin. We still use it the same way. Same principle. Of course, I understand the desire to present a compelling graphics and audio experience. After we complete the core content of our game, we can go back and replace programmer's art with stand in art. There are tons of free models, textures, and sounds on the Internet. As long as we respect intellectual property rights, we can use many of those resources to take our game one step closer to what we envision. Sure, one modeler's spaceship might be inconsistent with another modeler's spaceship. At least I have spaceships. At that point, hopefully we can show off our working game and attract interest. Maybe we can entice better artists and modelers to create better art for us, or we can attract investors and purchase services to help us complete the game. We could release it for free and see if a modding community develops around it and improves upon it. The point is, we can make a game without being modelers or musicians. I hope this helps. Good luck, to both of us.
  14. The ideas here reminded me of the Google Sponsored AI Challenge 2011. [url="http://aichallenge.org/index.php"]http://aichallenge.org/index.php[/url] Also: [url="http://en.wikipedia.org/wiki/Programming_game"]http://en.wikipedia.org/wiki/Programming_game[/url] [url="http://programminggames.org/"]http://programminggames.org/[/url]