whirlibulf

I use vim mostly. If I have to use another editor, I use vim keybindings wherever possible.

Thanks guys Here's a new video of raiding another player's house: http://www.youtube.com/watch?v=CV6HzM26iY8

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.

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!

Really fun game and nicely made! Awesome job!

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.

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.

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.

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.

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.

I've got a pong game implemented with the engine now, you can browse the source code here: https://github.com/whirlibulf/pong Still hoping for some feedback on the engine code You'll notice all the entities and components in the game are completely defined by data files. Soon the config, systems and component factories used in a game can be defined purely in data files too. Then the only code that needs to be written are individual entity scripts, and custom systems.

HappinessSam, the canvas context has a measureText function that can calculate the width of any text based on the context font and size. Just in case you might need it. Edit: oh sorry, this is the pixi.js forum, thought it was a general canvas question

Yeah, that's true, my app is using ejecta so rendering is hardware accelerated. It also loads assets from the local file system. If it were a networked game running in a regular mobile browser, it would probably take several minutes just to load. And I had problems running into the memory limit from loading assets at quadruple resolution for the ipad retina display.

You can still use bigger sprites! context.drawImage lets you specify the destination size. So you can draw a double sized image onto a regular sized area. All my game assets are in normal resolution, double resolution and quadruple resolution so that I can display sharp images from iphone 3gs devices all the way up to ipad retina. I just load the correct image size by detecting the platform. But none of my rendering code needs to change.

Writing a game maker tool is different from writing a game. I think most game engines and frameworks are not very suitable for writing a flexible game maker. But this depends on what kind of game maker you want to make. Is it completely a graphical editor, where you don't need to know how to program to make a game? Is it used for a specific game type, or should it be flexible enough to make many kinds of games easily? One option is to find an entity-component-system engine, since the data-driven nature of it makes it easy to simply put a ui in front of it and update the data without requiring the user to touch any code. This is basically how unity3d works. Why do you presume it has to be developed in typescript?

Hi guys! Just wanted to share my game engine that I am writing, the Whirlibulf game engine! Whirlibulf is an entity-component-system javascript engine: http://www.github.com/whirlibulf/engine Although it's still in development, I think the current engine API gives a good idea of what it will be like on release. I've only implemented a few systems and components so far, so you can only do very basic rendering. Is there any interest for this kind of game engine? I'd love to hear feedback on the API or design!

I recommend taking a look at http://www.cloudflare.com It's free!

I used pubnub for a while. They keep increasing the price or changing the pricing scheme without any notice. If your multiplayer game has small sessions (less than 10 players), it should be fine. If you are using it to broadcast messages to your entire player base (eg. sending a single message to hundreds of players at once) then it is quite expensive. Because of that, it's not very suitable for many kinds of games.

It depends on how you detect the device width. I don't know which of those values window.innerHeight returns, but if I had to guess, it would be CSS pixels. Luckily, you can tell if you need to resize the inner canvas size with window.devicePixelRatio. Just multiply canvas.width and canvas.height by window.devicePixelRatio, and it will display correctly on retina and non-retina devices. Since now canvas.style.width is different from canvas.width, you'll be drawing more hardware pixels per display pixel, which is exactly what you want. However, this means that your canvas will be 4 times larger on retina devices. This is a problem because your game is going to be drawn in the top left quarter of the screen if you continue to use the same pixel co-ordinates for drawing things. So the last thing you need to do is scale the canvas context by window.devicePixelRatio, so that all the co-ordinates you use in the game will be scaled up for the larger canvas area. To recap, assuming canvas.style.width and canvas.style.height remain unchanged because they are already set in CSS, do this: canvas.width *= window.devicePixelRatio;canvas.height *= window.devicePixelRatio;canvas.getContext("2d").scale(window.devicePixelRatio, window.devicePixelRatio); You'll probably want to clean up that code a bit. Remember you are changing both the canvas element and the canvas context.