Jump to content
  • Advertisement

Vilem Otte

GDNet+
  • Content Count

    930
  • Joined

  • Last visited

  • Days Won

    5

Vilem Otte last won the day on October 6

Vilem Otte had the most liked content!

Community Reputation

3197 Excellent

6 Followers

About Vilem Otte

  • Rank
    Crossbones+

Personal Information

Social

  • Twitter
    VilemOtte
  • Github
    Zgragselus
  • Steam
    Zgragselus

Recent Profile Visitors

32883 profile views
  1. Vilem Otte

    Bare bones AAA team

    I will just input salary for my country (Czech Republic, next to Poland) - for software developers, so you get the picture. For senior developers the statistics says that on average they require $40,000 per year. For junior developers it is $18,000 per year. These are netto - as it is reported salary by the employees. (Source: Startupjobs.cz) So, your income budget would be (our taxation is around 45%) at $73,000 for seniors and $32,000 for juniors. As senior we generally count somebody with at least like 5 or better 10 years of experience. Often also working for foreign company for few years. Of course the salary heavily varies based on the branch where you work. Of course, you can also try luck in India, which may be even a bit more cheaper - forming even bigger team. The problem is, bigger doesn't necessarily mean better. And when you have to aim at qualified people (often with university degrees and experience) that know what they are doing, the costs difference tend to decrease.
  2. Vilem Otte

    DOOM: Placeholders

    Currently, the only "playable" level is still full of placeholders - I'm still hoping for having the game finished on 18th, but we will see. In worst case - there might be some place holders left (while the game would still be playable). In the meanwhile I have added: Full physics (based on Bullet), not just character controllers, but even rigid bodies are technically supported (I'm still not sure whether I will do anything with them) Ability to control behavior of entities (doors, elevators and such are possible - but I don't think I will have enough time to make art for those, so we might be limited here) Improved the speed of dynamic BVH building by about factor of 10+ (by simply going through my code and removing dumb things) Get rid of most of the limitations (like total texture size was originally limited to just 8192x8192 texels, technically this is much higher now) Finished some sort of player movement I'm kind of satisfied with I'm realistic, the competition ends in about 2 days (and as most of us - I still have to be at work during those). I personally will be glad if I manage to make the scope I wanted for proof of concept demo - that includes: Simple menu (New Game/Exit) Single level Single type of enemy Single weapon Player can die in the game and player can win the game Some sort of Doom-ish UI Some advanced ray tracing effect or two I know this isn't much (and is most likely barely covering the scope for the challenge). In the meanwhile - behold - the placeholders (and no that 0.44 GRay/s is not joking - I'm currently limited by performance of actually displaying the buffer, not ray tracing nor BVH updates at all)!
  3. Vilem Otte

    Bare bones AAA team

    The Witcher 3 development costs were 306 mil. PLN - if you would convert that into USD that is $81 million. Witcher 3 is one of the largest open world RPG games I have played in past few years. I would say that it was a AAA experience. The Witcher 2 development costs were around 40 mil. PLN - about $10 million. I would dare to say that Witcher 2 was also AAA experience, despite being much shorter and not open world like its successor. It is considered as one of the cheaper AAA games. These games were developed in Poland, the costs for employees and living are slightly lower compared to Western Europe, and a lot lower than in F.e. California. You also need to take this into account.
  4. Vilem Otte

    Ludum Dare 45

    Introduction Yet another Ludum Dare event was around, and I found time to participate this time again (this time it is actually 10th Ludum Dare I've participated in so far). So, first of all - if you are interested, just roll down the post and play the game. Short gameplay video: Fig. 01 - A short gameplay video. What went right? This time around, we have decided to dive into the wonderful world of procedural generation quite fast, the actual work on the game started early saturday morning. Being heavily inspired by Angband, the decision was clear - our dungeon levels must be generated. Procedural generation of such dungeons is not really that hard, I have started off with simple algorithm and worked from there: Generate a 2D axis-aligned BSP tree, randomly terminating after at most N levels or when criteria is met Shrink rooms represented by leaves of the BSP tree Make connections in bottom-up order (first between leaves, then between interior nodes and leaves - picking always the closest room to the currently processed one). The results were quite promising, producing blocktober worthy images like: Fig. 02 - Randomly generated dungeon level At this stage entrance and exit were placed, followed by the monsters and power ups which you can pick up in the dungeon. The last thing to solve in level design were first and last level. Although as our levels during the generation phase are defined as byte arrays (containing actual chars defining what is on given tile) we simply used file and injected it into the process. Our first level looks like this: ### ###X### #.#...# #....## ##....# #...#.# ####### Where: # - represents wall . - represents empty space X - represents exit out of the level Apart from actual procedural generation, the development went quite smooth. I enjoyed making a non-realistic cartoon-ish models, and skeletal animation enabled just for the character hands. The models ended up being quite cute in the end: Fig. 03 - Mushroom in Unity engine editor, version without hands The game mechanics also overall felt quite comfortable (as I'd say finished enough to be playable), compared to some of my previous entries. Picking a smaller scope game definitely played in favor of this. What went wrong? As usual, time. Each game jam (and it doesn't matter whether it is Ludum Dare or anything else), it comes to the point where you have to start cutting features out to make it on time. Because at the end of the day for game jam, you either finish a game or you don't. We had to cut out various features that would make the game a LOT better, but most important of those was audio. Sound effects and music tend to improve the atmosphere a lot - or to be precise - it is one of the most underestimated feature of the game, with which atmosphere rises or completely falls. Due to our time constraints we ended up completely without audio in the game. User Interface, second item we left for the last moment of development was user interface, and we ended up having it very simple. While being informational enough for the game, making it graphically more attractive would improve the gameplay a lot (compared to having just default text giving you all the information you need). Next time around, I'd like to dedicate at least few hours on these two topics, even sacrificing some of the visual effects or details in world generation, to increase atmosphere of the game with audio and UI. Conclusion As said, this was 10th Ludum Dare for me, and I have enjoyed working on it very much. I'm quite satisfied with the game we have ended up with. For the next time, assuming I would have a free weekend, I'd like to participate again. Also, if any of you (who read this article) have participated in Ludum Dare, and would like me to play your game - please leave a comment here, and I will definitely play your game during the following weeks. Goodies So, for curious ones (I'm intentionally leaving just Itch.io link to the game, as I never know when I will remove it from the server - that would make the link inactive): Source code is available at: GitHub Game is available at: Itch.io Ludum Dare page is at: LDJAM
  5. Vilem Otte

    Roads rendering on large terrain

    There is nothing wrong with Humus's demo and large terrains, it can be used for that. The main problem that such technique has is, that it isn't really suitable for roads, unless you prepare terrain geometry for road before. Rendering of roads needs few parameters - like road width, maximum allowed slope, maximum allowed angle change per segments, etc. Now, it will get a bit image heavy - first, let me post here a photo of recent road construction near my town: Fig. 01 - real world road construction. (Credits for the photo: Lechovice town and Ministry of transportation of Czech Republic) This is a 1st class road in my country, they have some specific parameters (max allowed slope change, width of lane, min radius of turn, minimal distance to trees, etc. - these can all be looked up in standards and requirements for roads, and they are going to be different in each country). What is important factor here is that the terrain has been adjusted to support the road and its standards. This is actually very important feature to make roads look realistic in games, that many games actually forget. (Interesting unrelated fact, not related to the terrain - the asphalt actually is very dark when you pour it and it gets rigid, over the time its color change - almost none games on the market actually take this into account!). In case of aerial view (I know the photo is from drone, so the altitude is very low, compared to airplanes) this is still visible - from experience when I was piloting a helicopter. Depending on your altitude of course - but within few thousand feet, this will be visible and noticeable. Especially when you are in hilly or mountainous area. Let's jump ahead, so - how does a game do it? For this I decided to screenshot Cities: Skylines (so all credits for the game go to Colossal Order, published by Paradox Interactive, screenshots were captured by me). Fig. 02 - Terrain before building the road (standard game view). Fig. 03 - Terrain after building the road (standard game view). Notice how the terrain has changed. The geometry had to be adjusted to accommodate for at least the slope and direction of the road. Also notice that crossroads are technically flat (as usual for construction - while not always the case, in majority of cases in real world the terrain under crossroads will be flattened - if and when possible within budget of course). Let me also show you elevation view (as the game allows it), which will give you the idea how the terrain geometry has been adjusted: Fig. 04 - Terrain before building the road (elevation view). Fig. 05 - Terrain after building the road (elevation view). On the elevation view you can clearly see the maximum allowed slope for the road, and that the shape of the mountain was actually changed quite a lot. Now - how to calculate it? Generally you will need a definition of terrain (the simplest way is grid of height values - i.e. a height map representation), and a definition of road (which is technically just a set of segments - whether you allow only 2 points defined straight segments, or have a complex spline system is up to implementation). The basic case has one segment of points Ra and Rb, width of Rw and max slope of a (Important note here - the definition of road has to be checked before computing - as it has to be "build-able", i.e. you can get from point Ra to point Rb with max. slope of a). And set of heights H representing terrain. Brute force case goes over all heights of the terrain, and each height of the terrain impacted by the road has to be re-computed (basically a linear function for each height in oriented square between Ra and Rb with width of Rw). Like this: Fig. 06 - Height map selection of impacted vertices Where: Red point is Ra Blue point is Rb Green square of length of RXw = |Ra - Rb| (let's call this direction RX and RY be perpendicular direction for this) and width of 2 Rw Each point within the Green square needs to have height recomputed as following: H'.y = Ra.y + dot(H.xz - Ra, Rx) / RXw * (Rb.y - Ra.y) Which will basically make a linear slope on the terrain for the road along the direction from Ra to Rb. Of course the algorithm can be improved a lot (as said - using splines instead of just segments, improving the terrain next to road to have certain max slope (as seen on real photo), etc.) The important thing is - once this adjustment of the terrain geometry is done, you can place road geometry on top of it without any issues. I had an article for this in work, although didn't have time to finish or work on it too much as I'm quite busy these days. So, in case of any further questions - feel free to ask.
  6. Vilem Otte

    DOOM: Skeletal Animations & Dynamic BVHs

    @lawnjelly If it goes well, I'm considering either: Changing repository status to public on my server (maybe fork it to Github) Publishing that ray tracing library as a library (with few examples) Writing some articles about ray tracing dynamic scenes The library I'm using (a custom one) is OpenCL based renderer - it doesn't have hard syntax (it might need a review or two - and maybe updating the interface after the project - as I'm adding classes/methods whenever I need them for this project). I'm currently busy making and animating a daemon from hell. 100% programmer's art.
  7. A small update I was tackling today - and that is skeletal animation. Now, doing anything animated with ray tracers is quite a pain... Static scenes - you simply build acceleration structure once ... and then you can move camera around, and everything tends to be nice and easy Scenes with dynamic objects - multi-level BVHs can rescue you here, you build bottom level BVHs and then rebuild top level BVH, also this enables instancing as side product Scenes with dynamic geometry - you may go a bit nuts in here, as you NEED to rebuild BVH for given geometry So, current strategy for the DOOM project is somehow working, basically the scene allows you to add render nodes, which can be defined as either STATIC or DYNAMIC. The STATIC ones have BVH built once in the beginning, and never rebuilt again. On the other hand the DYNAMIC ones have BVH rebuilt every single frame. All of these bottom level BVHs are then leafs of top level BVH that is being rebuilt every single frame. My apologize for giving this in form of small post, and not a full featured article (once the Challenge is over, I already have quite a pile of topics I'd absolutely like to write about, most of those are related to ray tracing). In the meantime, I can at least feed you with simple sample...
  8. Vilem Otte

    DOOM: Multi Level BVHs

    @LandonJerre I'm glad to hear it is running on RTX 2080! Thanks for testing. I've figured out one application crash (BVH had a memory leak - and as it is rebuilt every frame, you can run out of memory quite fast), this might have been the cause of it. I was able to reproduce vertical black line on my GPU either - will look at it eventually (added into TODO list). Seems like RTX 2080 gives the highest performance so far (for later releases, I may want to add a way to send results to database (with hardware information and resolution)), that way we could compare how fast which GPU is - and I could make a minimal and recommended configuration (plus what resolution you should run) once the DOOM game is more game-like.
  9. Vilem Otte

    DOOM: Multi Level BVHs

    @dmatter Wow, I really didn't expect it running on Radeon HD 7790 (it is after all a bit older GPU). Now I can't test it on any NVidia directly (as I only have a friend who has it), which isn't really good - so I'll probably get one 2070 before end of September, so I can debug & run on it.
  10. Vilem Otte

    DOOM: Multi Level BVHs

    @JoeJ Thanks. Sounds good! @Rutin I'll try to add a bit more statistics and logging, to see why (it could be that I'm using too big surface for texture atlas, or too large workgroup).
  11. Vilem Otte

    DOOM: Multi Level BVHs

    One of the major challenges in real time ray tracing are dynamic scenes. It is not hard to pre-compute BVHs and then just render the scene, but working with dynamic objects and geometry is challenging. To handle such scenario I've implemented multi-level BVHs where top-level BVH is rebuilt every single frame, additionally for fully dynamic geometry I've added HLBVH (which is extremely fast to build). The first test I have (which you can try) is a Sponza atrium, which creates each single object in it as node within multi-level BVH. Each node has high quality SAH BVH pre-computed on start, and then a top-level BVH is built every single frame. Additionally it immediately supports instancing, which is a great feature! Geometry also have material (with diffuse map) assigned. To run demo, OpenCL 1.2 compatible hardware is required (I've tested this on AMD Rx 380, AMD Rx 590, NVidia 1070 and Intel HD Graphics 620 - where it runs quite slow, but still - runs) Raytracer Test No. 1 I don't like to promise future features, but if everything goes well - I'd like to have some skeletal animated model in soon along with finally some models that I'm working on for the actual game!
  12. Vilem Otte

    Where announcements go to die

    @AceBlkwell I personally don't read through announcements that much, I'd say create a blog here and post to it - if you write something that will catch my eye, I'm going to look at it (and I guess that goes for everyone here on the forums) - and if available - try it. There is also an Indie Showcase section, or you can create a Project. I believe those are visible (I remember checking out few of them). From the old times of GameDev.net I remember that there was an Image of the Day. "Every day" (sometimes it took a week), there was a post on home page that highlighted a project and there were many people talking under it - often trying accompanying demo or at least talking about the video or such. I personally miss it (and yes, I know there is still Image of the Day sadly it is just image - there is no archive of those (or I wasn't able to find them), and there is no direct easy way to post those (I believe it was right next to Image of the Day on the old website). On the other hand, the Blogs and Projects are making up for it, yet I have a feeling that there is far less discussions and comments on the site in recent years.
  13. Vilem Otte

    Folder Organization Methods

    Hello, it depends on scale of the project - for one of the big ones I'm currently having - full featured game engine with editor (it actually builds multiple libraries and multiple executables - engine editor, runtime, etc.): - Bin64 (binary output) - Data (resources - models, textures, scripts, shaders, etc. - I generally live monitor (in editor) only folders under this) - Dependencies (3rd party dependencies) - Lib (dynamically loaded libraries (mainly plugins, etc.)) - Source (under this only source files, divided into projects, and for more complex ones even further) - Projects (Visual studio project files/Makefiles) for small projects I sometimes tend to dump them in single directory (refactoring once they get bigger).
  14. It depends - F.e. Paradox Interactive does so (they have Paradox store and also games available on Steam). I believe Steam still doesn't require exclusivity in standard agreements, in which sense - yes you can have both. Payment system requires some maintenance, also Steam (and others) can do quite simple reports you are required for taxes. Especially in EU (from experience), running our own store can be administratively quite heavy. The cost will depend on scale, how much administrative work you will need, etc. It can go anywhere from few hundred EUR per month to tens of thousands EUR per month. Sadly, I can't disclose full cost and details of such system publicly. Bear in mind that implementing good payment system, along with systems allowing you to do useful reports and properly connecting with software you do taxes in - is a time consuming task. I can although disclose approximate price for implementing similar system (using a third party payment processor) - which does reports, is connected with other software, etc. ... It will end up in tens of thousands EUR. Implementation can be done within few months (even though you can have the source running faster - bureaucracy will kick in, it is also possible that you will be required to pass some audits). It is possible you will need a full time employee in the end to administrate the system after (which gives you approximate guess on maintenance cost). It will heavily differ whether you want a simple 'Buy Now' button, without any connection to other software or reporting ... or whether you want complex solution that is capable of doing large part of accounting stuff, is directly connected to license generation, etc. Note. You can argue that you can do most of the work yourself, I'm not denying that - while you won't spend tens of thousands on somebody doing it for you, you will still have to do the work such employee would do (which is of course major part of that amount).
  15. This was working back in the old days. Currently, you most likely won't get featured on Steam or anywhere else unless you pay for ads/promotion elsewhere (so that people will know about our new product). Of course the quality of the project you release, along with its presentation play a huge role. Having own show and own website may or may not have sense - this depends on how you approach marketing of your game. From experience, it will most likely end up being more costly than using a distribution system like Steam.
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!