Chris

Members
  • Content Count

    366
  • Joined

  • Last visited

  • Days Won

    9

Everything posted by Chris

  1. You will get the german page if your browser prefers it. Everyone else gets the english version.
  2. Hey guys, some of you may already know that I am a web-developer for a living. I recently created an application that just went into beta status that helps web-developers and web-agencies collect feedback from their customer or make internal quality control much easier. I am looking for beta testers who use the app and give me some feedback about it! Additionally I'd like to discus with you how I could tweak the application to directly support game development! Because I think many game developers would like to have a tool where testers can submit a screenshot, description and additional data just with a simple click in the browser. Feel free to give it a try and don't forget to leave a comment or suggestion! You can find the project's website at http://insite-feedback.com
  3. Whoot, raising this topic from the graves of the board Gamekit is not dead. In fact, its currently very alive and gets a lot of development progress since I finally started building my first real game after years of just bubbling around in the community Have a look at the updated documentation on http://wearekiss.com/gamekit You can help with the development and documentation - both hosted on github. As always - opinions and feedback is very velcome. The last thing I implemented and wrote about is the particle system.
  4. Hello tejveer - welcome to the board! From reading your op text, I am guessing that you are coming from a development place outside of the browser world, is that correct? There is a lot of things you don't have (or even can't) take care of in the browser world. About the rendering: The browser handles the page rendering with a frame rate of 60fps. You are given a API to use that update cycle to draw to your canvas in the same interval. The API I'm talking about is called requestAnimationFrame. Its basically a callback function that is being called at the same framerate as the browser window itself. Bonus: The callback is stopped being called when the window looses its visibility (browser minimized or switching to another tab). This also helps with saving battery. You could now call your game logic as well from the RAF callback. You could also set up conventional javascript timers, but they have two drawbacks: they may "stutter" (increasing and decreasing their call rates slightly) - and they continue to run when the user switches away and the RAF callbacks stop. The next thing is: Javascript runs single threaded. You have web workers, thats right - but the main thread coordinates everything, including the rendering. You cannot break out of that. The only thing you might use web workers for are very complex operations like some AI calculations or background stuff that can be calculated asynchronously.
  5. Man, no update here for a loooong time Well, I was very busy. I got married, spent some time in spain and had lots of work to do. Luckily, I hat a few ours of time left on sunday and was finally able to continue my work with gamekit I implemented Spritemaps! I wrote an article about them in the gamekit docs about general usage and defining animations. Feel free to play around with it and don't forget to post some feedback And remember: every demo in the docs can be modified by you to test things out!
  6. It theoretically is, but sadly I have very few free time to work on it. I started developing Tyler on top of my tilebased engine "Mosaik" which Is deprecated in favor of gamekit by now. I still need to port Tyler over to gamekit. Since I sadly only have limited time and use it mostly for my company, the development of gamekit and Tyler (which happens only on free time) progresses very slowly at the moment. I hope to be able to work more on it again in a few weeks.
  7. And the german version of the article is now available as well
  8. I just added a few inline demos with code examples into the article. Hope this helps
  9. If the player collides with a moving sprite, switch it to a "follow mode" and update the players x-position together with the sprites x-position. If the player jumps and the collision is resolved, the follow mode is disabled again. If you want to be tricky, use acceleration instead of plain x-position copying, so the player remains at the moving sprites' speed when he jumps into the air
  10. Hey, I am finally taking the time to write some documentation for gamekit and I just finished an article about Sprite animation with gamekit. It would be great if a couple of people would read through the article and give me some feedback if it was understandable at all and if there were some spots left unclear. Here's the link: http://wearekiss.com/gamekit/en/article/animating-sprites greetings, Chris
  11. Won't the examples work if you simply point the browser to a local URL without HTTP? So for example: "file:///whatever/folder/examples.html"? Or do they need AJAX functionality? There _is_ a documentation for modoJS, but since its not jet officially released (should happen this week), its not available online. I'll get back to you when its there
  12. @Deltakosh: Talk to rich about using Typescript for an OS project. He started Phaser in Typescript, I thought it was not the best idea. In the end he had so many problems that he invested days to roll everything back to vanilla JS.
  13. I'm looking forward to that article. Especially for an opensource project, I personally would never go away from plain JS, because you are locking out a LOT of potential contributors. But lets wait for your article
  14. A little note: I started writing a documentation for gamekit. I will write it in two languages (english, german), right from the beginning. Find the docs here: http://wearekiss.com/lab/gamekit
  15. Well, you can always fork the project on github and try to improve it. If you have added some good features, you can send me a pull-request and I'll try to re-integrate it into the project.
  16. Afaik, all browsers that support <canvas> also support localStorage. So... well, enough sayed
  17. Idk why you would need any library to use localstorage... Oo Its really just: localStorage.setItem('myItemKey', 'myContent');and localStorage.getItem('myItemKey');Only thing to keep in mind: localstorage can only store strings. So in order to store whole objects, do this: localStorage.setItem('myObject', JSON.stringify(myObject));and in reverse: myObject = JSON.parse(localStorage.getItem('myObject'));
  18. Well, yeah... But Warp doesn't need you to have nodejs installed on your machine at all. It also keeps a list of the recently used folders and I have a lot more features planned so far that you can find in the initial post and in the github readme. So its not so simple as just using the http-server module
  19. I already mentioned that you could h264 encode your images with javascript in my previous post Recording video while a game is played back just doesn't make sense. Not even native games you are playing on your pc or console are doing this. It just takes up too much resources that are needed otherwise.
  20. ...you know whe have a thread here where we collected a lot of good JavaScript learning resources.
  21. This is surely a safe way to crash even modern browsers on decently powered machines: constantly taking full screen (okay full canvas) screenshots, converting them INTO A DATA URL (so just add +30% space, jay) and then storing them. This blows up your memory in no-time! Hooray! Honestly - the idea is a trainwreck. Sorry to be so harsh but you will get nowhere with this. There is no way to create an actual replay video out of the captured data, nor will you ever be able to transfer the replay to a server since it will grow HUGE even after a couple of seconds. Okay, you COULD implement a JavaScript based H264 encoder that you feed the images to and convert them to a mp4 video on the fly. Yeah. But always remember you are trying to RUN A GAME on 60fps at the same time. If you really want to create a decent replay system to be integrated into game engines, then create a system thats able to store canvas states - "keyframes" - every couple of frames. That means NO image data but position, rotation, scale and what not of all objects. You could then use a library like greensock to tween between the values when you want to play back the recorded replay data. When playing the data back, all values have to be feeded back to the engine. That task is huge, complicated and surely a hell to develop. But its the only way to make replays available on all kinds of devices while keeping the captured data on a reasonably low amount. And if you manage to create such a system, I'm sure there will even be developers out there that will pay you real, hard money to license it.
  22. Pert, have you ever heard about grunt? It does exactly what you described. Any anything else you can imagine
  23. Yep, autotiling is a must-have feature, imho. This will definitely be implemented - I even mentioned them already in my first post of this thread But you brought me to another idea: A kind of Stamp-Tool, where you can "draw" multiple tiles at once. Maybe even on multiple layers. So you could pre-define trees, buildings and whot not, that are made of multiple tiles that belong together. Objects will be implemented as known from Tiled. You can add object layers where sprites of any size can be placed freely with pixel-based coordinates rather than tile based coordinates.
  24. I don't think you need to know the JS language features inside out for canvas based game development. I suggest you to learn everything about if, switch, for, while, objects, natives, functions, scope (!), closures (!), code patterns (!). And of course the featureset of the game engine you want to go with. That should be enough knowledge to write games in that specific direction.