• Content count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About Paratron

  • Rank

Personal Information

  1. Man, feedback is rolling in :) @Ravyne: I have gathered a lot of experience in developing SAAS in the recent years. My company creates such apps on a daily base. I know what kind of features I would have to implement on the server; but the lack of proper save-to-hdd support in browsers is a real downside of that thing. The problem is, that you would want to work with local files, since you need to work with that files inside your game. Also uploading all data to the server first, then downloading again is very tiresome for the user. I really want the application to feel like a native one. Even the FileSaver.js library @l0calh05t suggested (thanks for that!) just triggers a download. Goes straight to my downloads folder in chrome without asking.   So offering Tyler as SAAS will definitely be done - maybe I will even throw in a hosting solution for the generated map data, but imho a offline application with native access to the filesystem is a must :) But hey - maybe it turns out that folks are happy with the SAAS solution and will abandon native apps at all :D     There is currently no website available for Tyler, I'll try and set one up when I have a first version ready (and docs for the module API). Until then, you may just follow this thread - I'll post any updates in here :)   greetings, Chris
  2. I definitely plan to release Tyler as a Desktop Application as well. While it has its benefits to offer the Editor as SAAS - no installation, always most recent version - it comes with a heavy downside: no local filesystem access for saving your data.   I will propably include the usage of a service like dropbox in the online version of tyler, but in my opinion its absolutely necessary to have access to your filesystem in order to work properly with such a tool.   Thanks for the good luck I will try and keep this thread updated when I make further progress.
  3. Hey everybody, I'd like to share my work on my tilebased map editor "Tyler" with you and would like to gather some feedback and ideas during the development progress.   I want to build an alternative to Tiled - the current more or less standard editor for tilebased maps - in HTML5 and Javascript. My motivation behind the project is, that I am currently working on a little browsergame for fun that is also using tilebased maps. I found that Tiled is lacking a couple of features I would want to see inside a map editor - some of them are game specific.   My problem is: its a C++ project, based on Qt. While I am a more or less talented web-developer, I have no clue of building stuff with C++ and I don't want to learn it just to try and extend Tiled somehow   My plans for Tyler so far are:   Support of the Tiled Map format (JSON) Creation and management of palettes (so you can configure things like water-animations right inside the editor) Automatic prettifying of maps with autotiles Minimap generation Object management with free, JSON-style custom object properties Support of own modules/plugins based on JavasScript I am especially looking forward to the users developing their own modules that can be integrated into Tyler with a breeze. I have build a easy to use API that can be used to:   Create own Tools to draw on the map Append containers to the sidebar of the application Append buttons the toolbar of the application Interact with other modules of Tyler by exporting a public module context Through the public module context: Embed new data into the Info-Sidebar-Box Add plugins to the "new map"-process chain. Add plugins to the "save/load map"-process chain, so you can create your own output file formats. Tilers own tools and nearly all functionality is based on that same module system to make sure it gives 3rd party devs the post freedom in creating their own stuff.   Since the whole editor is based upon HTML5 and JavaScript, it should be easy for most people to extend its features to their like. I also plan a public repository, where the most useful modules can be hosted and activated by every Tyler user.   But enough of the talking, here are a few impressions of the editor  - I hope you like it   Screenshot of the UI state from about a week ago:     Screenshot of the layers sidebar panel:     Screenshot of the "Create a new map" dialog:     Screenshot of the current module manager, displaying Tylers core modules:     Most recent screenshot of the tooltips I implemented today:       The editor supports so-called "infinite maps". This means, you don't have to specify the dimensions of your map, when you just want to start sketching around. The map is really infinite - you can simply move around and draw wherever you like.   Upon map creation I added the possibility to chose from different options, regarding the used tileset:   Create Tileset from image You upload an image and it is turned into a tileset (the usual approach).   Generate Tileset You pick which types of tiles you (will) need and in which size you want them and Tyler generates a Tileset of simple colors for you. Great when you want to sketch out some maps, but don't already have a tileset created.   Preset Tilesets You can choose a tileset from a list of bundled tilesets and start working with it.   Isometric maps are currently not supported, but I will certainly add them at a later point in development.   Phew, this post grew quite lengthy... I hope to fetch good feedback and a couple of ideas for my editor   greetings, Chris
  4. Yeah, I read about gifsockets on hackernews recently but I don't think you are able to make use of that. Basically a GIF animation is "streamed" from the server and I don't think you are able to access the single frames in that animation. I also think you aren't even able to access the image object before the loading has finished, which will never happen with the gifsockets method. @EmployeeNumber8: Sure, web workers are interesting for processing the gathered resources, but this thread is more focused at how to transfer the information efficiently.
  5. Monster Paw - HTML5 3D Game Engine

    Well, to be honest - I hadn't had the chance to play with HTML5 audio in any project for now. But I've read a couple of articles about it, especially from the guys who created the HTML5 version of "cut the rope" (google for it, if you don't know it - its great!). I will take a look around and see if I can recover some of the articles regarding HTML5 audio. The biggest problem is that nearly every browser implements other audio formats. So you have to provide a varity of different file formats for ONE sound file to make sure they work in every major browser. But this also got better since it now looks like every browser (but IE) supports WAV files. On the other hand, WAV files are insanely huge and not very web (and mobile) friendly. The next problem which makes sound un-attractive for games is that there seems to be a lag when you try and play/skip/stop sounds. Think about a game where you fire a laser cannon and the sound is 300ms delayed. This feels nasty to the player. Its possible that problems are solved by now - as I sayed, I have to look around again for articles
  6. Monster Paw - HTML5 3D Game Engine

    The sad truth about HTML5 audio: It just isn't ready. So if you are of sane mind, you just HAVE to incorporate a Flash fallback for audio. We all hate flash like its from hell, but in case of media playback you really can rely on it. HTML5 audio is sadly broken (and unperformant) on >80% of the browsers and devices currently.
  7. I can really recommend you to use WebStorm/PHPStorm from JetBrains. The IDE is just awesome. I switched to it coming from a big bunch of other IDEs/Editors before (including Eclipse, Aptana and what not all) and finally stuck on PHPStorm. I simply never found anything superior. And the price is really affordable. If you look for something un-IDE-ish, I would give SublimeText 2 a try - its not specifically a HTML5/web editor but capable of doing anything. See it as a pretty and modern vim.
  8. I really like the idea and implementation of the game. Its fun to play The only thing that really annoys me after playing it for a couple of minutes is that it feels like the character is constantly walking through a sea of glue.
  9. Monster Paw - HTML5 3D Game Engine

    Fun is the most valuable reason you can get Thats why I am currently creating a 2D Tilebased engine + an Asset Loader, too ^^ Let me throw a few links at you which might be interesting for you: maybe you can incorporate a few of those into your engine to speed development up
  10. Well, I did some tests. I created a 500x500 fields "dummy map" with heavily differenciated field types on all layers. Means nearly no field is the same as its neighbours. (It would render out as nonsense-grain but the high difference will make it harder for the compression algorithms to squeeze the data). [url=""]Find the image here.[/url] Storing that data inside a PNG with my RGBA encoding resulted in a PNG file with a size of 288kb after optimization with OptiPNG. Storing the data inside a JSON file resulted in a file with the size of 2.78mb - after a GZIP compression (which a HTTP server usually applies when serving the file), it came down to 1.09mb. You see: even tough the PNG compression cannot work under its "natural conditions", it was still capable of recieving a MUCH better compression ratio.
  11. Wow, thats a quite lenghty post, thanks for the detailed response [img][/img] About point A) I currently decided to stick to three layers with up to 999 possible adressable slots on a spritemap. I would be able to decrease the total amount of slots per layer (since 999 tiles is still way to much, imho) to get more layers. Its just a bit of number-shifting but I could easily go up to about 6 layers and still have ~500 possible, addressable tilemap slots left - fairly enough, imho. I thought about your argument of having tiles sometimes rendered above, sometimes below the player and came to the following conclusion which also answers your point B): About point B) For now, I decided to make my maps like this: bottom layer is ground. Always non-blocking by default. Second layer is for objects, which are always blocking by default. Third layer is decorative, also non-blocking and above the player by default. So dependend on what you place on a field, you get it automatically calculated as blocking or non-blocking. Now, you could say: well, thats very limited - what If I want to have a bush where a player should be able to walk underneath... I would reply: well. Thats a SUCH uncommon usecase, I can just neglect it. [img][/img] We remember from post #1, there are still a few bytes left, which I trimmed away as "garbage". I could store information there that overrides the calculated blocking state of a field, or even which layers should go above or below the player. But with the rules I defined above, I will be able to cover 99.99% of all use cases out there. Point C) I am serving map-data (the PNG) apart from palette data (sprite palettes), so I am easily able to provide the same map in say - winter and summer look. My spritemaps consist mainly of a spritemap-image and a co-relating JSON file where things such as animations, autotiles and effects are defined. Thats no stuff I want to store in my mapdata-image. Point D) Currently, my layers can address 999 sprite slots. I could join every sprite I have (ground, object and decorative) into one palette, so I would be able to place every available sprite on any layer. Still, my blocking rules would apply. I would shift every tile you wouldn't want to set statically (additional frames for animated tiles, autotiles) above the 999 border, since they are placed by the engine automatically. And about your biggest complaint: I am NOT doing this to avoid a level editor. I am doing this because PNG brings a very good compression (basically only DEFLATE, yes but they are doing a few additional tricks to compress more effectively). And because I have not much choice in the browser world. Binary processing of custom files just isn't practicable with JavaScript because it completely lacks binary variable types. They are in draft for the upcoming version of JavaScript, but not available today. At least not in all mainstream browsers. So utilizing imagedata for maps was just a way which is really do-able with JavaScript. Currently a field with this layer-data: [source lang="jscript"]field = { layer0: 12, layer1: 0, layer2: 0 }[/source] would be encoded to this RGBA array: [source lang="jscript"][0, 183, 27, 0][/source] Which isn't something the usual map-creator could hold in mind. So there clearly is need for a level editor. I took a look at qTiled already and altough I think its a nice editor I decided to create my own (in HTML/JS).
  12. @slayemin: i am currently storing 3 layers with 999 possible tile types in the PNG file
  13. Monster Paw - HTML5 3D Game Engine

    Just out of curiosity: why are you using the 2D context, rather than the 3D (webGL) context? One benefit i can see is, that its capable of running on mobile devices, but the performance for 3D rendering through webGL is much better. What are the advantages of your engine compared against three.js?
  14. JavaScript bacame a quite fast thing since interpreters like V8, Nitro or Tracemonkey are around. So its no problem to convert the values around when I need them. I have successfully written two JavaScript functions today which convert three layers for a field to an RGBA value and back. It might be possible to store real layers and other stuff inside a PNG file (Adobe Fireworks stores all that stuff inside PNG files), but I am obly able to access flat RGBA values per pixel in JavaScript. No layers or metadata access. If I really want to incorporate some additional data, I still have a few bytes available in the RGBA space. The idea of splitting a map into chunks is interesting, but imho not neccessary. Even a multiplayer-game wouldn't have a world with thousands of thousands of fields in size. And if so, there is no need to having the whole world stored inside ONE map file. My engine is designed to be capable of loading multiple maps and then nicely transition between them, i.E. fading from one to another when walking down stairs, or sliding from left to right, when you leave a map thorugh a gateway on its left border. So you would basically divide such a huge world in multiple region maps.
  15. Hey, this is my first post here on [img][/img] I am currently writing a tilebased map engine which I want to use in a small HTML5 game - so the engine is written in JavaScript. I want to load tilebased maps of different sizes and thinking about how to transfer them efficiently to the users browser, I came up with the idea of storing them inside PNG files. Every pixel of the PNG image can be translated to a field on the map. Also, the compression of such a PNG file is quite good, so I can easily store a 500x500 fields map (this is incredibly huge!) inside a PNG with about 185kb. This loads fairly quick even on mobile phones. After retrieving the PNG file, I would read the map (sort of) pixel-by-pixel and use the extracted RGB color values to convert them back to palette indexes so my engine knows which field from a sprite palette to draw on which position on the map. Things like prettifying field type transitions (sand to grass or grass to water and so on) are calculated clientside so they don't have to be stored in the map. My problem is: to create pretty detailed maps, I want to utilize 3 layers for each field, like the RPG maker does: bottom layer is the base field type + autotiles for transitions. Second layer are elements like walls, fences, trees and every other stuff you cannot walk over with a character. The third layer is for additional decoration like cracks in walls or windows. I could merge the third layer down to the second layer but that would mean I have to store many many more element tiles (i.E. have to store each map with the crack already rendered onto it) and thats not very flexible. So however - I have have 4 channels per pixel with a range from 0 to 255 (r,g,b and a). If I convert that 4 channels to an integer, I can get a number with the max height of 255*255*255*255 = I would happily throw the billions away and split the remaining max 999.999.999 on thousands for each of the three layers, giving me 999 possible indexes per layer (no, not 1000 since a 0 means: empty layer). I really thing thats more than enough, otherwise the palette to load with the map is just too large. What do you think about that storage method? Do you have any other ideas on how to efficiently store large tilebased maps so they can be read by JavaScript?