• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

909 Good

About j_uk_dev

  • Rank

Personal Information

  • Interests
  1. Let's gamify education!

    I worked for the edu-gaming company for about 3 years. It's not a new idea but damn difficult to get it done right. We went from one unsuccessful idea into another one. We couldn't get a proper business model in place to actually start making any money ( it seems so easy when you think of regular games but it's different in edu-gaming ). Lastly, despite we had the right technology in place, teachers and psychologists on board, working with schools, having people with lots of experience in the field of children entertainment we failed. The company shut down. I'm not saying not to do it, but believe me - it's harder than it looks. Here are few of my own opinions: - In the educational software most of forget that there are also parents... - You don't make a game for a child only, but also for a parent - you have to make both happy ( after all it's a parent paying you by making a purchase ). - Parents are very unlikely to pay, the premium apps business model won't work here. Even in-app purchases happen less often than in regular games - Games must have plenty of content protections ( you don't want child accidentally perform in-app purchase etc. ) - PC edu-gaming doesn't exist and seems like nobody really wants it ( we tried, too side by side with the mobiles ) - Hiding education inside the game is very difficult, you have to extract the "fun factor" out of it and still not lose the educational value - Hard to find investors and funding, edu-gaming is an ugly sibling of regular gaming. - Getting schools on board isn't so hard, however ( at least in the UK ) special condition must be met to work with children ( like CRB checked etc. ) - Making games both entertaining and educational is damn hard. - We had PLENTY of money invested ( talking about millions of pounds ) and it didn't guarantee any success either. Maybe just for fun, or if I was a teacher - as a supporting software, I could think of making such games. However, if one wants to make it into a day job and make a living of it - stay the hell away from it for your own good
  2. On Location Interview

    @Kylotan's advice is a good one. I also, when it comes to interviewing somebody, I prefer to hear a simple "I don't know" if one really doesn't know. Believe me, you can tell if someone tries to hide any lacks in knowledge. Of course, it doesn't have to be just "I don't know" but it may transform into "I don't know, never encountered this problem, however if I did I could..." and so on. Showing that you have the ability to admit you don't know something is very important from the point of view of the employer. No one wants to hire a person who's afraid to admit that and will be working on something for ages, going nowhere, and at the end of the day will bring problems to the project and whole team. I worked with such people, they are usually quiet and really put effort into solving a problem, but sometimes the solving problem may require additional help and admitting that is a good thing. Nobody knows everything and nobody expects you to know everything ( although it's good if you know :D ).
  3. The pipeline stage doesn't have anything to do with resource initial state. Pipeline barrier allows to change for example image layout but it's up to you to decide how and when you are going to use the resource. For example, a newly created image with bound memory must make sure that all the writes and reads already happened before you try to change the layout. The safest place ( but usually least optimal )  is going to be a top of the pipeline for both - source and destination stages, as you may want to use this resource for example as sampled image. But again it depends on when and how you use your resource in the pipeline. To understand barriers you may think of it as "all the access operation must complete before source stage(s) to perform access operations after destination stage(s)". If we continue the example of image layout transition, usually the source stage for the new image is top of the pipeline ( regardless if the old layout is preinitialized or undefined ). The source access usually stays empty for uninitialized layout ( the data is undefined, no read and writes will occur at this point ). If your image is preinitialized you are going probably to write the data, so host write access must be complete before layout transition will happen. Those layouts are useless anywhere in the pipeline, so we use top of the pipeline as the source stage. Now depends on what you want to do next. If for example, you want to turn your image into the color attachment, then your destination stage mask will include color attachment output bit and access mask will include color attachment read and write bits. However, if you want to sample image in the shader, you need to perform transition earlier ( for example your new layout is VK_IMAGE_LAYOUT_SHADER_READ_ONLY_OPTIMAL ). The stage mask should include all stages that may try to sample your image ( so mostly all shading stages ). Destination access flag would include shader read bit as that's the only operation that may happen after layout change.   I'm not sure if it's clear enough. I used image resource as the example although mind that barriers are a lot more complex in terms of what and how they synchronise. The example above is a simplification of the concept to help you understand what stages and access masks are.
  4. What do you listen to while indie devving?

    Totally nothing. I can't focus if there's any noise and I count music as one. Usually, I wear earphones/headphones to cancel the outside noise, not to generate new one :)
  5. What should I expect from game industry?

    Most have been already said above by others so I will just add my 5cents to it. The games industry is very fragile hence it's mostly always product oriented - it doesn't matter that much what technology you use as long as it takes you to the end of it and you succeed releasing finished games. The smaller studio, the more it comes to be a matter of life and death. It means that especially as a junior developer, you will be thrown to work on very different areas, not necessary ones which you like ( well, this happens also to lot more senior developers too but they've been long enough in the industry to know what to expect ).   First of all the OpenGL is nowhere near being deprecated or obsolete. Vulkan is still very immature and takes very experienced programmers to tackle it ( have you ever written a graphics driver? With Vulkan you're almost there ). You can learn it from the specification ( I did, however since my company is a part of Khronos Group I admit I had a little bit better start ). Vulkan API isn't a problem at all. It looks horrible in the beginning etc. but it actually does what it says it does. The problem is something else - all other advanced knowledge you should have when you use Vulkan ( or DX12 ). That's why for this role rather senior and principal developers would be assigned. My company isn't a game development one but we do support and work with studios which try to implement Vulkan in their games. We see advanced programmers making crucial mistakes ( mostly in regard to objects lifetime and synchronisation ).   Now let's talk about the game engines. For a couple of years, the market has been flooded with various, better and worse, game engines. Game studios don't have to invest much money in own technology mostly because they can take one that exists, if needed adjust it to their need and have a game released in the finite amount of time ( so they may avoid redundancies by the end of the year - yay! success! ). Of course, some of the studios still invest in proprietary tech but then, you being a junior without big portfolio won't be anywhere near that. Portfolio for you, as engine developer, means games built with your own engine. The engine itself backed up with the long list of cool features is not so impressive Today. However what may impress somebody are games powered by it. Games which were not a chore to develop ( you took care about the development pipeline, tools etc. ), pretty much bugless, stable and running with good performance. Metaphorically speaking, if you're on the side with Carmack, then find somebody to be your Romero ;)   One more interesting thing is that even as a junior you may actually be allowed to work on the low-level Vulkan stuff if only you show something that proves you have an experience. Believe me, showing the running game or even better - games written from scratch, which maintains nice framerate, stable memory usage, doesn't crash ( I repeat: DOESN'T CRASH ) and doesn't throw thousands of warnings with validation layers enabled - I would probably consider you as a fit for such work.   Edit: Just wanted to add one thing, because my last paragraph looks a little bit like contradicting what @Kylotan said:   "This is also why most companies won't be paying to train people in Vulkan skills; most of their employees will never need them.)"   He is absolutely right and what I meant is the circumstances when the company actually looking for somebody to be Vulkan or DX12 guru. This is the very rare case and as I said - we do a lot of such work for external companies, so it shows what @Kylotan means by that - rather that a company invest time and money into porting stuff from one tech to another they're more likely to hire thirdparty developer to do the job for them. But there's always chance to find company that wants to make things independently :)
  6. Drop installing packages. There's no such need and it's pretty much obsolete. Vulkan doesn't install anymore system-wide. Go to LunarG website and download the SDK: https://lunarg.com/vulkan-sdk/ It contains all you need and even more and everything is up-to-date. I usually unpack Vulkan SDK into /opt keeping all updated versions and symlinking the latest one as the "current". Since it's not a system-wide package anymore you will need to tell where the Vulkan headers and libraries are however, the lazy way is just creating symlinks in /usr/include and /usr/lib into the proper directories from the SDK. Also, it's necessary to tell where the layers are by defining VK_LAYER_PATH env variable ( for example in .bashrc ) that points into PATH_TO_SDK/x86_64/etc/explicit_layer.d directory/. I have updated LD_LIBRARY_PATH in order to pick up the right runtime library ( points at PATH_TO_SDK/x86_64/lib ). Basically, everything you need is in the x86_64 directory ( which before used to be installed system-wide ). It may sound complicated but you do it only once and then, with each update of the SDK you just link to the new directory. It keeps environment clean, easy to update and doesn't mess up drivers ( which was the case if one used one of those nvidia-prime drivers in the past ). All instructions are in the SDK/config directory. If you follow them, you won't have a problem with setting Vulkan environment up. Then you may run build scripts to build examples, samples and tools.
  7. I'm not an artist but I use Blender a lot. Most of the people remember Blender as awful version 2.4. Blender changed since then. A lot. Yes, the UI is not the most user-friendly but it's not so horrible as it used to be. In fact, after a while, I find some of its elements really useful ( for example, windows subdivision ). I use Blender at work as well. An artist I work with uses Maya but the whole content anyway goes through scripts which run in Blender and its Blender a tool that spits out the data used by the application. I do a little bit of simple modelling ( mostly mockup models to have something to work with and work out what I will actually need from the artist ) and Blender works for me. I've been using Maya and Max and, as a programmer, I found lots of difficulties - could be it's because the habits I got working with Blender. In Blender, every single UI element is scripted and there's huge API which gives artist/programmer limitless prospects. Being free doesn't mean it's not in use in the industry. Two companies I worked for put Blender somewhere in their content creation pipeline and it did the job like a charm. That would be it of my praising Blender ( yeah, you could call me a fanboy here and if I don't shut up I will be talking about it endlessly :) ).   There's more free software that I've seen in a line of work. For example Meshmixer ( http://www.meshmixer.com/ ) that you could use for sculpting. One of the artists I know uses "3D Coat" as well for creating PBR materials ( the amateur version costs $99, not a budget breaker ).
  8. Nintendo NX/Switch

    I'm a bit skeptical about the Switch. However, I can tell I'm one of those gamers who likes to play longer, AAA-like titles on the go. I commute almost 2 hours and this is a perfect time to play on the go. I spent lots of time with the flagship Vita games ( Killzone, Uncharted, Gravity Rush ) and at some point, such games ran out. So my interest in Vita did too. I don't mind to play a boss fight on the train if only I can quickly suspend the game and resume later. Being able to play the same game at home ( without worrying about battery life and on the big screen ) is also something tempting. But there's one thing which doesn't convince me enough - Nintendo. I played old Nintendo games, I acknowledge their importance in the video games history but I don't find playing yet another Mario or Zelda fun anymore. They had titles that came up to be good but it was just a handful of games that could hook me in and make me spend hours playing.   Well, there's this other "competitor" - mobiles. I usually have a gamepad with a clip ( MOGAPro ) that not only can turn my mobile phone into a small handheld gaming console but can also extend the battery life a little bit. I played a couple of games like that and it was a really great experience. Shame there are only few that support it. So this is a field on which mobiles won't be any competitor to Switch. Despite the mobiles can support a controller, the games rarely use that. The mobile market took a turn at some point towards 'free-to-play- experience and titles like old Gameloft games ( "Modern Combat", "Gangstar" etc. ) don't seem to appear anymore. Yeah, I know these were "cheap ripoffs" but also it was closest to what could be considered "a console experience on a mobile device". That's why I found Vita so appealing.   So here, in the middle of this, the Nintendo is. It's very important question who is a target audience for Switch. I think people like me could be the audience if only Nintendo lets more variety into their titles. Although, it's still too early to make any judgments on it.
  9. Preventing overengeneering

    I can only speak based on my own experience. I tend to overengineer the code. Especially that I find working on the tech side more fun than working on the actual gameplay. This always gets me to the point where I can't complete single game by myself because I get stuck on improving the engine. There's always something that can be done better and better. At my daily job, this problem doesn't exist due to the management and because I'm working in R&D hence, I have a lot of freedom ( and sometimes overengineering is the right thing to do ;) ). However, when I work on my own projects I tend to focus on details and instead of pushing the project forward, I get stuck on tweaking not really important things just to make it looking perfect in my eyes. Also, my motivation graph would look like a sine function :) The motivation sometimes is there, sometimes it's not. So how do I deal with it?   1. I'm scheduling my own tasks and deadlines - it helps to see where I am with the project.   2. Motivation comes mostly from the progress. No progress - no motivation to continue.   3. I do try to make any progress. If any of the tasks seems to be taking longer than I have planned then it's a good idea to take it on hold ( or sometimes even to abandon it ) and try something else. There's always a number of areas to work on. Switching to something else lets me breathe and very often short break gives me a new point of view on the old task ( the way: "how could I not see that?" ).   4. Documenting own work. Planning etc. It may sound like not necessary if you're the only person who's involved but the truth is that writing things down will let you seeing the scope of your work better. You will see bottlenecks of your solutions, you will find which corners you may cut etc. Having no plan is plays role of a demotivating factor. Always try to write down what you've done and planning to do. I simply use GitHub wiki for that ( with the Asciio tool to make ASCII diagrams etc. ).   5. Use GitHub tools which analyze your progress. See for example, at what times you're the most productive. See when your productiveness drops. It is a really useful tool to learn about own working patterns. For instance, I found out that I can't be productive during the weekend. Sounds crazy, right? After all, it's a free time and I should be using it for my own work. But GitHub says something else. I learnt not to plan any work for the weekend. If weekends don't work for me I don't use them. Instead, it's better to have decent relax and rest which will power me up for other times when I'm actually more productive.   6. Don't force yourself to do any work. If you can't concentrate just let it go. You may be experiencing a "programmer's block" ;) Then focus on something else, do not code. This is what I use my weekends for ( see 5. ).   I know that what works for me not necessarily will work for you, but don't stress yourself too much. Own projects always move forward with a pace of a snail :)
  10. Ide For Linux

    QtCreator. Very lightweight, supports all custom types projects, easy to use, easy to extend if needed. I use it sometimes on Windows too :) I don't use Eclipse mostly because it's so heavy and slow ( but I work with people who chose to use it, so maybe it's just me ).
  11. Mapping C++ Entrypoint Into Dll

    If understanding "entry point" of shared library as a function that is invoked when the library is loaded, then on Android it's JNI_OnLoad(). However, I'm not sure what you want to achieve by that. Do you want to hijack the main executable's entry point with your library or something like that :)? If you want to make a user creating single 'main()' function and regardless a platform. Then you're overcomplicating things. You must deliver platform dependent framework that will invoke this function. On Android, you would create simple framework project that loads your library and invokes your "custom" entry point. The REAL entry point on Android starts with JVM, not with the code that runs on it. But as I say, I don't really understand what you want to achieve.
  12. @BitMaster, true. I left vector because simply everything in that topic started from vector in this thread. I admit that this solution may be too complex for the beginner. So maybe simply a linked list of free/allocated items within a pool should be easier? Using vector the way the original code does ( and few other iterations ) simply defeats the purpose of having the pool.
  13. First of all, do not modify vector. The vector may be reallocated and this will break your pool. Create buckets of fixed size. Let's say 10 elements bucket ( you may use vector and resize it right after creating ). If you need to increase the pool size, add one more bucket, DO NOT RESIZE YOUR POOL. Return only pointers using either at() or subscript operator. Threat vector as if it was an array. When you get an object from the pool, increase the pool index within a bucket. If you reach bucket capacity, create the new bucket and reset the index.   Now, freeing is more tricky. You don't need to put element back into the pool ( after all you never removed it from the bucket ). Instead, create one pointer that points to FIRST FREE ELEMENT. When you get a new object from the pool, first check if your pointer points at the object. If so, just return it and make sure that it points at next free object ( single linked list ).    You can use actual objects and encode the pointer in their space like: // In class: Bucket* firstFreeObject; // In free function: void BulletPool::Free( Bullet* ptr ) { *ptr = *(Bullet**)firstFreeObject; firstFreeObject = ptr; }  This way you create a list of freed objects that can be reused as first. When you run out of them, then follow a regular pattern, which is getting next element from the bucket. Note that freeing objects this way destroys content, so after allocating them again use placement new on the obtained memory address to reinitialise them.
  14.   I believe the guy who made Flappy Bird though same way ;)   Portfolio in this industry is incredibly important. Portfolio means experience. Many employers want to see you being able to run the development from start to its finish. It shows your dedication, self-motivation and other things. It is hard to sell a game, but we are not talking about marketing stuff here. Look that many job ads contain a bullet point stating that you have to have at least 1 published title in your career ( and believe me, self-published titles count too ). Also working on your own games rather than corporate AAA titles it's lots of fun due to being able to make all the decisions and shape the game the way you want. Working for a company ( especially big one ) doesn't look like it looked 20-30 years ago, and you have to be ready that sometimes you may need to work on "boring" stuff. Working on your own games will show you how you deal with that "boring" stuff too. Sometimes you would get annoyed because you may need to work on something that in your opinion doesn't make much sense, but still your boss made a decision etc. Hence, my strongest bet is to try self-publishing ;) This will automatically put you in the industry, no matter whether you want it or not :D
  15. This topic appears from time to time. Today there's a way of getting into games industry that we didn't have many years ago. It's called self-publishing. I didn't see anything in your post indicating that you have ever made a full game by yourself. Today you can make a game and publish it, make it a part of your professional portfolio. And guess what - you can call yourself a part of games industry! If I were you I would aim to follow this path. I understand you may not have much of free time, so focus on simple game that you can spend some time during weekend, maybe evening, maybe even on your way to work if you commute. Self-publishing is incredible powerful tool nowadays and working on own portfolio not only will make you a better candidate for a job but also will teach you lots of things about this industry and working on games at all.
  • Advertisement