• Content Count

  • Joined

  • Last visited

  • Days Won


whirlibulf last won the day on October 7 2013

whirlibulf had the most liked content!

About whirlibulf

  • Rank

Profile Information

  • Gender
    Not Telling
  1. I agree with Damir, a complex html5 game on mobile is going to be very difficult. My game is pretty large, and I know it will not run at all if played in a mobile browser. I had to package it up with ejecta to take advantage of opengl rendering. Even then, there are issues with memory usage, so I had to use compressed pvr textures which cannot be loaded through a browser either. Basically, all the most productive tricks involve moving parts of the game to native. Now it's a packaged app in the app store, but now it also needs to be further optimized to support older ios devices. You can't limit your app to just certain devices, and if your game doesn't run on older devices, you'll get bad app store ratings. Not that I am trying to discourage anybody! Your game sounds pretty cool and I'd love to see more of it!
  2. I use vim mostly. If I have to use another editor, I use vim keybindings wherever possible.
  3. Valve have already announced that there are many games that can run on Steam OS:
  4. See, I don't know where you are getting this. How do you know that their OS is going to be so different that all existing games won't work? As far as I know, we don't have any information about their OS yet. You are just making assumptions about everything. And why would they change it so much that existing games stop working? That would be incredibly stupid. They would be releasing an OS without ANY games. They have already ported all of their games to linux, it makes sense that they would ensure their OS can run their ports, otherwise what was the point of porting?
  5. Steam OS is free and available separate from steambox. If you don't want to buy a console but still want to play games on your tv, you can get steamos. Not your entire library will be incompatible, there are many games on steam that work on linux. So I assume those games will work on steam OS. Anyways, I'm sure steam will be pushing lots of developers to port their games onto steam OS, eventually the library of games will be closer to the PC library. Actually, buying an xbox one or ps4 will make your current library of games useless. How many of your current games will you be able to play on a next-gen console? The answer is none. At least steam OS will allow you to stream PC games.
  6. Why don't you think it will be successful?
  7. Thanks guys Here's a new video of raiding another player's house: http://www.youtube.com/watch?v=CV6HzM26iY8
  8. Some feedback: var typeCounter = 0;var TYPE_CLOCK = typeCounter++;var TYPE_POSITION = typeCounter++;var TYPE_VELOCITY = typeCounter++;var TYPE_RADIUS = typeCounter++;var TYPE_COLOR = typeCounter++;I don't like that you have to manage component types manually. This could be done by the library and prevent potential user errors. Maybe something like: world.registerComponent(Point);var ball = world.create();ball.add(new Point(5, 10)); //And in your systems:this.registerComponent(Point);I suppose passing around the constructor function might have performance implications, but it looks nicer to use. Or you could do a hybrid and pass the constructor function to the library, which will then return a library-generated type ID so the user doesn't have to use a type counter. Other than that it looks pretty good. What are your future plans for makr.js? I recently changed whirlibulf from a game engine to a basic library similar to yours.
  9. http://www.youtube.com/watch?v=d3-8qgyh30U This game I've been working on for the past 6 months is in the app store! Currently it's only in a limited number of countries because it's still in beta. Screenshots: http://imgur.com/a/Ev0eW Youtube trailer: http://www.youtube.com/watch?v=d3-8qgyh30U Here's the app store link, although it might not work for everybody yet: https://itunes.apple.com/app/id608855172 It's all written in javascript, and wrapped up with ejecta!
  10. Well, whirlibulf does this CraftyJS is slightly similar to an entity system but it's not quite the same. I'm not sure of any others in javascript, although I'm sure many people are working on them right now. The idea is that properties (components) are stored separately from entities, even though it conceptually belongs to an entity. This allows you to process components independently from each other. A rendering system doesn't care about the AI state, input state, etc. of an entity. All it needs to know is what to draw, and where to draw it, so that is the only data that the rendering system needs to iterate through.
  11. Here's another nice introduction article series on entity systems: http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ @Chris - Entity systems are about composition over inheritance, not performance. For example, if you have a player entity and a monster entity, both need position because they need to be able to move and be rendered somewhere. For an example OOP approach, you might have two classes, Player and Monster, both inheriting from a simple BaseEntity class. What if one type of monster needs to go underwater, and one kind needs to fly? You add some new classes, UnderwaterMonster and FlyingMonster extending Monster. What if another type of monster can both go underwater and can fly? What do you do then? What if monsters have different kinds of attacks - melee, range and magic? Do you now have MeleeMonster, RangedMonster, MagicMonster? What about UnderwaterMeleeMonster, FlyingMeleeMonster, UnderwaterRangedMonster, etc.? Now what if the Player class also needs to go underwater, fly, and have different kinds of attacks? Quite simply, inheritance is not a model that works for most games. There are far too many kinds of entities with different shared properties and behaviour. If you were to do this in OOP, you would have a huge mess of classes. Wouldn't it make more sense if Underwater, Flying, Melee, Range, and Magic were separate components that you could easily add to any entity, where the logic is separate from entities? A flying system shouldn't care if the entity is a player or a monster, or a brick, and if the entity can go underwater or not. As long as the entity can fly, then the flying system will handle all the logic for making it fly. Can you explain what you mean? The design has very little to do with language and can be implemented anywhere. From my own experience, javascript hasn't hindered writing an entity system in any way. As for performance, there aren't any known benchmarks for entity systems in javascript. As I said, entity systems are not necessarily done for performance, but they can perform just as well or even outperform simpler approaches. There's nothing bad about it, it's just a simpler approach, and is already the first steps towards an entity system. A proper entity system is easier to maintain and more flexible.
  12. There are a few ways you can do it. You can use bit masks, where each component type corresponds to a single bit position. You would still need to loop through each entity's bitmask to check for the presence of components but it is a very fast check. But bitmasks don't work very well in javascript so I had to try something else. In my engine, systems can make the engine index certain combinations of components. When components are added, it loops through each index to see if the entity matches any, and adds the entity's ID to the index if it does. Then the system can request all the entities for a specific index, which is done in constant time. There's no need to check which entities match because the check was already performed when the component was added. This adds a tiny bit of overhead when adding or removing components but ideally this would be done during a loading screen. You can see my indexing code in my entity manager: https://github.com/whirlibulf/engine/blob/master/lib/managers/entity.js And some instructions for using it in a system (see "Working with entities and components"): http://whirlibulf.com/docs/systems.html index is the function called by systems to let the engine know which component set is required by the system. updateIndex is called when a new component is added to an entity. match is called to compare an entity's set of components with an index's requirements.
  13. I made an ECS game engine, you can see it here: https://github.com/whirlibulf?tab=repositories `engine` is the repository for the main ECS management code. `pong` is a demo pong game using the engine. And the rest of the repositories are systems and components built for the engine/demo. And some basic documentation on the website: http://whirlibulf.com/ The nice thing about ECS is that it is very modular and data-oriented. All the systems and components are in separate repos, and for a game I can just pick and choose which ones I need/want. Once I've done that, all I need to do is define all the entities in data files, and write any systems for game-specific logic that are missing. I haven't used it in any actual games yet, but I do intend on doing that soon and trying out some more complex systems. It's not really an engine though, it's more like a tiny library, with some other supporting (optional) files. Right now I'm trying to figure out how to do scene management, entity grouping or parenting, and UI stuff. This isn't a huge problem really, because systems only loop over entities that have the necessary components. For example, the rendering system does not process entities that don't have a renderable component, and the movement system doesn't process entities that don't have both a position and velocity component.
  14. Explanation of the jsperf results: Prototype init is faster than closure init because objects created from the prototype don't need to allocate memory for the functions. They are part of the prototype, and all instances share the prototype functions (instance.get_name is just a reference to Person.prootype.get_name). A feature of this approach is that if you edit the prototype, you automatically update the implementation of all instances. Using closures is the opposite - every instance creates its own copy of the functions. You could edit the implementation of an instance, and you will only change that instance, the other instances will remain the same. There is no way to update all the instances after they have been created without updating each one of them one at a time. Prototype function calling is slower than closures - this is a side-effect of what I just described above. In a prototyped object, if you call person.get_name, the javascript vm needs to do the following: Check if person.get_name is defined (in this case it is not, get_name was defined in the prototype, not the object) Check if person.prototype.get_name is defined (in this case it is) (If it was not found, it will look for person.prototype.prototype.get_name, and repeat until the end of the prototype chain) So you see, when you call a prototype function, it needs to spend a bit of time 'looking' for the function. The longer your prototype chain is, the longer it takes. Since closures have their own copy of the functions, when you call person.get_name, the function is immediately available to it. It doesn't need to look up the prototype chain to 'find' the function. You can get around the slower call time for prototype functions by keeping a local reference to the function, with something like var func = Person.prototype.get_name, and calling func directly.