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

Xaan

Members
  • Content count

    8
  • Joined

  • Last visited

Community Reputation

157 Neutral

About Xaan

  • Rank
    Newbie
  1. Hey guys,   I'm currently working on an HTML5 top-down simple RPG game, and as a learning experience I'm building my own little engine from scratch. After reading around a little I decided to go with the Entity Component System pattern because I like the flexibility and reusability it brings.   I have a few questions I hope you could help me with:   First, there seems to be some disagreement as to what an ECS actually is - some articles have it that components are just containers for data and subsystems handling all the logic, and other articles have it that components contain methods in them and communicate via some sort of shared memory or messaging system. What's the most widely accepted model of an ECS?   Secondly, I've been wondering about in-game events. I'll explain:   So I started developing an engine that follows the "components are only data containers" rule, and subsystems operate only on the entities that match their requirements (for example, subsystem A takes all entities that have "physics" and "render" components, and subsystem B takes all entities that have "physics" and "health" components).   I'd like the game to be easily scriptable, so that in the yet-to-exist level editor, I could link a particular item (e.g. vase) to another (e.g. mob spawner) and create some sort of correlation (e.g. when vase is broken the spawner spits out a monster). With that in mind, I added the following to my Entity class (which, until now, was just a container for components): Event Trigger - has a "name" field, "predicate" field, and a "data" field. There would be a special subsystem that goes through all entities that have event triggers, check the predicate, and send the event, along with its data if the predicate evaluates to true, to anyone who's listening. Event Listener - has a "name" field and a "callback" field. If the entity receives an event it is listening to, it will invoke the event listener's callback (which will be able to do something like changing the "spawner" component to be ready to spawn a monster the next time the appropriate subsystem looks at it). This pretty much solves the problem I described above (vase + spawner, also allows for scripting events with relative ease). I don't like, however, that there are two ways to "change" components (subsystems and/or events). I usually like that there's only one way to do things, and that one way should be the best way. What do you guys think?   Now, the next problem deals with a different type of event. Say I have a player swinging his sword at a monster; when the "physics" subsystem recognizes that the sword collided with the monster, it should notify the "health" subsystem and the "sound" subsystem of the event, so that health could be decreased for the monster and so that a hit sound could be played.   So the obvious, brute force solution would be to have subsystems sending events to all other subsystems (which is what some ECS articles suggested). The physics system would send an event "entity-A collided with entity-B" every time two things would collide to all other subsystems. Then the health subsystem would check whether it cares about the event and do something about it.    I'm worried about this approach because it seems very computationally intensive and might be a hit for performance. Also, HTML5 doesn't have threads (except web workers but meh...), which would make this easier. I'm just afraid that the sheer amount of messages going between subsystems would be enormous. Also, this approach makes my engine have two completely distinct type of events (one that is inter-entity and one that is inter-subsystem) which is yucky.   What do you guys think? Any suggestions would be very welcome :)   Thanks, Xaan
  2. Well, you're going to have to break this habit of not using external libraries. I have this problem too... Building everything from scratch is so much more satisfying and you don't have to "learn" how to use your own code. That said, you have to break out of this habit.   Networking, at it's basics, is THAT hard. If you really want to learn the very basics of networking, that means taking up the C language, learning about processes and threads, then web sockets and how they work, then HTTP and TCP and UDP, etc... That is all really cool and doable, but unnecessary for you to build your game.   Node.js isn't an external library. It's a server side runtime environment for javascript. All that means is that it lets you write servers (easily) in javascript (which I think is nice, since the frontend of your game is going to be in javascript, too). Before you look at socket.io or anything else, you should google some articles on Node to understand what it is, and then do some tutorials (there are a lot of them). It starts with installing Node.js, writing some javascript file, and then running it from the command line. You'll also want to gain a basic understanding of AJAX. Plenty of tutorials for that too.   Socket.io is an external library to be used with Node.js. It goes inside a js file that you also run as a node program from the command line. The code you posted above is a very simple skeleton of a socket server that is listening on port 80 - i.e. if you want to communicate with that server, you'll have to connect to that.server's.ip.address:80. If that doesn't make any sense, then a few Node tutorials should fix it. In any case, you don't start with socket.io, you start with AJAX and Node.js. By the way, socket.io is an external library but it's so heavily used it might as well be a part of Node's core. Trust me - you will not want to learn how to implement it yourself.   Also, I'm not as experienced as you think. I've had to learn all this in 6 months over the summer to be able to teach a class I helped to write at Carnegie Mellon. Just dive in: a bunch of tutorials on one window and google.com on the other window to google anything you don't understand in the tutorial.
  3. Hi there,   I'm the head TA for '15-237: Building Cross Platform Mobile Web Apps' at Carnegie Mellon University, and I just happened to stumble upon your post and I think I may be able to help.   If you have no knowledge of basic web development (and actually, even if you do), I highly suggest reading "Object Oriented Javascript" [1], and then "Javascript: The Good Parts"[2] - but take everything you read in "The Good Parts" with a grain of salt - some of it is a little extreme.   Once you're done, learn how to use the fairly simple HTML5 canvas API [3]. At this point you should be able to build pretty much any browser-based, client-side-only game you like. Also, there are several libraries that build on the basic canvas API. I heard that Raphael.js is a good one.   As for networking, I suggest working with Node.js [4], which is a javascript environment for server-side code. At that point you should learn AJAX (look up JSONic and RESTful APIs). For real time games, which you seem to be interested in, you should take a look at socket.io [5]. There's not a lot of documentation for it, but it makes real time networking almsot trivial. Just look at some example code around the net and you'll get it in no time. Then, for authentication (player login, etc.) you should look into using either express - a node.js library [6] that handles some of that stuff, or any of the many alternatives around the web. Finally, for a database, I highly recommend mongoose [7], since it works quite well with node and is pretty popular.   It's sort of a long journey, but I think that going through it is going to be much more help than answering your specific questions directly.   Hope this helps!   [1] http://www.amazon.com/Object-Oriented-JavaScript-high-quality-applications-libraries/dp/1847194141http://www.amazon.com/Object-Oriented-JavaScript-high-quality-applications-libraries/dp/1847194141 [2] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742/ref=sr_1_1?s=books&ie=UTF8&qid=1356190548&sr=1-1&keywords=javascript+the+good+parts [3] https://developer.mozilla.org/en-US/docs/HTML/Canvas/Tutorial [4] http://nodejs.org/ [5] http://socket.io/ [6] http://expressjs.com/ [7] http://mongoosejs.com/
  4. I honestly think this is just someone who's trying to convince themselves that their limited skill set is all that matters and that they shouldn't pay any effort to expand it (because that's actually hard work.) -Xaan
  5. I have to say I agree with Simon. I've skimmed this thread, and it seems to me like an attempt at finding an excuse to not learn how to program. In startups, and businesses in general, coming up with a business plan [b]is[/b] an important part of the process. But the people who make the business plan also do other things. You don't have a dedicated "business-plan-writer" who gets to keep 50% of the profit after the rest of the team completed executing the business plan. Having a design oriented person on the team is important - but it's not a full time job. It's also a job that cannot be done if the person who does it is not involved in actually [i]making[/i] the game in any direct way. -Xaan
  6. [quote name='Postie' timestamp='1326493604' post='4902472'] [quote name='Xaan' timestamp='1326398866' post='4902084'] Have you heard of DUST14? [/quote] I believe it's actually called [url="http://www.dust514.com"]Dust514[/url]. [/quote] Yep, my bad. Thanks for the correction
  7. Well, I haven't got anything against either type of game (and actually, as far as monster breeding games, I like the a lot. In fact, there was a pretty good game a while back that made you mix animals to create monsters. All I remember from it is a tiger with claws and that it was set in somewhere snowy, at least the first few levels. Anyone got a name?) but I think you're going to need to think of further utility for the monsters. Right now, as your idea stands, the monsters serve as nothing more than a fancy wrapper for game points (since you need x monsters to unlock the next level). Try to think of a way of incorporating the monsters into the actual gameplay. Like, you could ride one of your monsters to achieve greater speed, precision, jump height, defense against obstacles, or any other power that depends on the monster. Then, by breeding monsters, you combine these powers, or something along those lines. I dunno, make them a more integral part of the game rather than just be a useless carrot at the end of the stick. Xaan
  8. Hi, I'm new here Have you heard of DUST14? It is set in the same universe (literally, the way you mean it) as EVE Online, developed by CCP. It is an FPS, unlike EVE Online which is a sci-fi simulator MMO (I say simulator because while it has tactical combat, a lot of players don't even touch that and specialize in mining, trading, and even just guild-type politics [which is the main force driving pretty much every other activity in the game]). Anyhow, the way the two games interact, supposedly, is that DUST14 will take place on the surface of EVE's planets (which EVE players make use of, but cannot actually land on) and EVE's players will employ DUST14 players to fight over control of those planets (and then the EVE player can gain resources from that planet, use it to fuel his/her empire, etc.) So DUST14 isn't out yet, and the fact that EVE is PC-only and DUST14 is console-only is worrying, it will be very interesting to see how it will play out.