Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

253 Neutral

About redmilamber

  • Rank
  1. A lot of people have been making these systems in the past few years (lots of threads in this forum I've read), and rather than constantly re-invent the wheel, I'd like to get more people sharing and re-using code. I'm often asked for source-code, and I usually can't share it because it's owned by whichever company I'm working for. So ... I've started going through my old entity systems, and re-writing them in clean, simple code. I'm going to try and get versions done in several different languages, so you can read one description, and download working code in a language you're comfortable with. But ... there's many different ways to make an ES, there's no "right way", so I'd really like for some of the other people on this forum to do the same with their own preferred approaches: document them, implement the simplest-possible-version in a programming language of choice, and share it. I've started a small wiki for this on wikidot: http://entity-systems.wikidot.com/ I've documented the most empirical form of my own preferred approach here: http://entity-systems.wikidot.com/rdbms-with-code-in-systems ...and created a tiny github project with Objective-C source here: https://github.com/adamgit/Entity-System--RDBMS-Inspired--Objective-C- (the plan is to do a separate github project for each alternative component/entity system, in each language - that way anyone can download code easily, and share improvemetns/fixes/etc) ...but this would be much, much better IMHO with multiple people putting their own stuff in there. I'd hope this is helpful to people starting ES's of their own - either as a starting point, or as something they can pull to pieces and try out in code, to help them understand, before starting their own.
  2. Quote:Original post by s.kwee KulSeran Thanks you for the link, it very interesting. However I think its a bit of extreme way of thinking (maybe just for cause I think OOP), but comparing ES to RDBMS? I mean yea, it looks like they have thing in common, but I don't know, sounds weired to me. What you're suggesting is already "weird" by OOP standards: you're THROWING AWAY one of the most famous and key parts of OOP. As for ES and Component stuff ... Yes, it's hard to understand at first - it's new, it's different, it's NOT the way you've been working. You have to learn new techniques, new thought-processes. But, if you don't ... you'll probably end up sleep-walking into the same old trap that OOP had you in to start with.
  3. One question: Quote:Original post by s.kwee 7. Dependencies between components. There are two ways of communication needed for components: Why? So many programmers pick up the idea of a component system, then insist on having this "inter-component communication", without justification. I keep trying to persuade people NOT to do this, but I'd love to understand better WHY programmers are so desperate to do this - what am I missing here? Personally, I tried this in my first component system, and it quickly became obvious that it was just making for a huge amount of boiler-plate code, a huge performance penalty, and served no actual purpose in the game itself. (although it took me some time to accept that last part - by then, I'd written so much code for it that I didn't want to admit to myself how much time I'd wasted :)) It's so long ago that I can't remember why it seemed right at the time, so my own experiences here are useless.
  4. redmilamber

    Having trouble with the big picture (architecture)

    Quote: I am currently using a component based design, where every object ingame inherits several different components, and each component manages itself. Example: That's not what most people mean when they talk about "component" design in this context; in at least one way, you're doing the opposite of what most people mean. I suspect this is causing a lot of your problems. Quote: I've tried 'has-a' components, and it makes more sense for components, but the problem is, it massively increased the amount of code I needed to write. You didn't give the full details, but I would *guess* that this is because you didn't get the right arch for doing has-a design. It *should not* significantly increase the code required (in many cases, it noticeably reduces it). I suggest you read the early t-machine articles - my *guess* is that you fell into one of the traps of: thinking you were escaping OOP, and then accidentally writing OOP code in the middle of your component artchitecture - thus DESTROYING the whole component system. What you describe - especially the "massively increased the amount of code" - is a classic symptom of that trap. (it's a subtle problem, and it's worse - and harder to spot - the more experience you have with OOP. When you know OOP well, everything in the world starts to look like Classes...)
  5. There aren't really any. Certainly I could find any good ones that are free. Mostly there's studies that record stats on the apps themselves, or their players / consumers (e.g. the one from the start of this year giving replay rates, engagement levels, etc). I wanted to know more about the other groups actually making the iPhone apps, so I setup a 5-minute survey here: http://www.surveymethods.com/EndUser.aspx?BB9FF3EEB9FAECEB ...with the promise that anyone who completes the survey sensibly (i.e. I'll prune out any obviously made-up entries) will get a free copy at the end of the aggregate results of all the questions. e.g. for a question asking "how many people in your team", you'd get: "30% of respondents have 3 team members, 20% have 4, 10% have 5" etc. That way, we each get some decent, interesting stats on who else is out there, and what's "normal" - and all for free (and I've deliberately included a bunch of questions that might help people who are trying to get funding for their projects and need to throw some stats into their presentations!). So, if you're doing iPhone development, please take 5 mins to fill out the form :). NB: I'll also anonymize the results before I send them out. This is really about the aggregate data, averages, ranges, medians, etc - not specifics of individual teams.
  6. redmilamber

    Component Oriented Design

    Whilst I don't disagree with your complaint about ignorance and the (sometimes terrifying) delay in propagation of ideas, I feel you miss something out that is both peculiar to the games industry (and a few other niche industries) and explains a lot: practicality. Your descriptions of COD are interesting, but so abstract as to be useless to a mainstream game developer; half of what you describe is indistinguishable from SOA, which may (theoretically) be interesting and valuable, but is proven irrelevant and useless to game development because it's too inefficient by a long, long way. We're talking about a niche industry that is still worrying about instrution-cache-level optimization (not even just data-cache) because it still matters, sadly. Kylotan's comments are great, disbelief and questioning are needed, but until he shows some sign of appreciating the realities of implementing this stuff - even something as simple as launching a game that shows he's right, and which he uses to give practical examples of *why* he's right, and why his experience flies in the face of my own experience - I'm afraid I'm going to continue listening to people who I know have done this stuff, continue to do this stuff, or who have the experience to extrapolate meaningfully.
  7. Quote:Original post by Trefall I've learned that there's a lot of debating on what exactly a component should be though, and what exactly a system should be. In adam's approach, referred to in the OP, I get the impression that a component is just a container of data, but that each type of component also comes with a complimentary system that can process that data in some logical form. Yes, it's about the separation of logic and data. i.e. the antithesis of Object Oriented Programming - and this is a large contributory factor to why so many game devs switched to doing it (at least for mainstream games dev): OOP has turned out to be almost pathologically bad for modelling game-logic systems as they've grown to the complexity they are at these days. I think there's a certain amount of guilt that no-one wants to slag-off OOP, because it's not so very long ago (maybe a decade) that many games industry teams were refusing to use OOP at all. There are even some (I know of at least one) well-known large game development studios that only code in C still - for all aspects of the game (the vast majority of modern game programmers consider such behaviour ... odd). You, of course, are free to do whatever you want. With simple logic (e.g. to power a basic FPS like Doom or Quake) I'm sure you'll be fine. Those of us who have first-hand experience with the nightmare of intertwined logic/data game-object systems and never want to go there again will happily go on our way with a cleanly separated system. But if you want to build the complex logic that underpins a modern FPS, with all the world-simulation stuff, then I'd advise you join us. If you want to work on an MMO, god help you if you decide to persist with mixing up logic and data - that way (at least on any MMO that survives more than a couple of years) lies madness. IME. YMMV. Quote: In my approach I have the logic handled in the components themselves, but since it's the components that get instanced, and not the component systems, I'm sure there's quite a lot to save doing the logic system side if one can generalize enough to do it that way. I'm afraid I cannot see any way in which what you write here differs from standard OOP. That's fine, I've nothing against that. Am I missing something? You have instanced "things" which contain code and data - that's a standard Object, no? But if I'm not being dumb, and that is the case, why you don't just use the standard game-industry terminology, call your components "GameObjects", and have done with it?
  8. Quote:Original post by Kylotan Quote:Original post by virus- I've read pretty much everything I can find about entity/component system and while I earlier had a bit different implementation in mind Adam's posts about entity systems made me think of a bit different solution. I cringe every time I see someone cite that URL. I find issue with so much of what is in that blog, sadly. Have you raised your specific objections on the blog? Lots of other people have. If you keep quiet, no-one can help you. Quote: Then again, I also cringe whenever anybody calls it an 'entity system' since that description doesn't really say anything, given that 'entity' could mean just about anything. The word 'component' should at least figure in there. Terminology is a shared game that none of us get much say in. Entity System is a phrase that's stuck, at least for the differnet programmers I've met within the game development companies I've worked at. I agree that you could invent better names. For instance, my favourite is "Component-based Entity-centric GameObject System", which pretty much fully and clearly defines it in less than one sentence. Unfortunately, that's too many words, and no-one uses it other than me. OTOH, when I say "entity system" in the office, so far *everyone knows what I mean*, which is a compromise I'm willing to accept.
  9. I've just posted: http://tmachine1.dh.bytemark.co.uk/blog/index.php/2008/01/22/java-nio-server-example/ (very simple non-blocking NIO server with fully documented source) I needed something very simple I could use with Slick to write multiplayer games in under 16 hours each (i.e. one weekend at a time), and simple and plain enough that I could easily change it, replace it, fix it, etc. NB: this is not intended to replace or compete with the existing full-fat java networking libraries people have written. This is the simplest possible thing I could come up with, and you'll probably find it more useful for teaching yourself NIO than for anything else. But, that said, I am actually using it in mini games including one I've already written (will post that game sometime in the coming weeks). What does it provide? 1. a very simple network protocol (4-byte message length followed by message) 2. a single-threaded NIO server that copes with fragmented packets properly (took a lot of testing, but I *think* it works in all cases now) 3. a simple Charset-based decoder to convert all messages into bytes and vice versa 4. two abstract methods on the server that allow you to a) receive any incoming messages and b) perform "server-side game tick stuff" after each Selector.select 5. a tiny client that connects with NIO and implements the protocol Simple stuff that most people have written for themselves by now. I thought this might be a good tutorial for people who want to know the simplest possible example of getting NIO to send and receive strings ! (and ... at 500+ lines just to achieve that, I think I've underlined quite how low-loevel NIO really is!) Fairly detailed javadoc here: http://tmachine1.dh.bytemark.co.uk/nioservers/javadoc/ NB: it's not very *good*, but I was experimenting with following the rules of Scrum correctly (i.e. make it work "just good enough" in the absolute minimum possible amount of coding time). There is one known bug that you are unlikely to encounter, which is documented with a FIXME, and requires copy/pasting some source from the server's message parser into the client's message-parser, but other than that it seems to work well enough - I've done a multiplayer tetris clone that worked fine with it. Some time in the future, after I've used it a bit more in quick-n-dirty personal projects, I'll release an update. Or sooner, if anyone sends me fixes.
  10. Quote:Original post by Kylotan Quote:Original post by redmilamber large-scale batched loading of data (e.g. level-loading) I'll assume that last line is the main point you're getting at. The thing is, large scale batched loading of data is trivial. 95% of what you load in will come in either standard formats, or optimised formats you made yourself. Nope. Here's a simple statistic to give an idea of what I'm getting at: the typical successful MMO generates somewhere in the region of 100Gb of data every 24 hours: combats, deaths, trades, quest actions, NPC interactions, respawn locations, inventory updates, private messages, ... etc etc etc. (I can't remember who (if anyone) has publically declared the actual number for their game, but you can approximate it for yourself fairly easily, especially given that with many games it's very easy to see data they MUST be keeping simply to implement various of their in-game systems, and on top of that several developers have declared what data they're data-mining) Somewhere between 10% and 100% of that data needs to be kept forever, AND it's generating that much EVERY 24 hours. So, you know, data is pretty central to MMOs, on a scale that simply doesn't apply in normal games. IMHO.
  11. Quote:Original post by Kylotan Quote:Original post by redmilamber Why not? IMHO MMO's are purely about data manipulation Because I disagree with that. All computer programs are 'about data manipulation'. There's nothing about MMOs that makes them more or less so than any other program. Theoreticaly speaking, yes - of course they are. But only at a very abstract level (at that same level, all programming languages are identical, and the only language we actually "need" is the lambda calculus; but practically, they're all very different, and we "need" a wide variety of them). But in practical terms, there is a huge difference between a typical enterprise "business system" written with JavaBeans, where 99% of the code is of the form: Take data Simple conversion of that data from one format to another Simple algebraic check Update a flag somewhere and a typical videogame, where the code is much more evenly divided between: low-level I/O high-level task scheduling complex algorithms to achieve specific effects large-scale batched loading of data (e.g. level-loading)
  12. Quote:Original post by Kylotan Incidentally I don't agree that "Entity Systems are the future of MMO development" as I don't think there's anything specific about 'entity systems' (a term that's too vague anyway) and MMO games. The problems they solve are pretty much the same problems everybody faces - how to generate large quantities of content efficiently. There's nothing new here - people have been saying "prefer composition over inheritance where possible" for ages. It's just that it's taken a while for other people to listen. Sometimes the composition is built into a master object, other times the composition is more abstract (eg. any component with a property of "actor" and a value of "354" is part of the Jim the Goblin actor), but it's essentially the same thing. Why not? IMHO MMO's are purely about data manipulation, and entity systems (or component systems?) are about encoding logic as data, so the two go rather well together.
  13. redmilamber

    Monthly MMO cost survey

    Not quoting from company internal figures *at all* (since that's illegal), but a fair expectation would be around 20k dollars per month on bandwidth for a moderately successful ( > 100,000 subscriber) MMO, and around 5k dollars per month for hardware. That's based on knowing the prices a variety of MMO companies have paid over the last 7 years. YMMV (a lot) and what you should really do is contact companies that actually sell this stuff to MMO companies, e.g. the folks at OGSi (or whatever it's now called).
  14. redmilamber

    Online / MMO publishing

    Ah, OK. I work for a publisher, and can help with pitching games to the company I work for, which is relatively easy for me.
  15. redmilamber

    free MMOs ???

    Quote:Original post by miminawewe I didn't think that ads would be enough to support an MMO. I guess the "free" term is like saying "try out this game demo" but in different way. MaidMarian.com, and Runescape before it, made ... more money than you would know what to do with ... from ads alone. Estimates by various people (google it and you should find some easily enough) put MM's earnings at the best part of a million dollars a year. From ad revenue. Is that enough for ya? :)
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!