Krisztian Varga

  • Content Count

  • Joined

  • Last visited

About Krisztian Varga

  • Rank
  • Birthday 07/02/1984

Contact Methods

  • Website URL
  • Twitter

Profile Information

  • Gender
  • Location

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Looks like something I would fiddle around with Keep us posted!
  2. The game looks promising, but I didn't get far. I don't want to put down pugs here, therefore I was going to add them to Trello, but I guess I don't have permission to add tasks to Bugs board. Let me know what you think, how can we work out, how to help me get started with this alpha version. I'm guessing many other people have encountered the same problems, therefore you don't have many comments here. PS: That music man, right at the beginning, perfect choice!!
  3. iDevGames looks well established and your Twitter is solid! You've put tremendous effort into this, I wish you the best of luck!
  4. You can't teach the concept of digital currencies early enough to kids! Well done! ..iDevGames also looks well established and your Twitter is solid! You've put tremendous effort into this, I wish you the best of luck!
  5. The website loaded just fine bet the game isn't. Maybe some other people are experiencing the same issue, that's why you don't get that much feedback... "Uncaught (in promise) DOMException: The play() request was interrupted by a call to pause()" - Latest Chrome on Mac as of today Just wanted to let you know. Probably this is not the best place for bug report so feel free to delete this comment after you've read it.
  6. Nice one! ..why not include the arrow keys as well to control the cookieminator.. or maybe I'm just too oldfashioned wanting that.. :) ..and good luck with the platform as well!
  7. Addictive! ..the only thing I would mention is that the adds interrupt the game, would be nicer to show them at the end of the level or something.
  8. Good progress! I personally think if you only changed as much as using 8 directions to move NPCs not 4, that would improve the look and feel a lot.
  9. I absolutely love the artistic direction!!
  10. Couldn't agree more! For games, the greater control you have the better, for websites, it makes sense - to some degree, but nowadays its a sport to find two lines of code that can be replaced with a npm module. The game looks amazing, downloading it right now
  11. Worked for me on Galaxy S9 ..had to refresh the page first time but then it was working fine. Nice execution @Nagval333, keep going!
  12. Flawless execution, even on mobile! Let me be the first one who congratulates you here
  13. Hey HeadClot, I'm more than happy to address those questions: 1. How big is the game world? How big can the game world get? Its 16km2 - 4km by 4km - at the moment but there is no limit how big it can get thanks to Recursive Search Grid System. I’ll address this below. 2. You mention a grid system. Can you go into detail about this? I am guessing that it is similar to the one that Bethesda Softworks uses in the creation kit. I’ve never used creation kit, but I’ve heard about this technique a few times from different sources so its safe to assume that its a common technique - no credit there for me 😃 The terrain is created with Blender, exported as .obj. The engine imports it in editor mode, split is with the resolution I choose. Then I end up with a lot of smaller terrain pieces saved as JSON files - I’ll refer to them as Cells from now on. Cells contain mesh data and other preprocessed info that makes rendering and Recursive Search faster. Resolution of the Grid: Cells are loaded on demand. When a Player shows up somewhere in the Grid, the first Cell has to load really fast otherwise the Player just looking at a blank screen. Therefore the Cell has to be small enough to be loaded fast enough. But if we make the Cells too small, it's very fast to load but slow to process. Javascript is fast to iterate over a lot of Cells but not nearly as fast as C for example. In the end, its a balancing exercise, and I ended up with 32 by 32. Recursive Search: Finding a Cell as fast as possible is crucial, the cost could grow exponentially when multiple processes involve searching for Cells. Therefore we don’t want to iterate over all of them, but keep track of the Cell that the Player/NPC is standing on and use that as a starting point. Then we can do a Recursive Search looking at the neighboring Cells and their neighbors. In order to speed up the process, we save the links to the neighboring Cells on every single Cell. I’ve done more optimization of Recursive Search because of extensive use but you might not be interested in that, let me know if you do. Loading Cells on Demand: the first Cell and the ones around the player loaded as soon as the game starts. When the player starts moving around in the Open World environment mere Cells are loaded when they get in range. Cells drive the loading of every other asset. When a Cell gets processed, the engine collects the other assets - like trees, rock, etc.. - to put them on the loading queue. So we really only load the assets we need and no more, and we load them in a sorted order. Whatever asset is closest to the Player gets loaded first just like Cells. Dynamically Generated Assets: Grass and clutter use the Grid System as well. The engine only generates dynamic assets for the loaded Cells. They are generated in a different thread to keep the rendering thread smooth and they are not saved in any shape or form. NPC and AI: NPC needs to be aware of their environment to navigate obstacles and find their prey. Same problem here, we don’t want to iterate over all the NPC we use Recursive Search and Grid System to reduce the number of NPCs to be checked out. Precomputed Scene Occlusion Culling using a Grid System: Most of the optimization is happening real-time or triggered on a regular basis while running the game with one exception: the Engine keeps an optimized list of all visible Cells recorded on every single Cell in the Grid. This Optimisation is done in the Editor once the terrain is split: The Engine goes over every single Cell in the Grid and renders them from the point of view of a specific Cell, pick randomly. A Cell is either visible or occluded by some obstacle or just out of range, by looking at it from the randomly picked Cell. The Engine records the visible ones and moves on to the next Cell to do the same occlusion checking. This reduces the number of Cells to be rendered significantly, but it takes about 40 hours to run this optimization for the whole terrain. Possible Improvements: The Engine only uses one resolution to create the Grid. I can see why multiple resolutions could make the engine run faster. Small Cell means less waste. We may only see a fraction of the Cell still precess the everything in it. The engine could use a small resolution to work out what Cell needs to be checked out then a higher resolution could work only with those few Cells to work out the labor-intensive details. 3. In regards to rendering why don't you use an existing engine such as bablyon.JS? Before I’ve started the project, I've checked out the available games for the web, and I wasn’t impressed. I thought there must be a reason why they all look so simple. I’ve noticed that Unity can compile to JS, but it had to load all the game assets in advanced. It took to long to start up a game, and its an obvious limit on how many assets you can include in a game. I come from a strong JS background so I thought, I will investigate the performance of whats involved to make a game run in the Browser ..a year and a half later I’ve ended up with Age of Reptiles Any off the shelf solution comes with tradeoffs. Fast to start, slow to finish when you start hitting those obstacles... I wouldn’t recommend writing an engine because it takes forever, but I ended up with one because I was curious and enjoyed the process. There is an upside though to write your own engine: you can optimize it for what is most important for you. My focus was to load assets progressively, to make Large Scale Open World environment possible in the Browser. If you guys have any other questions, I'm more than happy to go into details.
  14. You've done a great job, especially in a week! I'have a question regarding player movement prediction in multiplayer: when you use the velocity and direction and let's say a player or enemy is heading towards a wall. The distribution of network packages is uneven expectedly. Have you not run into an issue, where a package was in late, that describes a player/enemy turning before hitting the wall, therefore client predicting that it went through the wall, using existing velocity and direction for the prediction. ..I've personally run into this a lot and had to abandon the approach. Is there anything that I'm missing here?
  15. I enjoyed it a lot! Perfect candidate for a mobile game, but for some reason, doesn't let me play it on mobile. You may want to tweak the settings there, just saying