• Content count

  • Joined

  • Last visited

Community Reputation

183 Neutral

About DanielKrej?

  • Rank

Personal Information

  1. Making of Yard Scent

    Hey. I am the author of a new JavaScript framework made for creating games in the browser (without using any 3rd party plugins). I have named it Scent It follows entity component approach and it's based on principles of composition over inheritance. I want to use this journal to describe a creation of showcase game I have decided to make for this purpose. I am not a game designer so don't expect anything spectacular here. With the Scent we will create game that can be easily extended without actually breaking existing mechanics and messing up whole code base. I've been always interested in seeing some kind of game focused on train yard operations, I decided to do something simple around this theme. Lets create the game called Yard Scent. Side-note: Maybe this will inspire someone to create a proper game based on this prototype. I would love to see it in multiplayer where players are connected together and they are sending trains over big world map, earning money, rebuilding their yards or maybe even having more players working on single yard... Game features Here goes some basic brainstorming about game features. It also represents some kind of the order of how I will develop the game. Goal isn't creating perfect game, but show how easily Scent can be used. Yard map I want to keep this as simple as possible. The game will be 2D with tile based map. This will allow me to use editors like Tiled instead of hard-coding map or making my own format. I don't want to mess with curves for the tracks, so I am going to use the way of TTD and create just diagonal rails. Don't expect much of the graphics as I lack proper skills for that. There should also be panning of the map using arrow keys, but there will be no zoom functionality. Switcher Next step is to add some interactivity. That would be a player controlled switcher locomotive. Moving along the rails at constant speed forward or backward and being able to stop. Car will be as big as one game tile to make collisions easier. To avoid derailing the collisions will be solved in this milestone too simply by checking if there is proper rail in the path. Viewport should be centered on the switcher and pan the map when moving. When player uses arrow keys to look around, he can recenter back to the switcher. Freighter cars There will randomly placed cars on the yard map. Switcher can be coupled with these cars (front or behind), move them around the yard and decouple somewhere else. Coupling should be automatic when two cars touch each other. Simple speed modifier of the whole consist depending on how many cars are being pulled/pushed will implemented. This will introduce natural limit of how many cars can be operated by the switcher. Junctions Special tiles that allow to modify path of the train. It's pretty much essential for a good yard work. Along with this I will implement highlight of the whole track based on state of junctions points to easily see the path the switcher will use when traveling. Objectives At the end I will make it feel bit like a game. Cars with different destinations will be placed randomly around the map. Player will be required to assemble consist of cars with the same destination and deliver to appropriate exit point on the map. There will be no continuation or regenerating of cars as it's more than enough for the article. Lets start coding I will be using public git repository at https://github.com/FredyC/yardscent to store game code. Feel free to fork this repo and create modifications of the game on your own (it's MIT licensed). If you feel like you want to improve my code, you can send in the pull request. Workspace setup Some basic preparations are necessary. I will use tools that I am familiar with to speed up whole process. If you are unsure about something, you can always ask in the comments. List of tools used: NodeJS + NPM Grunt Browserify CoffeeScript + Jade + Stylus Yeah I love CoffeeScript because it makes me more effective. Scent is also written in CoffeeScript, but it doesn't require from you to write your game using CoffeeScript. All code snippets here will be written JavaScript to make it more accessible. Also using Jade + Stylus is just natural choice as it fits well with code style of CoffeeScript, but these are not that important. When you clone the repository, you will need to install NodeJS + NPM first. Then you can run npm install in cloned folder. You will also need to run npm install -g grunt-cli first in order to execute grunt dev to start development server. Browse to the http://localhost:9000 to see the game and it will be automatically reloaded if you change source code. Timing the engine First we need to create the Engine instance and call its update() method periodically so it can do its job with nodes and actions (more on that later). I've picked the CreateJS suite that has timing mechanics already included. I am not going to talk about this much as it is unrelated to Scent. Since the stage object will be useful in our systems later, we can use Engine injections to pass it in. This way we don't need to pollute global object of the browser and the stage will be provided to us when needed. [rollup="Using engine injection"] var engine = new Scent.Engine(function(engine, provide) { var stage = setupStage(); provide('$stage', stage);});engine.addSystem(function($stage) { // $stage is here for you});[/rollup] Setting up components Last thing for this entry I will prepare piece of code to setup component types based on their definition. This is one way to do this, but its up to you how do you want to pass your component types around. For now we can define first component to represent position on the map. [rollup="Defining component types"] var components = { tile: 'x y'};for (var name in components) { var component = new Component(name, components[name]); provide('$c' + capitalize(name), component); components[name] = component;}[/rollup] Wrap up And that would be it for now. We will get to the fun parts in the next entry. I hope it looks bit interesting to you and see you next time. Daniel K.
  2. Is there framework/library comparable to Angular but with more programatic approach? http://t.co/WVkygH0JVv
  3. Can you core review this small piece of mine please ? http://t.co/75Ff9jnKzY
  4. Dneska sem si p?ipadal jak v Praze (p?estože sem v HK), kolona snad 10km od HK na Ji?ín (po?ínaje n?kde u Kauflandu). V opa?nym sm?ru to není o moc lepší. Každopádn? mi trochu uniklo kv?li ?emu to bylo. Na jedný k?ižovatce strašili stáli dva policajti a za nima už to jelo plynule dál, tak fakt nevim :)
  5.   I think this is very nice summary. I just would like to add one more - testability. Writing unit tests for systems is much more easier as you can just set input value for the component and then write expectation for the value in the component. It cannot get easier than that.   And for the debuggability ... it is true that breakpoints for one entity are hard to achieve, however there is opportunity in the fact, that you can make "snapshot" of the entity and then rerun this snapshot through the systems how many times you want. Since everything is so separated, you could even run whole code with just that entity there and see what those systems are doing with it. Having unit tests (ideally with 100% coverage) really helps too as you can just apply this snapshot there and see where it breaks.
  6. I think you are reading it correctly, although I didn't meant to share all the components. It's per case and if it desired by design. I just wanted to point out, that by removing components completely, you are losing this possibility, because each entity needs to have own copy of data.
  7. Interesting article. I am working with entity component model lately and so far I am more satisfied with it than with OO. It needs a lot of mental adjustments to understand how to design the game differently.   Anyway, I want to point out one thing. When you remove components from the flow and store all data in the entities, you are losing some important features - shared and/or reusable data.   Components as the smallest data unit can be easily shared among other entities. That means you save some memory and also some processing time, because changing component in one entity makes that change applied to all other entities that contain this component. That can be very useful in some scenarios.   For example you want your weapons to have all the same base stats. You can create one component with that and assign the reference to all weapons created. Later you may decide that all these weapons need little tweak on one stat, so you just change it in that one component and it's all good. If you need one weapon to be special and stand out, you give it just its own component with own stats.   Other feature I have mentioned is reusable data. This can be handy for example for positioning. Instead of having like 10 components with the same X,Y,Z just because there is more items on that very spot, you can simply share one component among them. Other use is for pooling where entity gets removed, but some frequently used components can be stored in stack and reused for new entity. Garbage collector will be more happy this way, less mess to clean up and smaller overhead in creating those objects all over again.
  8. Multiplayer survival browser game

    Hey Hotrootsoup. As i have been playing die2nite for couple of days now, i have been looking for similar game to it, because i love the idea, but D2N has some things i don't like. So i stumbled to this post of yours and maybe I would like to help you with that. However thing is, that i'm Javascript coder too mostly. I have like 7 years experience with PHP and 2 years experience with .NET technology (mostly ASP.NET), but client side scripting gets me more and more in this time. Using node.js seems like a right choice, because of same language on both side, but i have no experience on that field unfortunately. I am not an artist and designer, but i think i have some sense for good looking and working GUI, so the people are not lost. If you want to talk about this more, you can contact me on mail [fredy.c at seznam.cz].