• Advertisement
• Image of the Day

• 0

• MIT is offering a bundle of great selections from their game studies catalog. Pick up titles like How Games Move Us: Emotion by Design; Super Power, Spoony Bards, and Silverware: The Super Nintendo Entertainment System; Developer's Dilemma: The Secret World of Videogame Creators; and more!

Get the bundle here.

GameDev.net is a

• Popular Tags

• Advertisement
• Latest GameDev.net Updates

• Advertisement
• Advertisement

1. Past hour
2. Do indie game designers play their own game?

Only through the eyes of a player. After the game is played through to check for technical issues, the game designer may play their game to imagine what the player feels and sees. They may treat this as a learning experience and use this as a continuous improvement cycle.
3. Scripting Designing interesting Quests

A few ideas could be: Travel to location X Interact with X Do not get noticed by X, but defeat Y and travel to Z Quests are in an interesting part of Game Design. Whilst there is a variety of different styles of game play, they typically fall into several categories. Arguably, the best quest design incorporate the mechanics of the game and have several layers of depth. For an example, let's look at Pokemon. The main quest is to catch defeat the Pokemon league, which is the primary goal. The secondary goal which is completed on the way is to collect every Pokemon and train them. To do this the player must take advantage of their knowledge of the game's mechanics and exploit them in such a way to progress their journey. This quest subsequently journeys the player through a story. There is no real answer to the best quest design, and to generate them whilst keeping them interesting would be difficult. I can however advise that to keep them refreshing is to incorporate the game's mechanics and keep side quests randomly generated, but the main story predetermined.
4. Algorithm Increasing difficulty algorithm

I have never heard of this before, so I just looked up some information on it. Is this something that would be feasible for a mobile game though? It sounds super complex.
5. Era Of Brutality

The idea for the game was made back in 2013, as Ooyama and several of his friends where getting annoyed with many of the current MMORPG's and the flaws they found in them. Among the things that made them grow tired of current games was that it was impossible to truly take sovereignty of areas AND defend them while not online, and that almost all games are (in one way or another) instanced,, that there where no truly openworld games out there. The approach to solving these issues lead across several different gameengines, before it was decided to use the BigWorld engine. With it's flexibility and power, it was the best choice for the task at hand,, afterall, to create the world in the game there was a need for a gameengine that could handle up to 5000x2000 square kilometres interlinked space. Another point in solving the issues was the defense side; this was done by allowing the players to hire npc's, not only once they had sovereignty of an area, but already before that. To make sure that such an act whould not automatically become an "i win" button, measures where taken to balance the npc-hirelings out so that teamwork and cooperation whould still be the driving factor. Finally, a thing that had annoyed Ooyama in many fantasy rpg's was that in the mountsystems there was a general idea that if you fought a dragon, it could breathe fire, but the moment that you caught one as a mount it inherently lost that ability. In EoB that is NOT the case, though you will have to get in range of hostile archers/catapults and the like before YOU can hit,, making you a strong fighter, but also a target,, and let us be honest; IF your dragon panics with you on the back, that MIGHT get ouchy! As the world is intended to become quite massive, there will be a strong playerpart in populating it as the starting empires will be centered in the middle so to speak. This, along with the fact that there is no linear questlines, will make the game more driven by the players own explorations and decisions than of a mere grinderapproach. Those two things, along with the unique characteridentification system built into the game, should make for a both beautyfull, scary, and intense expirience to any player. With the aproximately 10-million square kilometres of landmass planned for the gameworld, which will be named Shandoz, along with sailable seas (yes, you get to play captain aswell if you so desire) there will be a lot of different places to seek out and explore. This is where it is important to know what the meaning of MMORPG is, as you WILL need to be in groups to travel the outskirts of the world safely. On the edge of the world, there be not only monster,, but also titanic demigods. Some may be benevolent, but others will and can smash you with one blow of their hands if you're alone and intrude. So by all means, explore the world,, but,, remember,, it is not always for the fainthearted. All in all, we're hoping for you to enjoy the game once we launch, and till then maybe follow us on facebook too. On the facebookpage you can also find miscellaneous links to related things, such as Gamerpod where we plan streams regarding the game, aswell as our patreon-page (yes we're a small underfunded company, so go and look and see what benefits you get from becoming a patron). Best regards, and in the hope to see you in Shandoz, the EoB-team.
6. BGP DevLog #164 (Still with the Menus? Come ON!!)

This here is a WIP of what's essentially the pony/monster encyclopedia. Not functional, but the pieces are in place. Very red. Maybe too red. Feels like I should add some purple frames here and there. Another week in and the game's revamped menu systems still aren't done! Feels like I'm running in place sometimes, but week after week new things are being added and I'm feeling more and more capable as a developer. I just want the alpha build done already! Take a look at what I managed to do this past week. (The Yotes Games Blog)
7. Algorithm Increasing difficulty algorithm

Maybe logic would be better here than math. For example Left4Dead used "The Director" and logic based AI. Even today Left4Dead is still one of the most played multiplayer games and a lot of it is because of the AI.
8. C++ FreeGLUT - Making Planets Orbit

Alright, I think I've got an idea of what I'm doing XD, more then I did though I've still not got it working. Should I be applying this custom orbit rotation with a matrix like this? glRotatef(orbitAngle, orbitRotation.X, orbitRotation.Y, orbitRotation.Z); Or applying a velocity to the position like the other poster mentioned. I did try it but it didn't work well.
9. Today
10. Algorithm Increasing difficulty algorithm

I'm working on an endless wave-based arkanoid/space invaders style hybrid. Bricks spawn above the screen and move down line by line. You must destroy all bricks before they hit the bottom of the screen. There will be multiple types of bricks and random power-up spawns. Currently I am just using a simple Log function that takes in the current wave as a parameter. This works to increase the number of bricks spawned each wave, but I want to find a way to make this much more complicated. Here is a list of everything that should be effected by the increase in difficulty: 1. Number of bricks 2. Types of bricks (1 hit bricks, 2 hit bricks, 3 hit bricks, etc.) 3. Speed that the bricks move down the screen 4. How often power-ups spawn The biggest problem here is that I can't just increase all of these with each new wave. If I did that, it would quickly become far to difficult. What I would like is an algorithm that gives some amount of variance in the increase between all 4 of these. Say one wave we put 60% of the increase to number of bricks, 20% increase to power-up spawns, 10% to types of bricks and 10% to speed of bricks. But on the next wave those percentages are all moved around and we now have say 105% to work with so the overall difficulty has increased as well. The different types of bricks need to also change to the point where if someone has made it to a certain wave, such as wave 50 for example, there are no longer any 1 hit bricks. We now would have just 2-4 hit bricks, and if they are crazy good and make it all the way to round 100, Now it's just 3-5 hit bricks, etc. If anybody has any good ideas or suggestions on this, I'd appreciate anything you've got! Thanks!
11. DX11 implement and understand voxel cone tracing

many thanks for you answers JoeJ and turanszkij, @JoeJ Your "perfect mirror ball" helped me a lot to understand, also your info about weighting rays vs. changing the distribution of rays The part that comes nearly exactly to my understanding problem is the front/backside wall problem. Test scene. Just imagine a room which is diveded by a wall with a closed door. Lets assume the voxel len is 10 units and the wall is even 20 units thick. One room has a strong point light, the other is completely dark. The voxels of the middle wall on one side will be bright because of the direct light but the voxels on the other side of the wall will be completely dark. But at the 1, 2, 3, mip level of the voxels of the middle wall will be a middle bright area that will give indirect illumination in the dark room. is this right ?
12. Costs of "simple" Game Production

I think one aspect you need to take in consideration is where you are going to develop it and how you are going to develop it. If you are located in a 3rd world country or 2nd world country you could have a significantly lower budget and production costs (you could probably get professional coders/graphics artists for as low as 20k /year) You could cheap out by using freelancers to do one aspect like graphics but this would work only if you have strong skills on other levels , like do most of the coding yourself in your spare time and not count that investment. But as you want a mobile/PC game i imagine targeting iOS / Android/ Mac OS/Windows and Linux , i doubt you could pull it off without a sizeable investment, either that or do it solo in 5+ years.
13. Survey - community feedback on music in video games

Just finished my survey!
14. Do indie game designers play their own game?

I am a perfectionist I see irregularities and start moving the build around
15. Do indie game designers play their own game?

As an indie with some creative freedom, why would you make a game that you didn't want to play?
16. Algorithm What's the best way to clean as much fog of war possible in the next step?

Isn't it sufficient to walk to the nearest fog tile?
17. Do indie game designers play their own game?

I do PR and promote, it looks like playing, but it's work. I have to create alts to play.
18. Implicitly assign handle by overloading opImplConv operator

I did notice that bug before and I actually reported it: But I noticed by removing opImplCast operator overload, my problem solved so I thought it's not a bug. However, I installed VS 2015, with the latest revision, registered opImplConv in dictionaryValue, 1. In test_feature project (msvc test as) this happens: 2. test_castop.cpp Line 184 fails as well. 3. My old bug still exists, even with VS 2015, latest revision and THE EXACT SAME SOURCE CODE you posted in here in the exact same test_feature msvc project. --------------------- I took these screenshots, if you want me to take a video, downloading the actual latest WIP source code version, compiling it with VS 2015, add your code in msvc test as project and compile & test it, just do tell, if you want to remotely connect to my computer and see for yourself (or do it yourself), just do tell!
19. C++ FreeGLUT - Making Planets Orbit

Just in case it's not clear... The gravitation constant G is 6.673e-11. The sun's mass M is 1.989e30. For the planet Mercury: The aphelion distance is 69817079000. The perihelion distance is 46001200000. The semi major axis A is the (perihelion distance + the aphelion distance) / 2 is 57909100000. The eccentricity e is 0.20563069. The orbit speed at aphelion is v = sqrt((G*M/A) * (1 - e)/(1 + e)) = 38860.5.
20. Vulkan DirectX - Vulkan clip space

Thank you both, for the time being I will go with flipping in the vertex shaders. Though I have no system in place, I will have to manually add that with a SPIRV macro. This way I don't have to mess with culling direction.
21. DX11 implement and understand voxel cone tracing

Unfortunately, I don't have a machine with win 7 any more and can't keep up with syncing with the old DirectX SDK. Developing just for the new one is so much easier. Though I'm nearly finished the Vulkan implementation which should eliminate the Win 10 requirement. You are right, mip maps here are like different 3D textures, but in DirectX they are stored in the same resource as the main 3d texture wich enables eficcient access from the shaders because with one sample operation you can possibly load from multiple mips (sub-3d textures) at once. If your sampler has "linear" filtering mode. This is also called quadrilinear filtering as you mentioned. We don't need view dependency for the diffuse part of the illumination. This calculation only takes into consideration the surface normal, and shoots rays inside a hemisphere directed along that normal. This step involves first having your surface position which you start the rays from. Also you have the surface normal in world space, which will give the ray direction. Now you can start stepping along the ray. On each step, you convert the position on the ray which is in world space, to your voxel texture space, then sample. Repeat until you accumulated more that one alpha or reached the lowest mip level or reached some predefined maximum distance (to avoid infinite loop). You are actually right, sampling only gives the surrounding voxel colors, but those should already contain the scene with direct illumination, so it's exactly what you want. You will need view direction information for specular reflections, which you can also retrieve from the voxels. The algorithm is the same, but you are shooting a single ray in the reflection direction. Note that my code uses the function "ConeTrace" for both diffuse and specular GI. I hope that it was any help.
22. circle drawing method comparison

Until you draw a million circles / second, I wouldn't worry much about performance, whatever you pick it's always fast enough for a few circles. As to why it's faster, CPUs have changed, and compilers have improved. It's extremely hard to understand why code is faster or slower. For example, I would not be surprised if the loop of the second solution is unrolled a few times, and several points are computed in parallel in SSE. Secondly, sending a bunch of vectors to the GPU versus sending loads of pixels to the GPU does make a huge difference.
23. DX11 implement and understand voxel cone tracing

I'm not sure what you can not understand, but maybe it is how to approximate the above with cone tracing. First, notice that instead weighting by cosine, you should change the distribution of rays instead: More rays at normal directions, less at tangent directions. (Importance sampling) Then you can simply average and get better results with less rays... just to mention. So, e.g. instead tracing 1000 hemisphere rays we want to trace 4 cones instead. We can only expect to get an approximate and similar result, but we try to make it as good as possible. We start by dividing 1000 rays into 4 bundles of 250 rays, and we calculate a bounding* cone for each of them. Then we trace the cones, which is similar to sphere tracing, but for cone tracing we constantly grow sphere size so it fits our cone as it marches along the ray. We will also increase the step size by the same factor. Sphere size also sets the mip level for trilinear filtering so volume data resolution fits sphere size. Each time we sample from the volume data, we accumulate color and alpha, and if alpha > 1 we decide to stop tracing, because we assume all 250 rays have hit something at that point. The accumulated color divided by alpha then refers to the averaged color from all 250 rays. It's just an approximization, that becomes better and better the more cones you use. (3 is minimum to approximate hemisphere, 4,5,7... gives better results) Direction (hit point normal) does not matter. You seem to be confused by that, but it would not matter for ray tracing as well. The normal of the hit point would only matter if you would not just have point at the hit, but something like a patch or surfel, something that has an area you wouldd want to integrate - here visible area from the receiver depends on the surface normal of the emitting patch (radiosity method). Ray tracing does not care - it approximates this by the distribution of the ray directions (or their weighting as you said.) I like this example to understand how diffuse GI is calculated: Place a perfect mirror ball at the receiving point you want to calculate. Make a photo of the mirror ball from the direction along the receivers surface normal. (avoid perspective in the photo, so orthogonal if possible) Sum up all the pixel colors from the photo on the mirror ball and divide by number of pixels. (no weighting necessary) This is the final incoming light, we're done. Notice that this simple example explains the most important things about GI and how easy it is to derive related math (like ray or cone distribution or weighting, cone directions and angles, etc.) from there. Also the normal direction of emitters does not matter - only the image that appears on the mirror ball. *) bounding would not be very good as it would duplicate too much space between the cones, but just to visualize... EDIT: There are limitations in volume tracing where direction indeed matters. E.g. at some distance the fornt and back side of a wall will be merged and you accidently sample them both. No way to fix this - it's the main problem of voxel mips. (Anisotropic voxels with 6 colors, one for each side can't really fix it either.)
24. OpenGL Search for WebGL to OpenTK Port like 80bserver8 made...

Ah... sorry you are right because I am deaf My english is not okay. I need learn more. I would like to say sorry for my bad English. Please do not be angry to me! You know I am coder for C# but I am really shy because I am initial coder from deafness bedcause I have experience of HTML5, Javascript ( bit less ) and C# is like baby-light language. I will excuse you that my bad English. I need learn more details of Languages.
25. DX11 implement and understand voxel cone tracing

hi turanszkij, many many thanks for you answer. Some months ago i had an intensive study on your surce code und your home page. Although i work with c# i could success with my basic c++ knowledge to compile and run your engine. Bad badly i did no save the code and after trying to download and compile again i saw, that i cannot use the engine because i only have Win7 64bit your engine requires Win10 DirectX12. Do you still have a Win7 version ? In ray marching contex i understand. But opacity here is easy to detect and the progress is only e.g. one pixel. So the problem i have is not touched. My Problem "understanding occlusion query" is solved by tracing each pixel step by step. Now here is my problem. When doing mip mapping on a 3d texture several coarser 3d texture mip maps are created ? But when sampling the 3d texture at a given point an given mip level it will allways return the same value right ? When sampling with "quadrilinear interpolation" we get smooth values but allways the same value independent from view direction of the cone. see the following Part of your code The coneDirection is only for calculating the next postion in texture space where we sample from. But if sampling the mip map is view direction independent how can it reproduce the correct color ? Sampling a point within a 3d mipmap is something totally different from getting a projection (of the view ) of the colors from the Voxels it consists of ( when looking at it from a certain viepoint) ? To my understanding the sampling yust gives me the interplation of the accumulated surrounding voxel colors of the sample point. I still need help in understanding, please be patient. best regards evelyn Part Code from turanszkij game engine float diameter = max(g_xWorld_VoxelRadianceDataSize, 2 * coneAperture * dist); float mip =log2(diameter * g_xWorld_VoxelRadianceDataSize_Inverse); // Because we do the ray-marching in world space, we need to remap into 3d texture space before sampling: // todo: optimization could be doing ray-marching in texture space float3 tc = startPos + coneDirection * dist; tc = (tc - g_xWorld_VoxelRadianceDataCenter) * g_xWorld_VoxelRadianceDataSize_Inverse; tc *= g_xWorld_VoxelRadianceDataRes_Inverse; tc = tc * float3(0.5f, -0.5f, 0.5f) + 0.5f; // break if the ray exits the voxel grid, or we sample from the last mip: if (any(tc - saturate(tc)) || mip >= (float)g_xWorld_VoxelRadianceDataMIPs) break; float4 sam = voxels.SampleLevel(sampler_linear_clamp, tc, mip);
26. Implicitly assign handle by overloading opImplConv operator

I use Visual Studio 2015, I believe it only supports up to C++11. But I doubt it is the newer C++ version that causes the problem for you. After all, AngelScript works even without C++11 on older compilers too. I've tried several options; 64bit, 32bit, with or without AS_NO_THREADS, debug and release mode, and so far I haven't been able to reproduce this error. I did identify another problem while doing this related to the opImplCast with the variable type. The compiler would try to use this even for non reference types, and cause an assert failure (in debug mode) or crash (in release mode). I've fixed this in revision 2491. You will need this fix too, but unfortunately it doesn't fix the problem you've reported.
27. DX12 HLSL noise or random for fake water?

You could always just google for a good water normal map like this. If you wanted random noise to make the texture more dynamic like real water you could do something easy and hacky like just interpolate the normals over time between the original from the texture and the original's inverse.

Content and Members You Follow

You must be logged in to view this content.

Don't have a GameDev.net account? Sign Up

Recent Blogs

1. This here is a WIP of what's essentially the pony/monster encyclopedia. Not functional, but the pieces are in place. Very red. Maybe too red. Feels like I should add some purple frames here and there.      Another week in and the game's revamped menu systems still aren't done! Feels like I'm running in place sometimes, but week after week new things are being added and I'm feeling more and more capable as a developer. I just want the alpha build done already!

Take a look at what I managed to do this past week. (The Yotes Games Blog)
0 comments
2. Greetings!  I'm happy to announce that Pixelpunk XL has been released today on Steam! I thank all the people who support me and give feedback on my posts. Steam page: http://store.steampowered.com/app/803850/Pixelpunk_XL/
0 comments
3. The game is going to be a mix of three games DOOM Slender man and resident evil Story Line So Far: Your Maxwell (( the name is wip)) a 25 year old gang member who gets shot in a shoot out with the cops you wake up in a hospitle and it is empty in journy to the basement level and get it in the back of the head then you wake up in a weird looking room. that will be what happens in the first cut video thing lol if you want more just ask i am open to what ever ty all who comment
0 comments
4. It’s been a while since the last update, so lots to get through. We’re still progressing, probably slower than we had hoped, but never the less, its still going forwards. Kat’s been busy working on tons of graphics, icons, lighting, and we now have all the 4 worlds pretty much done with backgrounds and world layouts. She is currently working on placing items in the 2 remaining worlds, working on more puzzle ideas and polishing of the graphics. I’ve been working on performance a fair bit, making sure we stay in a good position. Just finished up with reducing memory usage, as I found that unloading scenes wasn’t quite releasing all resources and therefore if you went between 2 worlds it was using 1GB or so extra memory. This was ok on my rig, as I had 4GB VRAM, but Kat’s PC started to chug a bit when she went between worlds because she only had 2GB of VRAM. This was because I had some textures and materials being cached in variables, and the scene unload wasn’t catching that they were now unused, so I had to set them all to dummy textures/nulls and then call Resource.UnloadUnusedAssets() to clear them. I made heavy use of the memory profiler, which also lead me to some more memory improvements to further reduce memory usage. On my PC now we have a steady 200+ FPS (GeForce GTX 970, Core i7 920, 14GB Ram, 2560×1600), and 100+ on Kat’s (GeForce GTX 580 , Core i5 750, 12GB Ram, 2560×1600) We’ve shown the game off to a few people locally now, some friends came around for a games evening. Even shown it to some of our nieces and nephews and they all loved it, and we got some good feedback and ideas to make things better. Upgraded several times to new versions of Unity in the past few months. Not been great sailing with that, seemed to hit a new bug with whichever one I went with. Been able to navigate around some, but currently waiting for them to fix Resource.LoadAsyc() so that it works with uncompressed Textures/PNGs correctly. Currently on 2017.3.f3, and will probably wait for 2018.1 before I try again. Spent quite a large amount of time making the loading of worlds (ie scenes) be async, so that we could play an animation/particle effect during load. This was quite a challenge, as I was doing lots on load so that it didn’t effect the actual game, thinking the load would be the best place. Unfortunately, that caused stutters etc with the load animations, once we put them in. After lots of profiling and understanding how the load works, we’ve got it to basically never stutter now. Mainly removing all Awakes() as they were just setting cache vars for GameObjects etc, and actually linking them into public inspector vars. Also turning most of our Init() methods into IEnumerators so that we could yield every so often, and using Resource.LoadAsyc() for loading. Will have to revisit it nearer the end, but its working well now. Spent some time putting in lots of particle effects to brighten up the game. We used the Ultimate VFX  package from the Unity Store as a basis, and then played around with them. Got most of it done, but I have to go through and find all the graphics and sprite sheets we’ve used and pack them into our own sprite sheets and resize them to fit our game, so that performance is good. The same with the sprites used in the UI. Dotted throughout the worlds, there are puzzles that need to be completed to gain items, and we had done the world 1 puzzles, which were just basic push/pull of blocks and positioning them. These puzzles are intended to get harder as you progress through the 4 worlds, so I worked on the 2nd set of puzzles making 2 new elements for them to make them more interesting. ‘Mag’ blocks are placed around the area where you have to do the puzzles, and these either attract or repel the blocks you need to move. You need to work out which ones can help you or hinder you to complete the puzzles. Implemented a stats screen in-game, so that you can keep track of all the items, puzzles and other elements in the game. Then you can track your progress and see how much you’ve done… and what is left to do. Lots of bug fixing. We’ve played though the first level many times now trying to keep the number of bugs low so that we hopefully don’t have a big job at the end to fix lots of things. At the moment we are ‘bug free’ and everything we’ve found so far has been fixed, so that’s a nice place to be in 🙂 Major things left now are:
3rd and 4th world puzzles
In-Game Tutorial
Customization items for the alien
Boss levels
Achievements
Sounds So, we will be powering on with things and will keep you updated either here or on our social media pages at FaceBook or Twitter. So if you’re not already following us there, head on over and give us a ‘like’ or ‘follow’. Till next time… watch out for ‘Somethings’ that may eat your aliens… Rob & Kat
1 comments
5. And so we meet once again to discuss what's new in the development of Lyfe. But as we promised on our Twitter this is something big. I don't have to tell you what we're discussing, you probably already read the title of this entry. I have to thank Jake Best who took the time draw the concept we developed for how the player will create the basic shapes for his cells. So let me explain what is going on here. You start off with just one central orb. This is your base node and your cell starts to 'grow' from it. There are arrows on four sides of this base node. If you pull on them new nodes will be created in that direction. This will create a kind of 'spine' for your cell. As shown in fig. 3 and 4 not only is the default setting when creating new nodes to the left or the right to make your cell symmetrical but you can also move your nodes/ bend the spines and the shape will be translated to the other side as well. You can also scale single nodes (fig. 5/6). This expands the cytoplasm around this node. The next thing is something we decided we needed but are not sure how to implement: a weight/thickness slider. This includes the overall amount of cytoplasm with a slight bias for filling up space between spines. Next step: placing organelles. Most organelles like Mitochondria or a Golgi Apparatus can only be placed on the inside of your cells but all organelles that are used for interaction with the outside world like Flagella or Pseudopodia have to be placed on the membrane. Organelles will have options to deform them, like elongating. Rotating them around the anchor point on the cell is also an option. Asymmetry is an option that not only affects the placement of the organelles but also the sculpting of your cell. In fig. 11 the right half of the cell is deleted resulting in this more potato shaped creation. Below are some possible results you might achieve with this toolset. For the two on the right, the dashed line represents their shape if the weight-slider was put to maximum and the one on the far left is a more experimental idea with actually two split nodes. If this will be possible in future is not sure yet, but we will see. That's it for this entry. Feel free to comment all your questions and suggestions. Keep on evolving! cellcreator.pdf
0 comments
6. Hey All,  Another week another great update!  So we have several new features that were implemented.  First, we now have a start screen with a menu.  Right now I'm just using the starting room background for the artwork on the start screen.  This is only a place holder and will be changed.   Right now the options to select are; New Game, Continue Game, Arena, Store, Credits, and Quit.  3 of these options currently work.  New game starts the game and continue game works as designed, more info below on how that system works.  Arena mode, the store, and credits are placeholders.  The quit option currently quits the game but that will be removed as you do not need that for a mobile title.  Also along the same lines we now have a game over screen.  This screen also has the same artwork as the start screen (will be changed later) and displays game over text to hit the space bar to continue.  For this screen I will also be creating an animation of the main character spinning and falling on her knees.   So now lets talk about the continue game feature.  This does exactly what it states, allows you to continue an ongoing game.  There is a save system in place for the game that is making all this work.  The save system is an Auto Save feature.  The player is not allowed to manually save their progress.  Remember this is going to be a "rogue-lite" game.  So it will autosave every time the player enters a new room.  I found it best to implement it this way as it's a mobile game and if you get interrupted, your last progress of clearing that room will not be lost and you can pick up where you left off.  If you get a "game over" the auto save is completely erased.   You cannot continue a game after a game over.   The next thing I did was some more tweaking on the shadow engine.  I did a lot more work on this to try and get it more realistic.  Now the left wall, door, open door, room props, and enemies have shadows.  I even added depth to the shadows so if an object goes under a shadow it gets darker from the shadow being casted upon it.  Still needs some more tweaking but it looks a lot better.  I will be creating a lighting feature in the game.  Some rooms are going to be dark.  The only light in the room will be from candles or a flashlight.  This will just add more elements to the gameplay and look really cool at the same time.   Created two new objects in the game.  These are room hazards.  The first one was mentioned in the previous blog post.   Mucus was created.  He does not harm the player.  He sits on the ground and pulsates a little.  If the player runs through the mucus your speed is drastically slowed down while your in the mucus and up to 1 second after you get out of the mucus.  This proves to be a huge obstacle when you are running away from an enemy or need to run from an enemy.  The second hazard which I am extremely proud of is the hole.  There will now be random holes in the floor of the rooms.  If you get to close you will fall into the hole.  I have also created the animation for falling into the hole.  Once you fall into the hole you disappear, lose 1 heart of health, then re appear at the location where you started that room.   You will also be slightly invincible while you re spawn just in case you are re spawned next to an enemy (invincible while blinking).  I am very pleased with the results of this feature and it's going to be expanded upon.  Which leads to the next feature that will be implemented......Secret Rooms! Secret rooms is the next thing I will be focusing on.  In order to access these secret rooms you have to fall through a hole in the floor and be granted by the RNG gods that the hole does not damage you and brings you to the secret room.  If you find a secret room through one of the holes you will have the option to purchase upgrades.  These can range from +1 heart, +1 stamina, health potion, etc.  These can be purchased via coins that are collected while playing.  What will be offered will be complete random and will only be temporary for that particular play through.  This way every play through is different and you always end up with different stats and upgrades.  More on this to come.  Two sound effects have been added to the game.  They are for hitting an enemy and using the firecracker explosives.   Which reminds me I have not talked about that power-up yet.  The firecrackers can be used against all enemies, even damage the main player, and are very powerful.  They require 3 stamina for use and do 4 damage.  Also a long with this I have cleaned up the pause and inventory screen.  I made the dim of the game darker while in the pause screen so you can see the inventory more clear.  Also I will be adding a quit to menu option here if you choose to quit back to the main menu, which can be important because doing so will NOT delete that auto save file. I believe that was everything, if I missed anything I will add it to next weeks blog.   Here is a gameplay video showcasing most of the features discussed in this weeks blog.  Please post comments and questions we will respond! Thanks much!
1 comments
7. I am happy to announce that we release first demo of Rail Route! We have polished our first prototype of train routing and added a simple tutorial. To make it more a game than a prototype we have included short level where you can try your dispatcher skills. You can download it at our blog: https://railroute.bitrich.info/2018/04/17/demo-r0-1-released/ Or you if don't want download .exe from the internet we prepared Unity WebGL build: https://bitrich-info.github.io/railroute/r01/ Levels in Future Our vision is that the final game will contain a handful of such levels, some longer, some short (puzzle game / unlock scenario). You will be able to compare your performance with the others (global Top 10 list). We are thinking of tools that enable you to create & share own levels, so you will be able to model your home city railways if you want. These levels will be only one game mode, but the primary game play will be something completely else. Something like career mode where you take care of rail network that you will need to built, upgrade, manage and so on. We will write about it soon! Feedback We would like to hear any feedback from the prototype. So feel free to reach us anywhere :-). What's the best score you can reach?
1 comments
8. Ive finally put together this demo.  Only one enemy, but I hope you will like it and leave some response. My main goal is inventory system. Grid functions arent my favourite thing, but I will still use them, but first I wanted to show you at least some of my work. Errors will probably appear, Im sorry for that, but the base is good in my opinion.  Im NOT an artist, my sprites are bad and I know it, so ignore them now. Here is my work so far --fightSystem for rpg3.zip--
3 comments
9. I've shifted the project from C++ to JavaScript during this prototyping phase.  I've done this for a few reasons: This makes the project incredibly portable, allowing me to work on it on different devices easily. Prototyping in JavaScript is easy. Threejs is cool and easy to use. I'm a C++ coder at heart and my ultimate goal is for this to be a C++ project. Pragmatically it hasn't been working for me using C++ for my home projects for the last few years. I find myself needing to upgrade projects and libraries, worry about build processes, ensure Visual Studio is installed on the device etc. Now I can now edit generation scripts almost anywhere, anytime, event on my smart phone. Those little moments of downtime can be much more productive I'll take the project to C++ once it has matured - though it will continue to support JavaScript generation scripts so hopefully with a little work I won't have to throw anything away.
2 comments
10. Welcome to the new GameDev.net Groups feature. Groups are like they sound - mini-sites, microsites, areas of GameDev.net dedicated to a particular topic. I'm going to roll out Groups slowly - consider this a beta - but I wanted to start with our GameDev Challenges because they seem like a perfect fit for this. If you're here and interested in participating in the GameDev Challenges, then join the group! So, here you will find all the GameDev Challenges. They'll be announced in the News section of this Group, but even better than the GameDev Challenges forum, members can freely post any topic about the Challenges they'd like - current, old, and new ideas alike. I'm also opening up other features of the group and will soon even be adding Projects integration. For historical purposes, I'm going to copy the topics from the GameDev Challenges forum to this GameDev Challenges group, and I'll add News topics for past challenges. We also have a Calendar and Gallery for the group. I hope you like the new format and this new GameDev.net feature. Let me know what you think!
2 comments

1. Submissions are now open for IndieCade 2018.  The first submission deadline is May 28 with submission fees starting at $75 USD. Learn more about submission requirements, fees, and events at https://www.indiecade.com/. IndieCade supports independent game development and organizes a series of international events showcasing the future of independent games. It encourages, publicizes, and cultivates innovation and artistry in interactive media, helping to create a public perception of games as rich, diverse, artistic, and culturally significant. IndieCade's events and related production and publication programs are designed to bring visibility to and facilitate the production of new works within the emerging independent game movement. 0 comments 2. Spectral rendering enters the computer graphics world. After a period with not that many feature improvements, Dual Heights Software have now finally released a new major version of their water texture generator software called Caustics Generator. The new version includes full spectrum color rendering allowing the simulation of spectral refraction which produces prismatic coloring effects and thus bringing caustics simulation to a new level. The spectral functionality is available in the Pro version on both Windows, Mac and Linux. Read more about the Caustics Generator at https://www.dualheights.se/caustics/ 0 comments 3. In the latest CG Garage podcast, Chris Nochols interviews Sebastien Deguy, CEO of Allegorithmic. In the podcast Sebastien discusses the history of Allegorithmic in a refreshing, non-corporate way. Recorded at the Vertex Conference in London, Sebastien tells Chris how a single mistake led to the founding of this fast-growing and innovative company, which is branching out into visual effects and architecture, after rising to a state where 95% of AAA games use a Substance product for texturing. He also talks about the little tricks Allegorithmic uses behind the scenes, the future of the software, and even how we can understand the universe through mathematics. Check out the podcast at https://www.chaosgroup.com/blog/sebastien-deguy-allegorithmic. 0 comments 4. The International Game Developers Association (IGDA) and Plan C Ventures, LLC today announced the 2018 IGDA Game Leadership Summit will be held in Austin, TX on Thursday – Friday, Sept. 13 - 14. Featuring a diverse slate of executives who exemplify the best leadership practices in the industry, the global summit is the first-ever event focused on helping individual leaders at all levels within the industry maximize business performance and professional success as they navigate the rapidly changing interactive entertainment field. The announcement follows the release of IGDA’s highly publicized 2017 Developer Satisfaction Survey, citing diversity and job stability concerns across the industry. Informed by the survey’s results, the IGDA is developing a robust agenda designed to help leaders strengthen their individual leadership abilities and keep talent engaged in long-term careers. Summit Tracks 1. Management Excellence: Managers, executives, business owners and entrepreneurs will learn competencies essential to running smart, effective game businesses, at scales from small team to thousand-plus person studio. From planning ahead for success to navigating risk and positioning for growth, topics include Building Sustainable Teams, What to Consider Before Starting a Studio and Building Strong Partnerships 2. Professional Leadership: Game professionals at all stages of their careers and across all disciplines who seek to better manage their careers and acquire leadership skills will learn to improve their decision making, planning and problem solving. Topics include What I’ve Learned in 25 Years in Game Development, Negotiating Fundamentals and Adapting to Change in an Industry Driven by Change. “Strong, broad-based business management and professional leadership skills are the cornerstones of a healthy career and an essential foundation of high performance for companies in the interactive entertainment industry,” said Jen MacLean, executive director, IGDA. “With the re-launch of IGDA’s mission to support and empower game developers around the world in achieving fulfilling and sustainable careers, we’re excited to partner with Plan C Ventures to bring this one-of-a-kind program to our members and the worldwide game-development community.” (See GameDev.net's interview with Jen MacLean here.) Registration is now open. Early bird registration before July 13 is$125 for IGDA members and $200 for non-members. The IGDA Game Leadership Summit is guided by an expert advisory board. While most of the speakers and program content will be hand-selected by the board, a call for speakers is also now open. This comprehensive effort will insure a diverse field of innovation and experience for attendees. As a rolling call, speaker submissions are reviewed upon receipt, with the first deadline on April 30, 2018. 0 comments 5. Hello developers, my name is Sergio Ordonez from SOSFactory.com, I just wanted to let you know about the release of my Photoshop based Avatar creator. A premium, high resolution, high quality, full body cartoon Avatar Creator for male and female characters, fully customizable from the skin color or hair dresses to the clothing. Aimed for game and app developers, suitable for personal use too. With SOSFactory avatar system you can create unlimited characters, those are just a small selection: Already available 20 out 40 sets at my website: http://www.sosfactory.com/premium-stock-avatar-creator/ Feedback and critique is more than welcome! Thanks. Sergio 0 comments 6. Following a successful beta, Allegorithmic last week announced the official release of Substance Plugin for 3ds Max, now available for free. First announced in November, Substance Plugin for 3ds Max brings the professional material creation toolset to artists and designers, with over 20 new updates and a direct link to Substance Source. Designed for visualization experts, the new plugin launches with support for V-Ray and Corona, the AEC industry’s leading renderers, as well as the latest versions of Octane and Arnold. The new support comes with automated workflows, which send material data to the user’s renderer of choice at the push of a button. Substance menus have also been added to the design and default layouts of 3ds Max, ensuring a smooth, uninterrupted workflow for artists and designers. “This plugin was very much a collaborative effort between Allegorithmic and our community of beta testers,” said Sébastien Deguy, founder and CEO of Allegorithmic. “Thanks to their efforts, 3ds Maxusers can finally participate in the full benefits of the Substance ecosystem, creating and editing photorealistic materials in the most intuitive way possible.” Featuring a simplified design and tools that just work, Substance Plugin for 3ds Max streamlines the entire process without sacrificing quality. All materials can also now be sent to a user’s 3ds Maxlibrary, including anything drawn from Substance Source. With over 1,000 materials to choose from, artists and designers can use this tool to do their work faster, dropping readymade 8K materials into their projects outright, or editing for a little extra flavor. In the coming year, additional functionality will continue to be added at no cost. Current plans include network/cloud rendering, support for additional third-party renderers and animated Substance support. Additional features will be announced soon. A complete list of changes can be found here. Pricing/Availability Substance Plugin for 3ds Max 2018 is available now for Windows users for free. Substance Source files can be accessed through a Substance subscription; Substance Indie cost$19.90/month, while Pro plans cost $99.90/month. 0 comments 7. Last week VIVE announced the VIVE SRWorks SDK, allowing developers to access the stereo front facing cameras on the VIVE Pro. Developers will now be able to perform 3D perception and depth sensing with the stereo RGB sensors. From the announcement: The SDK includes plugins for Unity and Unreal. VIVE also included a few videos worth checking out: Learn more at http://developer.vive.com/resources. 0 comments 8. Epic Games has announced the Unreal Engine #ue4jam for Spring 2018. Once a quarter, Epic hosts the #ue4jam to give developers a chance to create new projects, sharpen their skills, and compete for prizes. Prizes include an Intel Optane SSD 900P, a Houdini Indie license from SideFX, and more. Learn more from the Unreal Engine blog here. 0 comments 9. Game Quality Forum has posted an article on cross-functional collaboration in game development. From their description: Get access to the full article by clicking here. 0 comments 10. Learning game development in Unreal Engine could be a daunting task for someone who don’t know where to start, and a cumbersome process if you don’t organize your progression correctly. One thing commonly known by experienced developers and by people unfamiliar with coding: mastering a development language is a long and difficult task. From blueprints to C++ in Unreal Engine If you want to learn fast, you need a good learning strategy. Unreal Engine contains a very powerful tool which you can use to learn C++ faster: its blueprint system. Blueprints are extremely easy to learn (and you may already have a good knowledge of them). Thus you can conveniently use them as a guide for writing code in C++. This is the reason why I am writing a tutorial series on how to make the transition from Unreal Engine blueprints to C++. Learn and practice C++ Following this tutorial, you’ll acquire new concepts of C++ programming in every chapter. Then following chapters will give you reasons to reuse and practice those same concepts. There’s no better way to wire you brain. Link to the tutorial: [Tutorial] Learn C++ in Unreal Engine 4 by making a powerful camera Please do send me as much feedback as you want. I’ll be considering every constructive remarks and taking them into consideration. Your feedback will help me to improve and update the existing chapters and to make the next one better. 1 comments Latest Project Updates • Role Playing • Role Playing • Casual • Puzzle • Other • Role Playing • Strategy • Strategy • Simulation • Engine • Action • Action • Adventure • Strategy • Action • Action • Role Playing • Adventure • Action • Action • Puzzle • Adventure • Action • Simulation Recent Articles and Tutorials 1. I got into a conversation awhile ago with some fellow game artists and the prospect of signing bonuses got brought up. Out of the group, I was the only one who had negotiated any sort of sign on bonus or payment above and beyond base compensation. My goal with this article and possibly others is to inform and motivate other artists to work on this aspect of their “portfolio” and start treating their career as a business. What is a Sign-On Bonus? Quite simply, a sign-on bonus is a sum of money offered to a prospective candidate in order to get them to join. It is quite common in other industries but rarely seen in the games unless it is at the executive level. Unfortunately, conversations centered around artist employment usually stops at base compensation, quite literally leaving money on the table. Why Ask for a Sign-On Bonus? There are many reasons to ask for a sign-on bonus. In my experience, it has been to compensate for some delta between how much I need vs. how much the company is offering. For example, a company has offered a candidate a position paying$50k/year. However, research indicates that the candidate requires $60k/year in order to keep in line with their personal financial requirements and long-term goals. Instead of turning down the offer wholesale, they may ask for a$10k sign on bonus with actionable terms to partially bridge the gap. Whatever the reason may be, the ask needs to be reasonable. Would you like a $100k sign-on bonus? Of course! Should you ask for it? Probably not. A sign-on bonus is a tool to reduce risk, not a tool to help you buy a shiny new sports car. Aspects to Consider Before one goes and asks for a huge sum of money, there are some aspects of sign-on bonus negotiations the candidate needs to keep in mind. - The more experience you have, the more leverage you have to negotiate - You must have confidence in your role as an employee. - You must have done your research. This includes knowing your personal financial goals and how the prospective offer changes, influences or diminishes those goals. To the first point, the more experience one has, the better. If the candidate is a junior employee (roughly defined as less than 3 years of industry experience) or looking for their first job in the industry, it is highly unlikely that a company will entertain a conversation about sign-on bonuses. Getting into the industry is highly competitive and there is likely very little motivation for a company to pay a sign-on bonus for one candidate when there a dozens (or hundreds in some cases) of other candidates that will jump at the first offer. Additionally, the candidate must have confidence in succeeding at the desired role in the company. They have to know that they can handle the day to day responsibilities as well as any extra demands that may come up during production. The company needs to be convinced of their ability to be a team player and, as a result, is willing to put a little extra money down to hire them. In other words, the candidate needs to reduce the company’s risk in hiring them enough that an extra payment or two is negligible. And finally, they must know where they sit financially and where they want to be in the short-, mid-, and long-term. Having this information at hand is essential to the negotiation process. The Role Risk Plays in Employment The interviewing process is a tricky one for all parties involved and it revolves around the idea of risk. Is this candidate low-risk or high-risk? The risk level depends on a number of factors: portfolio quality, experience, soft skills, etc. Were you late for the interview? Your risk to the company just went up. Did you bring additional portfolio materials that were not online? Your risk just went down and you became more hireable. If a candidate has an offer in hand, then the company sees enough potential to get a return on their investment with as little risk as possible. At this point, the company is confident in their ability as an employee (ie. low risk) and they are willing to give them money in return for that ability. Asking for the Sign-On Bonus So what now? The candidate has gone through the interview process, the company has offered them a position and base compensation. Unfortunately, the offer falls below expectations. Here is where the knowledge and research of the position and personal financial goals comes in. The candidate has to know what their thresholds and limits are. If they ask for$60k/year and the company is offering $50k, how do you ask for the bonus? Once again, it comes down to risk. Here is the point to remember: risk is not one-sided. The candidate takes on risk by changing companies as well. The candidate has to leverage the sign-on bonus as a way to reduce risk for both parties. Here is the important part: A sign-on bonus reduces the company’s risk because they are not commiting to an increased salary and bonus payouts can be staggered and have terms attached to them. The sign-on bonus reduces the candidate’s risk because it bridges the gap between the offered compensation and their personal financial requirements. If the sign-on bonus is reasonable and the company has the finances (explained further down below), it is a win-win for both parties and hopefully the beginning a profitable business relationship. A Bit about Finances First off, I am not a business accountant nor have I managed finances for a business. I am sure that it is much more complicated than my example below and there are a lot of considerations to take into account. In my experience, however, I do know that base compensation (ie. salary) will generally fall into a different line item category on the financial books than a bonus payout. When companies determine how many open spots they have, it is usually done by department with inter-departmental salary caps. For a simplified example, an environment department’s total salary cap is$500k/year. They have 9 artists being paid $50k/year, leaving$50k/year remaining for the 10th member of the team. Remember the example I gave earlier asking for $60k/year? The company cannot offer that salary because it breaks the departmental cap. However, since bonuses typically do not affect departmental caps, the company can pull from a different pool of money without increasing their risk by committing to a higher salary. Sweetening the Deal Coming right out of the gate and asking for an upfront payment might be too aggressive of a play (ie. high risk for the company). One way around this is to attach terms to the bonus. What does this mean? Take the situation above. A candidate has an offer for$50k/year but would like a bit more. If through the course of discussing compensation they get the sense that $10k is too high, they can offer to break up the payments based on terms. For example, a counterpoint to the initial base compensation offer could look like this: -$50k/year salary - $5k bonus payout #1 after 30 days of successful employment -$5k bonus payout #2 after 365 days (or any length of time) of successful employment In this example, the candidate is guaranteed $55k/year salary for 2 years. If they factor in a standard 3% cost of living raise, the first 3 years of employment looks like this: - Year 0-1 =$55,000 ($50,000 +$5,000 payout #1) - Year 1-2 = $56,500 (($50,000 x 1.03%) + $5,000 payout #2) - Year 2-3 =$53,045 ($51,500 x 1.03%) Now it might not be the$60k/year they had in mind but it is a great compromise to keep both parties comfortable. If the Company Says Yes Great news! The company said yes! What now? Personally, I always request at least a full 24 hours to crunch the final numbers. In the past, I’ve requested up to a week for full consideration. Even if you know you will say yes, doing due diligence with your finances one last time is always a good practice. Plug the numbers into a spreadsheet, look at your bills and expenses again, and review the whole offer (base compensation, bonus, time off/sick leave, medical/dental/vision, etc.). Discuss the offer with your significant other as well. You will see the offer in a different light when you wake up, so make sure you are not rushing into a situation you will regret. If the Company Say No If the company says no, then you have a difficult decision to make. Request time to review the offer and crunch the numbers. If it is a lateral move (same position, different company) then you have to ask if the switch is worth it. Only due diligence will offer that insight and you have to give yourself enough time to let those insights arrive. You might find yourself accepting the new position due to other non-financial reasons (which could be a whole separate article!). Conclusion/Final Thoughts  When it comes to negotiating during the interview process, it is very easy to take what you can get and run. You might fear that in asking for more, you will be disqualifying yourself from the position. Keep in mind that the offer has already been extended to you and a company will not rescind their offer simply because you came back with a counterpoint. Negotiations are expected at this stage and by putting forth a creative compromise, your first impression is that of someone who conducts themselves in a professional manner. Also keep in mind that negotiations do not always go well. There are countless factors that influence whether or not someone gets a sign-on bonus. Sometimes it all comes down to being there at the right time at the right place. Just make sure you do your due diligence and be ready when the opportunity presents itself. Hope this helps!
0 comments
2. Recently a long-awaited event has happen - Unity Technologies uploaded the C# source code of the game engine, available for free download on Github. The code of the engine and the editor is available. Of course, we couldn't pass up, especially since lately we've not written so many articles about checking projects on C#. Unity allows to use the provided sources only for information purposes. We'll use them exactly in these ways. Let's try out the latest version PVS-Studio 6.23 on the Unity code. Introduction Previously we've written an article about checking Unity. At that time so much C#-code was not available for the analysis: some components, libraries and examples of usage. However, the author of the article managed to find quite interesting bugs. How did Unity please us this time? I'm saying "please" and hope not to offend the authors of the project. Especially since the amount of the source Unity C#-code, presented on GitHub, is about 400 thousand lines (excluding empty) in 2058 files with the extension "cs". It's a lot, and the analyzer had a quite considerable scope. Now about the results. Before the analysis, I've slightly simplified the work, having enabled the mode of the code display according to the CWE classification for the found bugs. I've also activated the warnings suppression mechanism of the third level of certainty (Low). These settings are available in the drop-down menu of PVS-Studio in Visual Studio development environment, and in the parameters of the analyzer. Getting rid of the warnings with low certainty, I made the analysis of the Unity source code. As a result, I got 181 warnings of the first level of certainty (High) and 506 warnings of the second level of certainty (Medium). I have not studied absolutely all the warnings, because there were quite a lot of them. Developers or enthusiasts can easily conduct an in-depth analysis by testing Unity themselves. To do this, PVS-Studio provides free trial and free modes of using. Companies can also buy our product and get quick and detailed support along with the license. Judging by the fact that I immediately managed to find couple of real bugs practically in every group of warnings with one or two attempts, there are a lot of them in Unity. And yes, they are diverse. Let's review the most interesting errors. Results of the check Something's wrong with the flags PVS-Studio warning: V3001 There are identical sub-expressions 'MethodAttributes.Public' to the left and to the right of the '|' operator. SyncListStructProcessor.cs 240 MethodReference GenerateSerialization() { .... MethodDefinition serializeFunc = new MethodDefinition("SerializeItem", MethodAttributes.Public | MethodAttributes.Virtual | MethodAttributes.Public | // <= MethodAttributes.HideBySig, Weaver.voidType); .... } When combining enumeration flags MethodAttributes, an error was made: the Public value was used twice. Perhaps, the reason for this is the wrong code formatting. A similar bug is also made in code of the method GenerateDeserialization: V3001 There are identical sub-expressions 'MethodAttributes.Public' to the left and to the right of the '|' operator. SyncListStructProcessor.cs 309 Copy-Paste PVS-Studio warning: V3001 There are identical sub-expressions 'format == RenderTextureFormat.ARGBFloat' to the left and to the right of the '||' operator. RenderTextureEditor.cs 87 public static bool IsHDRFormat(RenderTextureFormat format) { Return (format == RenderTextureFormat.ARGBHalf || format == RenderTextureFormat.RGB111110Float || format == RenderTextureFormat.RGFloat || format == RenderTextureFormat.ARGBFloat || format == RenderTextureFormat.ARGBFloat || format == RenderTextureFormat.RFloat || format == RenderTextureFormat.RGHalf || format == RenderTextureFormat.RHalf); } I gave a piece of code, preliminary having formatted it, so the error is easily detected visually: the comparison with RenderTextureFormat.ARGBFloat is performed twice. In the original code, it looks differently: Probably, another value of enumeration RenderTextureFormat has to be used in one of two identical comparisons. Double work PVS-Studio warning: V3008 CWE-563 The 'fail' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 1633, 1632. UNetWeaver.cs 1633 class Weaver { .... public static bool fail; .... static public bool IsValidTypeToGenerate(....) { .... if (....) { .... Weaver.fail = true; fail = true; return false; } return true; } .... } The true value is assigned twice to the value, as Weaver.fail and fail is one and the same static field of the Weaver class. Perhaps, there is no crucial error, but the code definitely needs attention. No options PVS-Studio warning: V3009 CWE-393 It's odd that this method always returns one and the same value of 'false'. ProjectBrowser.cs 1417 // Returns true if we should early out of OnGUI bool HandleCommandEventsForTreeView() { .... if (....) { .... if (....) return false; .... } return false; } The method always returns false. Pay attention to the comment in the beginning. A developer forgot about the result PVS-Studio warning: V3010 CWE-252 The return value of function 'Concat' is required to be utilized. AnimationRecording.cs 455 static public UndoPropertyModification[] Process(....) { .... discardedModifications.Concat(discardedRotationModifications); return discardedModifications.ToArray(); } When concatenating two arrays discardedModifications and discardedRotationModifications the author forgot to save the result. Probably a programmer assumed that the result would be expressed immediately in the array discardedModifications. But it is not so. As a result, the original array discardedModifications is returned from the method. The code needs to be corrected as follows: static public UndoPropertyModification[] Process(....) { .... return discardedModifications.Concat(discardedRotationModifications) .ToArray(); } Wrong variable was checked PVS-Studio warning: V3019 CWE-697 Possibly an incorrect variable is compared to null after type conversion using 'as' keyword. Check variables 'obj', 'newResolution'. GameViewSizesMenuItemProvider.cs 104 private static GameViewSize CastToGameViewSize(object obj) { GameViewSize newResolution = obj as GameViewSize; if (obj == null) { Debug.LogError("Incorrect input"); return null; } return newResolution; } In this method, the developers forgot to consider a situation where the variable objis not equal to null, but it will not be able to cast to the GameViewSize type. Then the variable newResolution will be set to null, and the debug output will not be made. A correct variant of code will be like this: private static GameViewSize CastToGameViewSize(object obj) { GameViewSize newResolution = obj as GameViewSize; if (newResolution == null) { Debug.LogError("Incorrect input"); } return newResolution; } Deficiency PVS-Studio warning: V3020 CWE-670 An unconditional 'return' within a loop. PolygonCollider2DEditor.cs 96 private void HandleDragAndDrop(Rect targetRect) { .... foreach (....) { .... if (....) { .... } return; } .... } The loop will execute only one iteration, after that the method terminates its work. Various scenarios are probable. For example, return must be inside the unit if, or somewhere before return, a directive continue is missing. It may well be that there is no error here, but then one should make the code more understandable. Unreachable code PVS-Studio warning: V3021 CWE-561 There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless CustomScriptAssembly.cs 179 public bool IsCompatibleWith(....) { .... if (buildingForEditor) return IsCompatibleWithEditor(); if (buildingForEditor) buildTarget = BuildTarget.NoTarget; // Editor .... } Two identical checks, following one after another. It is clear that in case of buildingForEditor equality to the true value, the second check is meaningless, because the first method terminates its work. If the value buildingForEditor is false, neither then-brunch nor if operator will be executed. There is an erroneous construction that requires correction. Unconditional condition PVS-Studio warning: V3022 CWE-570 Expression 'index < 0 && index >= parameters.Length' is always false. AnimatorControllerPlayable.bindings.cs 287 public AnimatorControllerParameter GetParameter(int index) { AnimatorControllerParameter[] param = parameters; if (index < 0 && index >= parameters.Length) throw new IndexOutOfRangeException( "Index must be between 0 and " + parameters.Length); return param[index]; } The condition of the index check is incorrect - the result will always be false. However, in case of passing the incorrect index to the GetParameter method, the exception IndexOutOfRangeException will still be thrown when attempting to access an array element in the return block. Although, the error message will be slightly different. One has to use || in a condition instead of the operator && so that the code worked the way a developer expected: public AnimatorControllerParameter GetParameter(int index) { AnimatorControllerParameter[] param = parameters; if (index < 0 || index >= parameters.Length) throw new IndexOutOfRangeException( "Index must be between 0 and " + parameters.Length); return param[index]; } Perhaps, due to the use of the Copy-Paste method, there is another the same error in the Unity code: PVS-Studio warning: V3022 CWE-570 Expression 'index < 0 && index >= parameters.Length' is always false. Animator.bindings.cs 711 And another similar error associated with the incorrect condition of the check of the array index: PVS-Studio warning: V3022 CWE-570 Expression 'handle.valueIndex < 0 && handle.valueIndex >= list.Length' is always false. StyleSheet.cs 81 static T CheckAccess<T>(T[] list, StyleValueType type, StyleValueHandle handle) { T value = default(T); if (handle.valueType != type) { Debug.LogErrorFormat(.... ); } else if (handle.valueIndex < 0 && handle.valueIndex >= list.Length) { Debug.LogError("Accessing invalid property"); } else { value = list[handle.valueIndex]; } return value; } And in this case, a release of the IndexOutOfRangeException exception is possible.As in the previous code fragments, one has to use the operator || instead of && to fix an error. Simply strange code Two warnings are issued for the code fragment below. PVS-Studio warning: V3022 CWE-571 Expression 'bRegisterAllDefinitions || (AudioSettings.GetSpatializerPluginName() == "GVR Audio Spatializer")' is always true. AudioExtensions.cs 463 PVS-Studio warning: V3022 CWE-571 Expression 'bRegisterAllDefinitions || (AudioSettings.GetAmbisonicDecoderPluginName() == "GVR Audio Spatializer")' is always true. AudioExtensions.cs 467 // This is where we register our built-in spatializer extensions. static private void RegisterBuiltinDefinitions() { bool bRegisterAllDefinitions = true; if (!m_BuiltinDefinitionsRegistered) { if (bRegisterAllDefinitions || (AudioSettings.GetSpatializerPluginName() == "GVR Audio Spatializer")) { } if (bRegisterAllDefinitions || (AudioSettings.GetAmbisonicDecoderPluginName() == "GVR Audio Spatializer")) { } m_BuiltinDefinitionsRegistered = true; } } It looks like an incomplete method. It is unclear why it has been left as such and why developers haven't commented the useless code blocks. All, that the method does at the moment: if (!m_BuiltinDefinitionsRegistered) { m_BuiltinDefinitionsRegistered = true; } Useless method PVS-Studio warning: V3022 CWE-570 Expression 'PerceptionRemotingPlugin.GetConnectionState() != HolographicStreamerConnectionState.Disconnected' is always false. HolographicEmulationWindow.cs 171 private void Disconnect() { if (PerceptionRemotingPlugin.GetConnectionState() != HolographicStreamerConnectionState.Disconnected) PerceptionRemotingPlugin.Disconnect(); } To clarify the situation, it is necessary to look at the declaration of the methodPerceptionRemotingPlugin.GetConnectionState(): internal static HolographicStreamerConnectionState GetConnectionState() { return HolographicStreamerConnectionState.Disconnected; } Thus, calling the Disconnect() method leads to nothing. One more error relates to the same method PerceptionRemotingPlugin.GetConnectionState(): PVS-Studio warning: V3022 CWE-570 Expression 'PerceptionRemotingPlugin.GetConnectionState() == HolographicStreamerConnectionState.Connected' is always false. HolographicEmulationWindow.cs 177 private bool IsConnectedToRemoteDevice() { return PerceptionRemotingPlugin.GetConnectionState() == HolographicStreamerConnectionState.Connected; } The result of the method is equivalent to the following: private bool IsConnectedToRemoteDevice() { return false; } As we can see, among the warnings V3022 many interesting ones were found. Probably, if one spends much time, he can increase the list. But let's move on. Not on the format PVS-Studio warning: V3025 CWE-685 Incorrect format. A different number of format items is expected while calling 'Format' function. Arguments not used: index. Physics2D.bindings.cs 2823 public void SetPath(....) { if (index < 0) throw new ArgumentOutOfRangeException( String.Format("Negative path index is invalid.", index)); .... } There is no error in code, but as the saying goes, the code "smells". Probably, an earlier message was more informative, like this: "Negative path index {0} is invalid.". Then it was simplified, but developers forgot to remove the parameter index for the method Format. Of course, this is not the same as a forgotten parameter for the indicated output string specifier, i.e. the construction of the type String.Format("Negative path index {0} is invalid."). In such a case, an exception would be thrown. But in our case we also need neatness when refactoring. The code has to be fixed as follows: public void SetPath(....) { if (index < 0) throw new ArgumentOutOfRangeException( "Negative path index is invalid."); .... } Substring of the substring PVS-Studio warning: V3053 An excessive expression. Examine the substrings 'UnityEngine.' and 'UnityEngine.SetupCoroutine'. StackTrace.cs 43 static bool IsSystemStacktraceType(object name) { string casted = (string)name; return casted.StartsWith("UnityEditor.") || casted.StartsWith("UnityEngine.") || casted.StartsWith("System.") || casted.StartsWith("UnityScript.Lang.") || casted.StartsWith("Boo.Lang.") || casted.StartsWith("UnityEngine.SetupCoroutine"); } Search of the substring "UnityEngine.SetupCoroutine" in the condition is meaningless, because before that the search for "UnityEngine." is performed. Therefore, the last check should be removed or one has to clarify the correctness of substrings. Another similar error: PVS-Studio warning: V3053 An excessive expression. Examine the substrings 'Windows.dll' and 'Windows.'. AssemblyHelper.cs 84 static private bool CouldBelongToDotNetOrWindowsRuntime(string assemblyPath) { return assemblyPath.IndexOf("mscorlib.dll") != -1 || assemblyPath.IndexOf("System.") != -1 || assemblyPath.IndexOf("Windows.dll") != -1 || // <= assemblyPath.IndexOf("Microsoft.") != -1 || assemblyPath.IndexOf("Windows.") != -1 || // <= assemblyPath.IndexOf("WinRTLegacy.dll") != -1 || assemblyPath.IndexOf("platform.dll") != -1; } Size does matter PVS-Studio warning: V3063 CWE-571 A part of conditional expression is always true if it is evaluated: pageSize <= 1000. UNETInterface.cs 584 public override bool IsValid() { .... return base.IsValid() && (pageSize >= 1 || pageSize <= 1000) && totalFilters <= 10; } Condition for a check of a valid page size is erroneous. Instead of the operator ||, one has to use &&. The corrected code: public override bool IsValid() { .... return base.IsValid() && (pageSize >= 1 && pageSize <= 1000) && totalFilters <= 10; } Possible division by zero PVS-Studio warning: V3064 CWE-369 Potential division by zero. Consider inspecting denominator '(float)(width - 1)'. ClothInspector.cs 249 Texture2D GenerateColorTexture(int width) { .... for (int i = 0; i < width; i++) colors[i] = GetGradientColor(i / (float)(width - 1)); .... } The problem may occur when passing the value width = 1 into the method. In the method, it is not checked anyway. The method GenerateColorTexture is called in the code just once with the parameter 100: void OnEnable() { if (s_ColorTexture == null) s_ColorTexture = GenerateColorTexture(100); .... } So, there is no error here so far. But, just in case, in the method GenerateColorTexture the possibility of transferring incorrect width value should be provided. Paradoxical check PVS-Studio warning: V3080 CWE-476 Possible null dereference. Consider inspecting 'm_Parent'. EditorWindow.cs 449 public void ShowPopup() { if (m_Parent == null) { .... Rect r = m_Parent.borderSize.Add(....); .... } } Probably, due to a typo, the execution of such code guarantees the use of the null reference m_Parent. The corrected code: public void ShowPopup() { if (m_Parent != null) { .... Rect r = m_Parent.borderSize.Add(....); .... } } The same error occurs later in the code: PVS-Studio warning: V3080 CWE-476 Possible null dereference. Consider inspecting 'm_Parent'. EditorWindow.cs 470 internal void ShowWithMode(ShowMode mode) { if (m_Parent == null) { .... Rect r = m_Parent.borderSize.Add(....); .... } And here's another interesting bug that can lead to access by a null reference due to incorrect check: PVS-Studio warning: V3080 CWE-476 Possible null dereference. Consider inspecting 'objects'. TypeSelectionList.cs 48 public TypeSelection(string typeName, Object[] objects) { System.Diagnostics.Debug.Assert(objects != null || objects.Length >= 1); .... } It seems to me that Unity developers quite often make errors related to misuse of operators || and && in conditions. In this case, if objects has a null value, then this will lead to a check of second part of the condition (objects != null || objects.Length >= 1), which will entail the unexpected throw of an exception. The error should be corrected as follows: public TypeSelection(string typeName, Object[] objects) { System.Diagnostics.Debug.Assert(objects != null && objects.Length >= 1); .... } Early nullifying PVS-Studio warning: V3080 CWE-476 Possible null dereference. Consider inspecting 'm_RowRects'. TreeViewControlGUI.cs 272 public override void GetFirstAndLastRowVisible(....) { .... if (rowCount != m_RowRects.Count) { m_RowRects = null; throw new InvalidOperationException(string.Format("....", rowCount, m_RowRects.Count)); } .... } In this case, the exception throw (access by the null reference m_RowRects) will happen when generating the message string for another exception. Code might be fixed, for example, as follows: public override void GetFirstAndLastRowVisible(....) { .... if (rowCount != m_RowRects.Count) { var m_RowRectsCount = m_RowRects.Count; m_RowRects = null; throw new InvalidOperationException(string.Format("....", rowCount, m_RowRectsCount)); } .... } One more error when checking PVS-Studio warning: V3080 CWE-476 Possible null dereference. Consider inspecting 'additionalOptions'. MonoCrossCompile.cs 279 static void CrossCompileAOT(....) { .... if (additionalOptions != null & additionalOptions.Trim().Length > 0) arguments += additionalOptions.Trim() + ","; .... } Due to the fact that the & operator is used in a condition, the second part of the condition will always be checked, regardless of the result of the check of the first part. In case if the variable additionalOptions has the null value, the exception throw is inevitable. The error has to be corrected, by using the operator && instead of &. As we can see, among the warnings with the number V3080 there are rather insidious errors. Late check PVS-Studio warning: V3095 CWE-476 The 'element' object was used before it was verified against null. Check lines: 101, 107. StyleContext.cs 101 public override void OnBeginElementTest(VisualElement element, ....) { if (element.IsDirty(ChangeType.Styles)) { .... } if (element != null && element.styleSheets != null) { .... } .... } The variable element is used without preliminary check for null. While later in the code this check is performed. The code probably needs to be corrected as follows: public override void OnBeginElementTest(VisualElement element, ....) { if (element != null) { if (element.IsDirty(ChangeType.Styles)) { .... } if (element.styleSheets != null) { .... } } .... } In code there are 18 more errors. Let me give you a list of the first 10: V3095 CWE-476 The 'property' object was used before it was verified against null. Check lines: 5137, 5154. EditorGUI.cs 5137 V3095 CWE-476 The 'exposedPropertyTable' object was used before it was verified against null. Check lines: 152, 154. ExposedReferenceDrawer.cs 152 V3095 CWE-476 The 'rectObjs' object was used before it was verified against null. Check lines: 97, 99. RectSelection.cs 97 V3095 CWE-476 The 'm_EditorCache' object was used before it was verified against null. Check lines: 134, 140. EditorCache.cs 134 V3095 CWE-476 The 'setup' object was used before it was verified against null. Check lines: 43, 47. TreeViewExpandAnimator.cs 43 V3095 CWE-476 The 'response.job' object was used before it was verified against null. Check lines: 88, 99. AssetStoreClient.cs 88 V3095 CWE-476 The 'compilationTask' object was used before it was verified against null. Check lines: 1010, 1011. EditorCompilation.cs 1010 V3095 CWE-476 The 'm_GenericPresetLibraryInspector' object was used before it was verified against null. Check lines: 35, 36. CurvePresetLibraryInspector.cs 35 V3095 CWE-476 The 'Event.current' object was used before it was verified against null. Check lines: 574, 620. AvatarMaskInspector.cs 574 V3095 CWE-476 The 'm_GenericPresetLibraryInspector' object was used before it was verified against null. Check lines: 31, 32. ColorPresetLibraryInspector.cs 31 Wrong Equals method PVS-Studio warning: V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. CurveEditorSelection.cs 74 public override bool Equals(object _other) { CurveSelection other = (CurveSelection)_other; return other.curveID == curveID && other.key == key && other.type == type; } Overload of the Equals method was implemented carelessly. One has to take into account the possibility of obtaining null as a parameter, as this can lead to a throw of an exception, which hasn't been considered in the calling code. In addition, the situation, when _other can't be cast to the type CurveSelection, will lead to a throw of an exception. The code has to be fixed. A good example of the implementation of Object.equals overload is given in the documentation. In the code, there are other similar errors: V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. SpritePackerWindow.cs 40 V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. PlatformIconField.cs 28 V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. ShapeEditor.cs 161 V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. ActiveEditorTrackerBindings.gen.cs 33 V3115 CWE-684 Passing 'null' to 'Equals' method should not result in 'NullReferenceException'. ProfilerFrameDataView.bindings.cs 60 Once again about the check for null inequality PVS-Studio warning: V3125 CWE-476 The 'camera' object was used after it was verified against null. Check lines: 184, 180. ARBackgroundRenderer.cs 184 protected void DisableARBackgroundRendering() { .... if (camera != null) camera.clearFlags = m_CameraClearFlags; // Command buffer camera.RemoveCommandBuffer(CameraEvent.BeforeForwardOpaque, m_CommandBuffer); camera.RemoveCommandBuffer(CameraEvent.BeforeGBuffer, m_CommandBuffer); } When the camera variable is used the first time, it is checked for null inequality. But further along the code the developers forget to do it. The correct variant could be like this: protected void DisableARBackgroundRendering() { .... if (camera != null) { camera.clearFlags = m_CameraClearFlags; // Command buffer camera.RemoveCommandBuffer(CameraEvent.BeforeForwardOpaque, m_CommandBuffer); camera.RemoveCommandBuffer(CameraEvent.BeforeGBuffer, m_CommandBuffer); } } Another similar error: PVS-Studio warning: V3125 CWE-476 The 'item' object was used after it was verified against null. Check lines: 88, 85. TreeViewForAudioMixerGroups.cs 88 protected override Texture GetIconForItem(TreeViewItem item) { if (item != null && item.icon != null) return item.icon; if (item.id == kNoneItemID) // <= return k_AudioListenerIcon; return k_AudioGroupIcon; } An error, that in some cases leads to an access by a null link. The execution of the condition in the first block if enables the exit from the method. However, if this does not happen, then there is no guarantee that the reference item is non-zero. Here is the corrected version of the code: protected override Texture GetIconForItem(TreeViewItem item) { if (item != null) { if (item.icon != null) return item.icon; if (item.id == kNoneItemID) return k_AudioListenerIcon; } return k_AudioGroupIcon; } In the code there are 12 similar errors. Let me give you a list of the first 10: V3125 CWE-476 The 'element' object was used after it was verified against null. Check lines: 132, 107. StyleContext.cs 132 V3125 CWE-476 The 'mi.DeclaringType' object was used after it was verified against null. Check lines: 68, 49. AttributeHelper.cs 68 V3125 CWE-476 The 'label' object was used after it was verified against null. Check lines: 5016, 4999. EditorGUI.cs 5016 V3125 CWE-476 The 'Event.current' object was used after it was verified against null. Check lines: 277, 268. HostView.cs 277 V3125 CWE-476 The 'bpst' object was used after it was verified against null. Check lines: 96, 92. BuildPlayerSceneTreeView.cs 96 V3125 CWE-476 The 'state' object was used after it was verified against null. Check lines: 417, 404. EditorGUIExt.cs 417 V3125 CWE-476 The 'dock' object was used after it was verified against null. Check lines: 370, 365. WindowLayout.cs 370 V3125 CWE-476 The 'info' object was used after it was verified against null. Check lines: 234, 226. AssetStoreAssetInspector.cs 234 V3125 CWE-476 The 'platformProvider' object was used after it was verified against null. Check lines: 262, 222. CodeStrippingUtils.cs 262 V3125 CWE-476 The 'm_ControlPoints' object was used after it was verified against null. Check lines: 373, 361. EdgeControl.cs 373 The choice turned out to be small PVS-Studio warning: V3136 CWE-691 Constant expression in switch statement. HolographicEmulationWindow.cs 261 void ConnectionStateGUI() { .... HolographicStreamerConnectionState connectionState = PerceptionRemotingPlugin.GetConnectionState(); switch (connectionState) { .... } .... } The method PerceptionRemotingPlugin.GetConnectionState() is to blame here. We have already come across it when we were analyzing the warnings V3022: internal static HolographicStreamerConnectionState GetConnectionState() { return HolographicStreamerConnectionState.Disconnected; } The method will return a constant. This code is very strange. It needs to be paid attention. Conclusions I think we can stop at this point, otherwise the article will become boring and overextended. Again, I listed the errors that I just couldn't miss. Sure, the Unity code contains a big number of the erroneous and incorrect constructions, that need to be fixed. The difficulty is that many of the issued warnings are very controversial and only the author of the code is able to make the exact "diagnosis" in each case. Generally speaking about the Unity project, we can say that it is rich for errors, but taking into account the size of its code base (400 thousand lines), it's not so bad. Nevertheless, I hope that the authors will not neglect the code analysis tools to improve the quality of their product. Use PVS-Studio and I wish you bugless code!
0 comments
3. Intention This article is intended to give a brief look into the logistics of machine learning. Do not expect to become an expert on the field just by reading this. However, I hope that the article goes into just enough detail so that it sparks your interest in learning more about AI and how it can be applied to various fields such as games. Once you finish reading the article, I recommend looking at the resources posted below. If you have any questions, feel free to message me on Twitter @adityaXharsh. How Neural Networks Work Neural networks work by using a system of receiving inputs, sending outputs, and performing self-corrections based on the difference between the output and expected output, also known as the cost. Neural networks are composed of neurons, which in turn compose layers, or collections of neurons. For example, there is an input layer and an output layer. In between the these two layers, there are layers known as hidden layers. These layers allow for more complex and nuanced behavior by the neural network. A neural network can be thought of as a multi-tier cake: the first tier of the cake represents the input, the tiers in between, or lack thereof, represent the hidden layers, and the last tier represents the output. The two mechanisms of learning are Forward Propagation and Backward Propagation. Forward Propagation uses linear algebra for calculating what the activation of each neuron of the next layer should be, and then pushing, or propagating, those values forward. Backward Propagation uses calculus to determine what values in the network need to be changed in order to bring the output closer to the expected output. Forward Propagation As can be seen from the gif above, each layer is composed of multiple neurons, and each neuron is connected to every other neuron of the following and previous layer, save for the input and output layers since they are not surrounding by layers from both sides. To put it simply, a neural network represents a collection of activations, weights, and biases. They can be defined as: Activation: A value representing how strongly a neuron is firing. Weight: How strong the connection is between two neurons. Affects how much of the activation is propagated onto the next layer. Bias: A minimum threshold for whether or not the current neuron's activation and weight should affect the next neuron's activation. Each neuron has an activation and a bias. Every connection to every neuron is represented as a weight. The activations, weights, biases, and connections can be represented using matrices. Activations are calculated using this formula: After the inner portion of the function has been computed, the resulting matrix gets pumped into a special function known as the Sigmoid Function. The sigmoid is defined as: The sigmoid function is handy since its output is locked between a range of zero and one. This process is repeated until the activations of the output neurons have been calculated. Backward Propagation The process of a neural network performing self-correction is referred to as Backward Propagation or backprop. This article will not go into detail about backprop since it can be a confusing topic. To summarize, the algorithm uses a technique in calculus known as Gradient Descent. Given a plane in an infinite number of dimensions, the direction of change that minimizes the error must be found. The goal of using gradient descent is to modify the weights and biases such that the error in the network approaches zero. Furthermore, you can find the cost, or error, of a network using this formula: Unlike forward propagation, which is done from input to output, backward propagation goes from output to input. For every activation, find the error in that neuron, how much of a role it played in the error of the output, and adjust accordingly. This technique uses concepts such as the chain rule, partial derivatives, and multi-variate calculus; therefore, it's a good idea to brush up on one's calculus skills. High Level Algorithm Initialize matrices for weights and biases for all layers to a random decimal number between -1 and 1. Propagate input through the network. Compare output with the expected output. Backwards propagate the correction back into the network. Repeat this for N number of training samples. Source Code If you're interested in looking into the guts of a neural network, check out AI Chan! It's a simple to integrate library for machine learning I wrote in C++. Feel free to learn from it and use it in your own projects. https://bitbucket.org/mrsaturnsan/aichan/ Resources http://neuralnetworksanddeeplearning.com/ https://www.youtube.com/channel/UCWN3xxRkmTPmbKwht9FuE5A
0 comments
4. The following is an excerpt from the book, Unity 2017 Game Development Essentials - Third Edition written by Tommaso Lintrami and published by Packt Publishing. Unity makes the game production process simple by giving you a set of logical steps to build any conceivable game scenario. Renowned for being non-game-type specific, Unity offers you a blank canvas and a set of consistent procedures to let your imagination be the limit of your creativity. Essential Unity concepts By establishing the use of the Game Object concept, you are able to break down parts of your game into easily manageable objects, which are made of many individual component parts. By making individual objects within the game, introducing functionality to them with each component you add, you are able to infinitely expand your game in a logical, progressive manner. Component parts in turn have Variables, which are essentially properties of the component, or settings to control them with. By adjusting these variables, you'll have complete control over the effect that a component has on your object. The following diagram illustrates this: Assets These are the building blocks of all Unity projects. From textures in the form of image files, through 3D models for meshes, and sound files for effects, Unity refers to the files you'll use to create your game as assets. This is why, in any Unity project folder, all files used are stored in a child folder named Assets. This Assets folder is mirrored in the Project panel of the Unity interface; see the interface section in this chapter for more detail. Scenes In Unity, you should think of scenes as individual levels or areas of game content. However, some developers create entire games in a single scene, such as puzzle games, by dynamically loading content through the code. By constructing your game with many scenes, you'll be able to distribute loading times and test different parts of your game individually. New scenes are often used separately to a game scene you may be working on in order to prototype or test a piece of potential gameplay.

Any currently open scene is what you are working on. In Unity 2017, you can load more scenes into the hierarchy while editing, and even at runtime, through the new SceneManager API, where two or more scenes can be worked on simultaneously. Scenes can be manipulated and constructed by using the Hierarchy and Scene views. OK, now that we know what assets and scenes let’s start setting up a scene and building a game asset. Setting up a scene and preparing game assets Create a new scene from the main menu by navigating to Assets | Create | Scene, and name it ParallaxGame. In this new scene, we will set up, step by step, all the elements for our 2D game prototype. First of all, we will switch the camera setting in the Scene view to 2D by clicking on the button as shown by the red arrow in the following screenshot: As you can see, now the Scene view camera is orthographic. You can't rotate it as you wish, as you can do with the 3D camera. Of course, we will want to change this setting on our Main Camera as well. Also, we want to change the Orthographic size to 4.5 to have the correct view of the scene. Instead, for the Skybox, we will choose a very dark or black color as clear color in the depth setting. This is how the Inspector should look when these settings are done:   While the Clipping Planes distances are important for setting the size of the frustum cone of a 3D, for the Perspective camera (inside which everything will be rendered by the engine), we should only set the Orthographic Size to 4.5, to have the correct distance of the 2D camera from the scene. When these settings are done, proceed by importing Chapter2-3-4.unitypackage into the project. You can either double-click on the package file with Unity open, or use the top menu: Assets | Import | Custom Package. If you haven't imported all the materials from the book's code already, be sure to include the Sprites subfolder. After the import, look in the Sprites/Parallax/DarkCave folder in the Project view and you will find some images imported as textures (as per default). The first thing we want to do now is to change the import settings of these images, in the Inspector, from Texture to Sprite (2D and UI). To do so, select all the images in the Project view in the Sprites/Parallax/DarkCave folder, all except the _reference_main_post file. Which is just a picture used as a reference of what the game level should look like: The Import Settings shown in the Inspector after selecting the seven images in the Project view The Max Size setting is hidden (-) because we have a multi-selection of image files. After having made the multiple selections, again, in the Inspector, we will do the following: Set the Texture Type option to Sprites (2D and UI). By default, images are imported as textures; to import them as Sprites, this type must be set. Uncheck the Generate Mip Maps option as we don't need MIP maps for this project as we are not going to look at the Sprites from a distant point of view, for example, games with the zoom-in/zoom-out feature (like the original Grand Theft Auto 2D game) would need this setting checked. Set Max Size to the maximum allowed. To ensure that you import all the images at their maximum resolution, set this to 8192. This is the maximum resolution size for an image on a modern PC, imported as a Sprite or texture. We set it so high because most of the background images we have in the collection are around 6,000 pixels wide. Click on the Apply button to apply these changes to all the images that were selected: The Project view showing the content of the folder after the images have been set to Sprite in the Import Settings. Placing the prefabs in the game Unity can place the prefabs in the game in many ways, the usual, visual method is to drag a stored prefab or another kind of file/object directly into the scene. Before dragging in the Sprites we imported, we will create an empty GameObject and rename it ParallaxCave. We will drag the layer images we just imported as Sprites, one by one, from the Project view (pointing at the Assets/Chapters2-3-4/Sprites/Background/DarkCave folder) into the Scene view, or more simply, directly in the Hierarchy view as the children of our ParallaxCaveGameObject, resulting in a scene Hierarchy like the one illustrated here: You can't drag all of them instantly because Unity will prompt you to save an animation filename for the selected collection of Sprites; we will see this later for our character and for the collectable graphics. Importing and placing background layers In any game engine, 2D elements, such as Sprites, are rendered following a sort order; this order is also called the z-order because it is a way to express the depth or to cope with the missing z axis in a two-dimensional context. The sort order is assigned an integer number which can be positive or negative; 0 is the middle point of this draw order. Ideally, a sort order of zero expresses the middle ground, where the player will act, or near its layer. Look at this image: Image courtesy of Wikipedia: parallax scrolling   All positive numbers will render the Sprite element in front of the other elements with a lower number. The graphic set we are going to use was taken from the Open Game Art website at http://opengameart.org. For simplicity, the provided background image files are named with a number within parentheses, for example, middleground(z1), which means that this image should be rendered with a z sort order of 1. Change the sort order property of the Sprite component on each child object under ParallaxCave according to the value in the parentheses at the end of their filenames. This will rearrange the graphics into the appropriately sorted order. After we place and set the correct layer order for all the images, we should arrange and scale the layers in a proper manner to end as something like the reference image furnished in the Assets/Chapters2-3-4/Sprites/Background/DarkCave/ folder. You can take a look at the final result for this part anytime, by saving the current scene and loading the Chapter3_start.unity scene. You just read an excerpt from the book, Unity 2017 Game Development Essentials - Third Edition written by Tommaso Lintrami and published by Packt Publishing. Use the code ORGDA10 at checkout to get recommended eBook retail price for $10 only until April 30, 2018. 0 comments 5. This reference guide has now been proofread by @stimarco (Sean Timarco Baggaley). Please give your thanks to him. The guide should now be far easier to read and understand than previous revisions, enjoy! Note: The normal mapping tutorial has been temporarily moved, to be added back as its own topic, to help separate the two for more clarity. If anyone has any corrections, please contact me. 3D Graphics Primer 1: Textures. This is a quick reference for artists who are starting out. The first topic revolves around textures and the many things an artist who is starting out needs to understand. I am primarily a 3d artist and my focus will therefore be primarily on 3d art. However, some of this information is applicable to 2d artists. Textures What is a texture? By classical definition a texture is the visual and esp. tactile quality of a surface (Dictionary.com). Since current games lack the ability to convey tactile sensations, a texture in game terms simply refers to the visual quality of a surface, with an implicit tactile quality. That is, a rock texture should give the impression of the surface of a rock, and depending on the type, a rough or smooth tactile quality. We see these types of surfaces in real life and feel them in real life. So when we see the texture, we know what it feels like without needing to touch it due to our past experiences. But a lot more goes into making a convincing texture beyond the simple tactile quality. As you will learn as you read on, textures in games is a very complex topic, with many elements involved in creating them for realtime rendering. We will look at: Texture File Types & Formats Texture Image Size Texture File Size Texture Types Tiling Textures Texture Bit Depth Making Normal Maps (Brief overview only) Pixel Density and Fill Rate Limitation Mipmaps Further Reading Further Reading Creating and using textures is such a big subject that covering it entirely within this one primer is simply not sensible. All I can sensibly achieve here is a skimming over the surface, so here are some links to further reading matter. Beautiful Yet Friendly - Written by Guillaume Provost, hosted by Adam Bromell. This is a very interesting article that goes into some depth about basic optimizations and the thought process when designing and modeling a level. It goes into the technical side of things to truly give you an understanding on what is going on in the background. You can use the information in this article to find out how to build models that use fewer resources -- polygons, textures, etc. -- for the same results. This is the reason why this is the first article I am linking to: it is imperative to understand the topics discussed in this article. If you need any extra explanation after reading it, you can PM me and I am more than happy to help. However, parts of this article go outside the texture realm of things and into the mesh side, so keep that in mind if you're focusing on learning textures at the moment. UVW Mapping Tutorial - by Waylon Brinck. This is about the best tutorial I have found for a topic that gives all 3D artists a headache: unwrapping your three-dimensional object into a two-dimensional plane for 2D painting. It is the process by which all 3D artists place a texture on a mesh (model). NOTE: while this tutorial is very good and will help you in learning the process, UVW mapping/unwrapping is just one of those things you must practice and experiment with for a while before you truly understand it. Poop In My Mouth's Tutorials - By Ben Mathis. Probably the only professional I know who has such a scary website name, but don't be afraid! I swear there is nothing terrible beyond that link. He has a ton of excellent tutorials, short and long, that cover both the modeling and texturing processes, ranging from normal-mapping to UVW unwrapping. You may want to read this reference first before delving into some of his tutorials. Texture File Types & Formats In the computer world, textures are really nothing more than image files applied to a model. Because of this, a variety of common computer image formats can be used. These include, .TGA, .DDS, .BMP, and even .JPG (or .JPEG). Almost any digital image format can be used, but some things must be taken into consideration: In the modern world of gaming, being heavily reliant on shaders, formats like the .JPG format are rarely used. This is because .JPG, and others like it, are lossy formats, where data in the image file is actually thrown away to make the file smaller. This process can result in compression artifacts The problem is that these artifacts will interfere with shaders, because these rely on having all the data contained within the image intact. Because of this, lossless formats are used -- formats like .DDS (if lossless option chosen), .BMP, and .TGA. However, there is such a thing called S3TC (also known as "dxt") compression. This was a compression technique developed for use on Savage 3D graphics cards, with the benefit of keeping a texture compressed within video memory whereas non-S3TC-compressed textures are not. This results in a 1:8 or greater compression ratio and can allow either more textures to be used in a scene, or can be used to increase the resolution of a texture without using more memory. S3TC compression can be made to work with any format, but is most commonly associated with the .DDS format. Just like the .jpg and other lossy formats, any texture using S3TC will suffer compression artifacts, and as such is not suitable for normal maps, (which we'll discuss a little later on). Even with S3TC it is common to use a lossless format for the texture format, and then apply S3TC when necessary. This is done to provide an artist with the ability to have lossless textures when needed -- e.g. for normal maps -- but then provide them with a method for compression on textures that could benefit from S3TC compression, such as diffuse textures. Texture Image Size The engineers who design computers and their component parts like us to feed data to their hardware in chunks that have dimensions defined as powers of two. (E.g. 16 pixels, 32 pixels, 64 pixels, and so on.) While it is possible to have a texture that is not the power of two, it is generally a good idea to stick to power-of-two sizes for compatibility reasons (especially if you're targeting older hardware). That is, if you're creating a texture for a game, you want to use image dimensions that are the power of two. Examples, 32x32, 16x32, 2048x1024, 1024x1024, 512x512, 512x32, etc. Say for example, you have a mesh/model and you're UV Unwrapping, for a game you must work within dimensions that are a power of two. Powers of two include: 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, and so on. What if you want to use images that aren't powers of two? In such cases, you can often use uneven pixel ratios. This means you can create your texture at, say, 1024x768, and then you can save it as 1024x1024. When you're applying your texture to your mesh you can stretch it back out in proportion. However, it is best to go for a 1:1 pixel ratio and create the texture starting at the power of 2, but the stretching is one method for getting around this if needed Please refer to the "Pixel Density and Fill Rate Limitation" section for more in depth info on how exactly to choose your image size. Texture File Size File size is important for a number of reasons. The file is the actual amount of memory (permanent or temporary) that the texture requires. For an obvious example, an uncompressed .BMP could be 6MB, this is the space it requires to be saved on a hard drive and within the video and/or system RAM. Using compression we can squeeze the same image into a file size of, say, 400 KB, or possibly even smaller. Compression, like that used by .JPG and other similar formats, will only do compression on permanent storage media, such as hard drives. That is to say, when the image is stored in video card memory it must be uncompressed within the memory, so you truly only get a benefit on storing the texture on its permanent medium but not in memory during use. Enter S3TC The key benefit of the S3TC compression system is that it compresses on hard drives, discs, and other media, while also staying compressed within video card memory. But why should you care what size it is within the video memory? Video cards have onboard memory called, unsuprisingly enough, video memory, for storing data that needs to be accessed fast. This memory is limited, so considerations on the artists' part must be used. The good news is that video card manufacturers are constantly adding more of this video memory -- known as Video RAM (or VRAM for short). Where once 64 MB was considered good, we can now find video cards with up to 1 GB of RAM. The more textures you have, the more RAM will be used. The actual amount is based primarily on the file size of each texture. Other data take up video memory, such as the model data itself, but the majority is used for textures. For this reason, it is a good idea to both plan your video memory usage and test how much you're using once in the engine. It is also advised that you have a minimum hardware configuration for what you want your game to run on. If this is the case, then you should always make sure your video memory usage does not go over the minimum target hardware's amount. Another advantage of in-memory compression like S3TC is that it can increase available bandwidth. If you know your engine on your target hardware may be swapping textures back and forth frequently (something that should be avoided if possible, but is a technique used on consoles), then you may want to consider having the textures compressed and then decompress them on the fly. That is to say, you have the textures compressed, and then when they're required, they're transported and then decompressed as they're added to video memory. This results in less data having to be shunted across the graphics card's bus (transport line) to and from the computer's main memory, resulting in less bandwidth utilization, but with the added penalty of a few wasted processing clocks. Texture Types Now we're going to discuss such things are diffuse, normal, specular, parallax and cube mapping. Aside from the diffuse map, these mapping types are common in what have become known as 'next-gen' engines, where the artist is given more control over how the model is rendered by use of control maps for shaders. Diffuse maps are textures which simply provide the color and any baked-in details. Games before shaders simply used diffuse textures. (You could say this is the 'default' texture type.) For example, when texturing a rock, the diffuse map of the rock would be just the color and data of that rock. Diffuse textures can be painted by hand or made from photographs, or a mixture of both. However, in any modern engine, most lighting and shadow detail is preferred to not be 'baked' (i.e. pre-drawn directly into the texture) into the diffuse map, but instead to have just the color data in the diffuse and use other control maps to recreate such things as shadows, specular reflections, refraction effects and so on. This results in a more dynamic look for the texture overall, helping its believability once in-game. 'Baking' such details will hinder the game engine's ability to produce "dynamic" results, which will cause the end result to look unrealistic. There is sometimes an exception to this rule: if you're providing "general" shading/lighting like ambient occlusion maps baked (merged) into the diffuse, then it is ok. These types of additions into the diffuse are general enough that they won't hinder the dynamic effect of running in a realtime engine, while achieving a higher level of realism. Another point to remember is that while textures sourced from photographs tend to work very well in 3D environment work, it is often frowned upon to use such 'photosourced textures' for humans. Human diffuse textures are usually hand-painted. Normal maps are used to provide lighting detail for dynamic lighting, however this is involved in an even more important role, as we will discuss shortly. Normal maps get their name from the fact that they recreate normals on a mesh using a texture. A 'normal' is a point (actually a vector) extending from a triangle on a mesh. This tells the game engine how much light the triangle should receive from a particular light source -- the engine simply compares the angle of the normal with the position and angle of the light itself and thus calculates how the light strikes the triangle. Without a normal map, the game engine can only use the data available in the mesh itself; a triangle would only have three normals for the engine to use -- one at each point -- regardless of how big that triangle is on the screen, resulting in a flat look. A normal map, on the other hand, creates normals right across a mesh's surface. The result is the capability to generate a normal map from a 2 million poly mesh and have this lighting detail recreated on a 200 poly mesh. This can allow an artist to recreate a high-poly mesh with relatively low polygons in comparison. Such tricks are associated with 'next-gen' engines, and are heavily used in screenshots of the Unreal 3 Engine, where you can see large amounts of detail yet able to run in realtime due to the actual amount of polys used. Normal maps use the different color channels (red, green, and blue) for storing gray scale data of lighting information at different angles, however there is no set standard for how these channels can be interpreted and as such sometimes require a channel to be flipped for correct function in an engine. Normal maps can be generated from high-poly meshes, or they can be image generated, that is, being generated from a gray scale map. However, high-poly generated normal maps tend to be preferred as they tend to have more depth. This is for various reasons, but the main one is that it is difficult for most to paint a grayscale map that is equal to the quality you'll receive straight from a model. Also, you will often find that the image generators tend to miss details, requiring the artist to edit the normal map by hand later. However, it is not impossible to receive near equal results using both methods, each have their own requirements, it is up to you on which to use in each situation (Please refer to the tutorial section for extended information on normal maps.) Specular maps are simple in creation. They are easy to paint by hand, because the map is simply a gray scale map that defines the specular level for any point on a mesh. However, in some engines and in 3D modeling applications this map can be full-color so the brightness defines the specular level and color defines the color of the specular highlights. This gives the artist finer control to produce more lifelike textures because the specific specular attribute of certain materials can be more defined and closer to reality. In this way you can give a plastic material a more plastic-like specular reflection, or simulate a stone's particular specular look. Parallax mapping picks up where regular normal mapping fails. We create normals on a model by use of a normal map. A parallax map does the same thing as a normal map except it samples a grayscale map within the alpha channel. Parallax mapping works by using the angles recorded in the tangent space normal maps along with the heightmap to calculate which way to displace the texture coordinates. It uses the grayscale map to define how much the texture should be extruded outwards, and uses the angle information recorded in the tangent normal map to determine the angle to offset the texture. Doing things this way a parallax map can then recreate the extrusion of a normal map, but without the flattening that visible in ordinary normal mapping due to lack of data at different perspectives. It mainly gets its name from how the effect is created by the parallax effect. The end results are cleaner and deeper extrusions with less flattening that occurs in normal mapping because the texture coordinates are offset with your perspective. Parallax mapping is usually more costly than normal mapping. Parallax also has the limitation of not being used on deformable meshes because of the tendency for the texture to "swim" due to the way textures are offset. Cube mapping uses a texture that is not unlike an unfolded box and acts just like a sky box when used. Basically this texture is designed like an unfolded box where it all is folded back together when being used. This allows us to create a 3d dimensional reflection of sorts. The result is very realistic precomputed reflections. For example, you would use this technique to create a shiny, metal ball. The cube map would provide the reflection data. (In some engines, you can tell the engine itself to generate a cube map from a specific point in the scene and have it apply the result to a model. This is how we get shiny, reflective cars in racing games, for example. The engine is constantly taking cube map 'photos' for each car to ensure it reflects its surroundings accurately.) Tiling Textures Now, while you can have unique, specific textures made for specific models, a common thing to do to both save time and video memory, is tiling textures. These are textures which can be fitted together like floor or wall tiles, producing a single, seamless texture/image. The benefit is that you can texture an entire floor in an entire building using a single tiling texture, which both saves the artist's time, and video memory due to fewer textures being needed. A tiling texture is achieved by having the left and right side of a texture blend into each other, and the same for the bottom and top of the texture. Such blending can be achieved by the use of a specialist program, a plugin, or by simply offsetting the texture a little to the left and down, cleaning up the seams, and then offsetting back to the original position After you create your first tiling texture and test it, you're bound to see that each texture will produce a 'tiling artifact' which shows how and where the texture is tiled. Such artifacts can be reduced by avoiding high-contrast detail, unique detail (such as a single rock on a sand texture), and by tiling the texture less. Texture Bit Depth A texture is just an image file. This means most of the theory you're familiar with when it comes to working with images also applies to textures. One such would be bit depth. Here you will see such numbers as 8, 16, 24, and 32 bits. These each correspond to the amount of color data that is stored for each image. How do we get the number 24 from an image file? Well, the number 24 refers to how many bits it contains. That is, that you have 3 channels, red, green, and blue, all of which are simply channels which contain a gray scale image, but are added together to produce a full color image. So black, in the red channel, means "no red" at that point, while white in the red channel means "lots of red". Same applies to blue and green. When these are combined, they produce a full color image, a mix of Red, Green and Blue (if using the RGB color model). The bits come in by the fact that they define how many levels of gray each channel has: 8 bits per channel, over 3 channels, is 24 bits total. 8 bits gives you 256 levels of gray. Combining the idea that 8 bits gives you 256 levels of gray and that each channel is simply gray scale and different levels of gray define a level within that color, we can then see that a 24 bit image will give us 16,777,216 different colors to play with. That is, 8 bits x 3 channels= 24 bits, 8 bits= 256 gray scale levels, so 256 x 3= 16,777,216 colors. This knowledge comes in useful when at certain times it is easier to edit the RGB channels individually, with a correct understanding you can then delve deeper into editing your textures. However, with the increase in shader use, you'll often see a 32 bit image/texture file. These are image files which contain 4 channels, each of 8 bits: 4 x 8 = 32. This allows a developer to use the 4th channel to carry a unique control map or extra data needed for shaders. Since each channel is gray scale, a 32 bit image is ideal to carry a full color texture along with an extra map within it. Depending on your engine you may see a full color texture with the extra 4th channel being used to hold a gray scale map for transparency (more commonly known as an "alpha channel"), specular control map, or a gray scale map along with a normal map in the other channels to be used for parallax mapping. As you paint your textures you may start to realize that you're probably not using all of the colors available to you in a 24 bit image. And you're probably right, this is why artists can at times use a lower bit depth texture to achieve the same or near the same look with a lesser memory footprint. There are certain cases where you will more than likely need a 24 bit image however: If your image/texture contains frequent gradations in the color or shading, then a 24 bit image is required. However, if your image/texture contains solid colors, little detail, little or no shading, and so on, you can probably get away with a 16, 8, or perhaps even a 4 bit texture. Often, this type of memory conservation technique is best done when the artist is able to choose/make his own color pallette. This is where you hand pick the colors that will be saved with your image, instead of letting the computer automatically choose. By using a careful eye you have the possibility to choose more optimal colors which will fit your texture better. Basically, in a way, all you're doing is throwing out what would be considered useless colors which are being stored in the texture but not being used. Making Normal Maps There are two methods for creating normal maps: Using a detailed mesh/model. Creating a normal map from an image. The first method is part of a common workflow that nearly all modelers who support normal map generation use. For generating a normal map from a model you can either generate it out to a straight texture, or if you're generating your normal map from a high-poly mesh, it is common to then model the low poly mesh around your high-poly mesh. (Some artists have prefer for modeling the low-poly version first while others like to do the high then the low, in the end there is no perfect way, its just preference.) For example: you have a high-poly rock, you will then model/build a low poly mesh around the high, then UVW unwrap it, and generate the normal map from your high-poly version. Virtual "rays" will be cast from the high- to the low-poly model -- a technique known as "projecting". This allows for a better application of your high-poly mesh normal map to your low-poly mesh since you're projecting the detail from the high to the low. However, some applications will switch the requirements and have your low poly mesh be inside your high, and others allow the rays for generating the normal map to be cast both ways. So refer to your application tutorials for how to do this as it may vary. Creating a normal map from an image. This method can be quicker than the more common method described above. For this, all you need is an edited version of your diffuse map. The key to good-looking image-based normal maps is to edit out any unneeded information for your grayscale diffuse texture. If your diffuse has any baked-in specular, shadows, or any information that does not define depth, this needs to be removed from the image. Also, anything that is extra, like strips of paint on a concrete texture, that too should be edited out. This is because, just like bump maps, and displacement maps, the colour of the pixels defines depth, with lighter pixels being "higher" than darker pixels. So, if you have specular (will turn white when made gray), it will be interpreted as a bump in your normal map, you don't want this if the specular in fact lays on a flat surface. The same applies to shadows and everything else mentioned: it will all interfere with the normal map generation process. You simply want to only have various shades of gray represent various depths, any other data in the texture will not produce the correct results. For generating normal maps you can always use the Nvidia Plugin, however it takes a lot of tweaking to get a good looking normal map. As such, I recommend Crazy Bump!. Crazy Bump will produce some very good normal maps if the given texture it is generating it from is good. Combining the two methods. It is common, even if you're generating a normal map from a 3d high-poly mesh to then generate an image generated normal map and overlay it over the high-poly generated one. This is done by generating one from your diffuse map, filling the resulting normal map's blue channel with 128 neutral gray, and then overlaying this over your high-poly generated one. This is done to add in those small details that only the image can generate. This way you get the high frequency detail along with the nice and cleanly generated mid-to-low frequency detail from your high-poly generated normal map. Pixel Density and Fill Rate Limitation Let's say you have a coin that you just finished UVW unwrapping, it will indeed be very small once in-game, however you decide it would be fine to use a 1024x1024 texture. What is wrong with the above situation? Firstly, you shouldn't need to UVW unwrap a coin! Furthermore, you should not be applying the 1024x1024 texture! Not only is this wasteful of video memory, but it will result in uneven pixel density and will increase your fill rate on that model for no reason. A good rule of thumb is to only use the amount of resources that would make sense based on how much screen space an object will take up. A building will take up more of the screen than a coin, so it needs a higher resolution texture and more polygons. A coin takes up less screen space and therefore needs fewer polys and a lower resolution texture to obtain a similar pixel density. So, what is pixel density? It is the density of each pixel from a texture on a mesh. For example, take the UVW unwrapping tutorial linked to in the "Texture Image Size" section: There you will see a checkered pattern, this is not only used to make sure the texture is applied right, but to also keep track of pixel density. If you increased the pixel density, you would see the checkered pattern get more dense; if you decrease the density, the checkered pattern would be less dense, with fewer squares showing. Maintaining a consistent pixel density in a game helps all of the art fit together. How would you feel if your high pixel density character walks up to a wall with a significantly lower pixel density? Your eyes would be able to compare the two and see that the wall looks like crap compared to the character, however would this same thing happen if the character were near the same pixel density of the wall? Probably not -- such things only become apparent (within reason) to the end user if they have something to compare it to. If you keep a consistent pixel density throughout all of the game's assets, you will see all of it fits together better. It is important to note that there is one other reason for this, but we'll come to it in a moment. First, we need to look at two related problems that can arise: transform(ation) limited and fill-rate limited modeling. A transform-limited model will have less pixel density per polygon than a fill-rate limited model where it has a higher pixel density per polygon. The theory is that a model takes longer on either processing the polys, or processing the actual pixel-dense surface. Knowing this, we can see that our coin, with very few polys will have a giant pixel density per polygon, resulting in a fill rate limited mesh. However, it does not need to be fill rate limited if we lower the texture resolution, resulting in a lower pixel density. The point is that your mesh will be held back when rendering based on which process takes longer: transform or fill rate. If your mesh is fill rate limited then you can speed up its processing by decreasing its pixel density, and its speed will increase until you reach transform limitation, in which your mesh is now taking longer to render based on the amount of polygons it contains. In the latter case, you would then speed up the processing of the model by decreasing the amount of polygons the model contains. That is, until you decrease the polygon count to the point where you're now fill rate limited once again! As you can see, it's a balancing act. The trick is to maximize the speed of the transform and fill rate processing (minimize the impact of both as much as you can), to get the best possible processing speed for your mesh. That said, being fill rate limited can sometimes be a good thing. The majority of "next-gen" games are fill rate limited primarily because of their use of texture/shading techniques. So, if you can't possibly get any lower on the fill rate limitation and you're still fill rate limited, then you have a little bit of wiggle room to work around where you can actually introduce more polygons with no performance hit. However, you should always try to cut down on fill rate limitations when possible because of general performance concerns Some methods revolve around splitting up a single polygon into multiple polygons on a single mesh (like a wall for example). This works by then decreasing the pixel density and processing (shaders) for the single polygon by splitting the work into multiple polygons. There are other methods for dealing with fill rate limitation, but mainly it is as simple as keeping your pixel density at a reasonable level. MipMaps It is fitting that after we discuss pixel density and fill rate limitation that we discuss a thing called Mipmapping. Mipmaps (or mip maps) are a collection of precomputed lower resolution image copies for a texture contained in the texture. Let's say you have a 1024x1024 texture. If you generate mipmaps for your texture, it will contain the original 1024x1024 texture, but it will also contain a 512x512, 256x256, 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2 version of the same texture, (exactly how many levels there are is up to you). These smaller mipmaps (textures) are then used in sequence, one after the other, according to the model's distance from the camera in the scene. If your model uses a 1024x1024 texture up close, it may be using a 256x256 texture when further away, and an even smaller mipmap texture level when it's way off in the distance. This is done because of many things: The further away you are from your mesh, the less polygonal and texture detail is needed. This is because all displays have a fixed display resolution and it is physically impossible for the player to decipher the detail of a 1024x1024 texture and 6,000 polygon mesh when the model takes up only 20 pixels on screen. The further away we are from the mesh, the fewer the polygons and the lower the texture resolution we need to render it. Because of the whole fill rate limitation described above, it is beneficial to use mipmaps as less texture detail must be processed for distant meshes. This results is a less fill-rate-heavy scene because only the closer models are receiving larger textures, whereas more distant models are receiving smaller textures. Texture filtering. What happens when the player tries to view a 1024x1024 texture at such a distance that only 40 pixels are given to render the mesh on screen? You get noise and aliasing artefacts! Without mipmaps, any textures too large for the display resolution will only result in unneeded and unwanted noise. Instead of filtering out this noise, mipmaps use a lower resolution texture for different distances, this results in less noise. It is important to note, that while mipmaps will increase performance overall, you're actually increasing your texture memory usage. The mipmaps and the whole texture will be loaded into memory. However, it is possible to have a system where the user or dev can select the highest mipmap they want and the ones higher than this limit will not be loaded into memory (as the system we're using now), however the mipmaps which meet or are lower than this limit will still be loaded into memory. It is widely agreed that the benefits of mipmaps vastly outweigh the small memory hit. NOTE: Mesh detail can also affect performance, so the equivalent method used for mesh detail is known as LOD -- "Level Of Detail. Multiple versions of the mesh itself are stored at different levels of detail. The less-detailed mesh is rendered when it's a long way away. Like mipmaps, a mesh can have any number of levels of detail you feel it requires. The image below is of a level I created which makes use of most of what we've discussed. It makes use of S3TC compressed textures, normal mapping, diffuse mapping, specular mapping, and tiled textures. 0 comments 6. Sounds This is our final part, 5 of a series on creating a game with the Orx Portable Game Engine. Part 1 is here, and part 4 is here. It's great that collecting the pickups work, but a silent game is pretty bland. It would be great to have a sound play whenever a pickup is collected. Start by configuring a sound: [PickupSound] Sound = pickup.ogg KeepInCache = true Then as part of the collision detection in the PhysicsEventHandler function, we change the code to be: if (orxString_SearchString(recipientName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstRecipientObject, 0); orxObject_AddSound(pstSenderObject, "PickupSound"); } if (orxString_SearchString(senderName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstSenderObject, 0); orxObject_AddSound(pstRecipientObject, "PickupSound"); } In code above, if the recipient is a pickup object, then use the orxObject_AddSound function to place our sound on the sender object. There's little point adding a sound to an object that is about to be deleted. And of course, if the pickup object is the sender, we add the sound to the recipient object. Also, the PickupSound that is added to the object, is the config section name we just defined in the config. Compile and run. Hit the pickups and a sound will play. You can also use sounds without code. There is an AppearSound section already available in the config. We can use this sound on the ufo when it first appears in the game. This is as simple as adding a SoundList property to the ufo: [UfoObject] Graphic = UfoGraphic Position = (0, 0, -0.1) Body = UfoBody AngularVelocity = 200 SoundList = SoundAppear Re-run and a nice sound plays at the start of the game. Adding a score What's a game without a score? We need to earn points for every pickup that is collected. The great thing about Orx objects is that they don't have to contain a texture as a graphic. They can contain a font and text rendered to a graphic instead. This is perfect for making a score object. Start by adding some config for the ScoreObject: [ScoreObject] Graphic = ScoreTextGraphic Position = (-380, -280, 0) Next, to add the ScoreTextGraphic section, which will not be a texture, but text instead: [ScoreTextGraphic] Text = ScoreText Now to define the ScoreText which is the section that contains the text information: [ScoreText] String = 10000 The String property contains the actual text characters. This will be the default text when a ScoreObject instance is created in code. Let's now create an instance of the ScoreObject in the Init() function: orxObject_CreateFromConfig("ScoreObject"); So far, the Init() function should look like this: orxSTATUS orxFASTCALL Init() { orxVIEWPORT *viewport = orxViewport_CreateFromConfig("Viewport"); camera = orxViewport_GetCamera(viewport); orxObject_CreateFromConfig("BackgroundObject"); ufo = orxObject_CreateFromConfig("UfoObject"); orxCamera_SetParent(camera, ufo); orxObject_CreateFromConfig("PickupObjects"); orxObject_CreateFromConfig("ScoreObject"); orxClock_Register(orxClock_FindFirst(orx2F(-1.0f), orxCLOCK_TYPE_CORE), Update, orxNULL, orxMODULE_ID_MAIN, orxCLOCK_PRIORITY_NORMAL); orxEvent_AddHandler(orxEVENT_TYPE_PHYSICS, PhysicsEventHandler); return orxSTATUS_SUCCESS; } Compile and run. There should be a score object in the top left hand corner displaying: 10000 The score is pretty small. And it's fixed into the top left corner of the playfield. That's not really what we want. A score is an example of a User Interface (UI) element. It should be fixed in the same place on the screen. Not move around when the screen scrolls. The score should in fact, be fixed as a child to the Camera. Wherever the Camera goes, the score object should go with it. This can be achieved with the ParentCamera property, and then setting the position of the score relative to the camera's centre position: [ScoreObject] Graphic = ScoreTextGraphic Position = (-380, -280, 0) ParentCamera = Camera UseParentSpace = false With these changes, we've stated that we want the Camera to be the parent of the ScoreObject. In other words, we want the ScoreObject to travel with the Camera and appear to be fixed on the screen. By saying that we don't want to UseParentSpace means that we want specify relative world coordinates from the centre of the camera. If we said yes, we'd have to specify coordinates in another system. And Position, of course, is the position relative to the center of the camera. In our case, moved to the top left corner position. Re-run and you'll see the score in much the same position as before, but when you move the ufo around, and the screen scrolls, the score object remains fixed in the same place. The only thing, it's still a little small. We can double its size using Scale: [ScoreObject] Graphic = ScoreTextGraphic Position = (-380, -280, 0) ParentCamera = Camera UseParentSpace = false Scale = 2.0 Smoothing = false Smoothing has been set to false so that when the text is scaled up, it will be sharp and pixellated rather than smoothed up which looks odd. All objects in our project are smooth be default due to: [Display] Smoothing = true: So we need to explicitly set the score to not smooth. Re-run. That looks a lot better. To actually make use of the score object, we will need a variable in code of type int to keep track of the score. Every clock cycle, we'll take that value and change the text on the ScoreObject. That is another cool feature of Orx text objects: the text can be changed any time, and the object will re-render. Finally, when the ufo collides with the pickup, and the pickup is destroyed, the score variable will be increased. The clock will pick up the variable value and set the score object. Begin by creating a score variable at the very top of the code: #include "orx.h" orxOBJECT *ufo; orxCAMERA *camera; int score = 0; Change the comparison code inside the PhysicsEventHandler function to increase the score by 150 points every time a pickup is collected: if (orxString_SearchString(recipientName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstRecipientObject, 0); orxObject_AddSound(pstSenderObject, "PickupSound"); score += 150; } if (orxString_SearchString(senderName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstSenderObject, 0); orxObject_AddSound(pstRecipientObject, "PickupSound"); score += 150; } Now we need a way to change the text of the score object. We declared the score object in the Init() function as: orxObject_CreateFromConfig("ScoreObject"); But we really need to create it using an orxOBJECT variable: scoreObject = orxObject_CreateFromConfig("ScoreObject"); And then declare the scoreObject at the top of the file: #include "orx.h" orxOBJECT *ufo; orxCAMERA *camera; orxOBJECT *scoreObject; int score = 0; Now it is possible to update the scoreObject using our score variable. At the bottom of the Update() function, add the following code: if (scoreObject) { orxCHAR formattedScore[5]; orxString_Print(formattedScore, "%d", score); orxObject_SetTextString(scoreObject, formattedScore); } First, the block will only execute if there is a valid scoreObject. If so, then create a 5 character string. Then print into the string with the score value, effectively converting an int into a string. Finally set the score text to the scoreObject using the orxObject_SetTextString function. Compile and Run. Move the ufo around and collect the pickups to increase the score 150 points at a time. Winning the game 1200 is the maximum amount of points that can be awarded, and that will mean we've won the game. If we do win, we want a text label to appear above the ufo, saying “You win!”. Like the score object, we need to define a YouWinObject: [YouWinObject] Graphic = YouWinTextGraphic Position = (0, -60, 0.0) Scale = 2.0 Smoothing = false Just like the camera, the YouWinObject is going to be parented to the ufo too. This will give the appearance that the YouWinObject is part of the ufo. The Scale is set to x2. The Position is set offset up in the y axis so that it appears above the ufo. Next, the actual YouWinTextGraphic: [YouWinTextGraphic] Text = YouWinText Pivot = center And the text to render into the YouWinTextGraphic: [YouWinText] String = You Win! We'll test it by creating an instance of the YouWinObject, putting it into a variable, and then parent it to the ufo in the Init() function: orxObject_CreateFromConfig("PickupObjects"); scoreObject = orxObject_CreateFromConfig("ScoreObject"); ufoYouWinTextObject = orxObject_CreateFromConfig("YouWinObject"); orxObject_SetParent(ufoYouWinTextObject, ufo); Then the variable: #include "orx.h" orxOBJECT *ufo; orxCAMERA *camera; orxOBJECT *ufoYouWinTextObject; orxOBJECT *scoreObject; int score = 0; Compile and Run. The “You win” text should appear above the ufo. Not bad, but the text is rotating with the ufo much like the camera was before. We can ignore the rotation from the parent on this object too: [YouWinObject] Graphic = YouWinTextGraphic Position = (0, -60, 0.0) Scale = 2.0 Smoothing = false IgnoreFromParent = rotation Re-run. Interesting. It certainly isn't rotating with the ufo, but its position is still being taken from the ufo's rotation. We need to ignore this as well: [YouWinObject] Graphic = YouWinTextGraphic Position = (0, -60, 0.0) Scale = 2.0 Smoothing = false IgnoreFromParent = position.rotation rotation Good that's working right. We want the “You Win!” to appear once all pickups are collected. The YouWinObject object on created on the screen when the game starts. But we don't want it to appear yet. Only when we win. Therefore, we need to disable the object immediately after it is created using the orxObject_Enable function: ufoYouWinTextObject = orxObject_CreateFromConfig("YouWinObject"); orxObject_SetParent(ufoYouWinTextObject, ufo); orxObject_Enable(ufoYouWinTextObject, orxFALSE); Finally, all that is left to do is add a small check in the PhysicsEventHandler function to test the current score after each pickup collision: if (orxString_SearchString(recipientName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstRecipientObject, 0); orxObject_AddSound(pstSenderObject, "PickupSound"); score += 150; } if (orxString_SearchString(senderName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstSenderObject, 0); orxObject_AddSound(pstRecipientObject, "PickupSound"); score += 150; } if (orxObject_IsEnabled(ufoYouWinTextObject) == orxFALSE && score == 1200) { orxObject_Enable(ufoYouWinTextObject, orxTRUE); } We are checking two things: that the ufoYouWinTextObject is not yet enabled using the orxObject_IsEnabled function, and if the score is 1200. If both conditions are met, enable the ufoYouWinTextObject. Compile and run. Move the ufo around and collect all the pickups. When all are picked up and 1200 is reached, the “You Win!” text should appear above the ufo signifying that the game is over and we have won. And that brings us to the end! We have created a simple and complete game with some configuration and minimal code. Congratulations! I hope you enjoyed working through making the ufo game using the Orx Portable Game Engine. Of course, there are many little extras you can add to give your game that little extra polish. So, for just a bit more eye candy, there a couple more sections that you can follow along with if you wish. Shadows There are many ways to do shadows. One method is to use shaders… though this method is a little beyond this simple guide. Another method, when making your graphics, would be to add an alpha shadow underneath. This is a good method if your object does not need to rotate or flip. The method I will show you in this chapter is to have a separate shadow object as a child of an object. And in order to remain independent of rotations, the children will ignore rotations from the parent. First a shadow graphic for the ufo, and one for the pickups: Save these both into the data/texture folder. Then create config for the ufo shadow: [UfoShadowGraphic] Texture = ufo-shadow.png Alpha = 0.3 Pivot = center The only interesting part is the Alpha property. 0.1 would be almost completely see-through (or transparent), and 1.0 is not see-through at all, which is the regular default value for a graphic. 0.3 is fairly see-through. [UfoShadowObject] Graphic = UfoShadowGraphic Position = (20, 20, 0.05) Set the Position a bit to the right, and downwards. Next, add the UfoShadowObject as a child of the UfoObject: [UfoObject] Graphic = UfoGraphic Position = (0,0, -0.1) Body = UfoBody AngularVelocity = 200 UseParentSpace = position SoundList = AppearSound ChildList = UfoShadowObject Run the project. The shadow child is sitting properly behind the ufo but it rotates around the ufo, until it ends up at the bottom left which is not correct. We'll need to ignore the rotation from the parent: [UfoShadowObject] Graphic = UfoShadowGraphic Position = (20, 20, 0.05) IgnoreFromParent = position.rotation rotation Not only do we need to ignore the rotation of ufo, we also need to ignore the rotation position of the ufo. Re-run and the shadow sits nice and stable to the bottom right of the ufo. Now to do the same with the pickup shadow: [PickupShadowGraphic] Texture = pickup-shadow.png Alpha = 0.3 Pivot = center [PickupShadowObject] Graphic = PickupShadowGraphic Position = (20, 20, 0.05) IgnoreFromParent = position.rotation The only difference between this object and the ufo shadow, is that we want the pickup shadow to take the rotation value from the parent. But we do not want to take the position rotation. That way, the pickup shadow will remain in the bottom right of the pickup, but will rotate nicely in place. Now attach as a child to the pickup object: [PickupObject] Graphic = PickupGraphic FXList = RotateFX Body = PickupBody ChildList = PickupShadowObject Re-run, and the shadows should all be working correctly. And that really is it this time. I hope you made it this far and that you enjoyed this series of articles on the Orx Portable Game Engine. If you like what you see and would like to try out a few more things with Orx, head over our learning wiki where you can follow more beginner guides, tutorials and examples. You can always get the latest news on Orx at the official website. If you need any help, you can get in touch with the community on gitter, or at the forum. They're a friendly helpful bunch over there, always ready to welcome newcomers and assist with any questions. 0 comments 7. Creating Pickup Objects This is part 4 of a series on creating a game with the Orx Portable Game Engine. Part 1 is here, and part 3 is here. In our game, the player will be required to collect objects scattered around the playfield with the ufo. When the ufo collides with one, the object will disappear, giving the impression that it has been picked up. Begin by creating a config section for the graphic, and then the pickup object: [PickupGraphic] Texture = pickup.png Pivot = center [PickupObject] Graphic = PickupGraphic The graphic will use the image pickup.png which is located in the project's data/object folder. It will also be pivoted in the center which will be handy for a rotation effect later. Finally, the pickup object uses the pickup graphic. Nice and easy. Our game will have eight pickup objects. We need a simple way to have eight of these objects in various places. We will employ a nice trick to handle this. We will make an empty object, called PickupObjects which will hold eight copies of the pickup object as child objects. That way, wherever the parent is moved, the children move with it. Add that now: [PickupObjects] ChildList = PickupObject1 # PickupObject2 # PickupObject3 # PickupObject4 # PickupObject5 # PickupObject6 # PickupObject7 # PickupObject8 Position = (-400, -300, -0.1) This object will have no graphic. That's ok. It can still act like any other object. Notice the position. It is being positioned in the top left hand corner of the screen. All of the child objects PickupObject1 to PickupObject8 will be positioned relative to the parent in the top left corner. Now to create the actual children. We'll use the inheritance trick again, and just use PickupObject as a template: [PickupObject1@PickupObject] Position = (370, 70, -0.1) [PickupObject2@PickupObject] Position = (210, 140, -0.1) [PickupObject3@PickupObject] Position = (115, 295, -0.1) [PickupObject4@PickupObject] Position = (215, 445, -0.1) [PickupObject5@PickupObject] Position = (400, 510, -0.1) [PickupObject6@PickupObject] Position = (550, 420, -0.1) [PickupObject7@PickupObject] Position = (660, 290, -0.1) [PickupObject8@PickupObject] Position = (550, 150, -0.1) Each of the PickupObject* objects uses the properties defined in PickupObject. And the only difference between them are their Position properties. The last thing to do is to create an instance of PickupObjects in code in the Init() function: orxObject_CreateFromConfig("PickupObjects"); Compile and Run. Eight pickup objects should appear on screen. Looking good. It would look good if the pickups rotated slowly on screen, just to make them more interesting. This is very easy to achieve in Orx using FX. FX can also be defined in config. FX allows you to affect an object's position, colour, rotation, scaling, etc, even sound can be affected by FX. Change the PickupObject by adding a FXList property: [PickupObject] Graphic = PickupGraphic FXList = SlowRotateFX Clearly being an FXList you can have many types of FX placed on an object at the same time. We will only have one. An FX is a collection of FX Slots. FX Slots are the actual effects themselves. Confused? Let's work through it. First, the FX: [SlowRotateFX] SlotList = SlowRotateFXSlot Loop = true This simply means, use some effect called SlowRotateFXSlot, and when it is done, do it again in a loop. Next the slot (or effect): [SlowRotateFXSlot] Type = rotation StartTime = 0 EndTime = 10 Curve = linear StartValue = 0 EndValue = 360 That's a few properties. First, the Type, which is a rotation FX. The total time for the FX is 10 seconds, which comes from the StartTime and EndTime properties. The Curve type is linear so that the values changes are done so in a strict and even manner. And the values which the curve uses over the 10 second period starts from 0 and climbs to 360. Re-run and notice the pickups now turning slowly for 10 seconds and then repeating. Picking up the collectable objects Time to make the ufo collide with the pickups. In order for this to work (just like for the walls) the pickups need a body. And the body needs to be set to collide with a ufo and vice versa. First a body for the pickup template: [PickupObject] Graphic = PickupGraphic FXList = SlowRotateFX Body = PickupBody Then the body section itself: [PickupBody] Dynamic = false PartList = PickupPart Just like the wall, the pickups are not dynamic. We don't want them bouncing and traveling around as a result of being hit by the ufo. They are static and need to stay in place if they are hit. Next to define the PickupPart: [PickupPart] Type = sphere Solid = false SelfFlags = pickup CheckMask = ufo The pickup is sort of roundish, so we're going with a spherical type. It is not solid. We want the ufo to able to pass through it when it collides. It should not influence the ufo's travel at all. The pickup is given a label of pickup and will only collide with an object with a label of ufo. The ufo must reciprocate this arrangement (just like a good date) by adding pickup to its list of bodypart check masks: [UfoBodyPart] Type = sphere Solid = true SelfFlags = ufo Friction = 1.2 CheckMask = wall # pickup This is a static bodypart, and we have specified collision actions to occur if the ufo collides with a pickup. But it's a little difficult to test this right now. However you can turn on the debug again to check the body parts: [Physics] Gravity = (0, 0, 0) ShowDebug = true Re-run to see the body parts. Switch off again: [Physics] Gravity = (0, 0, 0) ShowDebug = false To cause a code event to occur when the ufo hits a pickup, we need something new: a physics hander. The hander will run a function of our choosing whenever two objects collide. We can test for these two objects to see if they are the ones we are interested in, and run some code if they are. First, add the physics hander to the end of the Init() function: orxClock_Register(orxClock_FindFirst(orx2F(-1.0f), orxCLOCK_TYPE_CORE), Update, orxNULL, orxMODULE_ID_MAIN, orxCLOCK_PRIORITY_NORMAL); orxEvent_AddHandler(orxEVENT_TYPE_PHYSICS, PhysicsEventHandler); This will create a physics handler, and should any physics event occur, (like two objects colliding) then a function called PhysicsEventHandler will be executed. Our new function will start as: orxSTATUS orxFASTCALL PhysicsEventHandler(const orxEVENT *_pstEvent) { if (_pstEvent->eID == orxPHYSICS_EVENT_CONTACT_ADD) { orxOBJECT *pstRecipientObject, *pstSenderObject; /* Gets colliding objects */ pstRecipientObject = orxOBJECT(_pstEvent->hRecipient); pstSenderObject = orxOBJECT(_pstEvent->hSender); const orxSTRING recipientName = orxObject_GetName(pstRecipientObject); const orxSTRING senderName = orxObject_GetName(pstSenderObject); orxLOG("Object %s has collided with %s", senderName, recipientName); return orxSTATUS_SUCCESS; } } Every handler function passes an orxEVENT object in. This structure contains a lot of information about the event. The eID is tested to ensure that the type of physics event that has occurred is a orxPHYSICS_EVENT_CONTACT_ADD which indicates when objects collide. If true, then two orxOBJECT variables are declared, then set from the orxEVENT structure. They are passed in as the hSender and hRecipient objects. Next, two orxSTRINGs are declared and are set by getting the names of the objects using the orxObject_GetName function. The name that is returned is the section name from the config. Potential candidates are: UfoObject, BackgroundObject, and PickupObject1 to PickupObject8. The names are then sent to the console. Finally, the function returns orxSTATUS_SUCCESS which is required by an event function. Compile and run. If you drive the ufo into a pickup or the edge of the playfield, a message will display on the console. So we know that all is working. Next is to add code to remove a pickup from the playfield if the ufo collides with it. Usually we could compare the name of one object to another and perform the action. In this case, however, the pickups are named different things: PickupObject1, PickupObject2, PickupObject3… up to PickupObject8. So we will need to actually just check if the name contains “PickupObject” which will match well for any of them. In fact, we don't need to test for the “other” object in the pair of colliding objects. Ufo is a dynamic object and everything else on screen is static. So if anything collides with PickupObject*, it has to be the ufo. Therefore, we won't need to test for that. First, remove the orxLOG line. We don't need that anymore. Change the function to become: orxSTATUS orxFASTCALL PhysicsEventHandler(const orxEVENT *_pstEvent) { if (_pstEvent->eID == orxPHYSICS_EVENT_CONTACT_ADD) { orxOBJECT *pstRecipientObject, *pstSenderObject; /* Gets colliding objects */ pstRecipientObject = orxOBJECT(_pstEvent->hRecipient); pstSenderObject = orxOBJECT(_pstEvent->hSender); const orxSTRING recipientName = orxObject_GetName(pstRecipientObject); const orxSTRING senderName = orxObject_GetName(pstSenderObject); if (orxString_SearchString(recipientName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstRecipientObject, 0); } if (orxString_SearchString(senderName, "PickupObject") != orxNULL) { orxObject_SetLifeTime(pstSenderObject, 0); } } return orxSTATUS_SUCCESS; } You can see the new code additions after the object names. If an object name contains the word “PickupObject”, then the ufo must have collided with it. Therefore, we need to kill it off. The safest way to do this is by setting the object's lifetime to 0. This will ensure the object is removed instantly and deleted by Orx in a safe manner. Notice that the test is performed twice. Once, if the pickup object is the sender, and again if the object is the recipient. Therefore we need to check and handle both. Compile and run. Move the ufo over the pickups and they should disappear nicely. We'll leave it there for the moment. In the final, Part 5, we'll cover adding sounds, a score, and winning the game. 0 comments 8. Collisions This is part 3 of a series on creating a game with the Orx Portable Game Engine. Part 1 is here, and Part 2 is here. There is one last requirement for the collision to occur: we need to tell the physics system, who can collide with who. This is done with flags and masks. Make a change to the ufo's body part by adding SelfFlags and CheckMask: [UfoBodyPart] Type = sphere Solid = true SelfFlags = ufo CheckMask = wall SelfFlags is the label you assign to one object, and CheckMask is the list of labels that your object can collide with. These labels don't have to match the names you give objects, however it will help you stay clean and organised. So in the config above, we are saying: the UfoBodyPart is a “ufo” and it is expected to collide with any bodypart marked as a “wall”. But we haven't done that yet, so let's do it now. We will only need to add it to the WallTopPart: [WallTopPart] Type = box Solid = true SelfFlags = wall CheckMask = ufo TopLeft = (-400, -300, 0) BottomRight = (400, -260, 0) Remember, that the other three wall parts inherit the values from WallTopPart. So each now carries the label of “wall” and they will collide with any other body part that carries the label of “ufo”. Re-run and press the left arrow key and drive the ufo into the left wall. It collides! And it stops. Now that the collision is working, we can flesh out the rest of the keyboard controls and test all four walls: void orxFASTCALL Update(const orxCLOCK_INFO *_pstClockInfo, void *_pContext) { if (ufo) { const orxFLOAT FORCE = 0.8; orxVECTOR rightForce = { FORCE, 0, 0 }; orxVECTOR leftForce = { -FORCE, 0, 0 }; orxVECTOR upForce = { 0, -FORCE, 0 }; orxVECTOR downForce = { 0, FORCE, 0 }; if (orxInput_IsActive("GoLeft")) { orxObject_ApplyForce(ufo, &leftForce, orxNULL); } if (orxInput_IsActive("GoRight")) { orxObject_ApplyForce(ufo, &rightForce, orxNULL); } if (orxInput_IsActive("GoUp")) { orxObject_ApplyForce(ufo, &upForce, orxNULL); } if (orxInput_IsActive("GoDown")) { orxObject_ApplyForce(ufo, &downForce, orxNULL); } } } Now is a good time to turn off the physics debug as we did earlier on. Compile and run. Try all four keys, and you should be able to move the ufo around the screen. The ufo can also collide with each wall. The ufo is a little boring in the way that it doesn't spin when colliding with a wall. We need to ensure the UfoBody is not using fixed rotation. While this value defaults to false when not supplied, it will make things more readable if we explicitly set it: [UfoBody] Dynamic = true PartList = UfoBodyPart FixedRotation = false The active ingredient here is to ensure that both the wall bodypart and the ufo bodypart both have a little friction applied. This way when they collide, they will drag against each other and produce some spin: [UfoBodyPart] Type = sphere Solid = true SelfFlags = ufo CheckMask = wall Friction = 1.2 [WallTopPart] Type = box Solid = true SelfFlags = wall CheckMask = ufo TopLeft = (-400, -300, 0) BottomRight = (400, -260, 0) Friction = 1.2 Re-run that and give it a try. Run against a wall on angle to get some spin on the ufo. The next thing to notice is that both the movement of the ufo and the spin never slow down. There is no friction to slow those down. We'll deal with the spin first. By adding some AngularDamping on the UfoBody, the spin will slow down over time: [UfoBody] Dynamic = true PartList = UfoBodyPart AngularDamping = 2 FixedRotation = false Re-run and check the spin. The ufo should be slowing down after leaving the wall. Now for the damping on the movement. That can be done with LinearDamping on the UfoBody: [UfoBody] Dynamic = true PartList = UfoBodyPart AngularDamping = 2 FixedRotation = false LinearDamping = 5 Re-run and the speed will slow down after releasing the arrow keys. But it's slower overall as well. Not 100% what we want. You can increase the FORCE value in code (ufo.cpp), in the Update function to compensate: const orxFLOAT FORCE = 1.8; Compile and run. The speed should be more what we expect. It would be nice for the ufo to be already spinning a little when the game starts. For this, add a little AngularVelocity : [UfoObject] Graphic = UfoGraphic Position = (0, 0, -0.1) Body = UfoBody AngularVelocity = 200 Run this and the ship will have a small amount of spin at the start until the AngularDamping on the ufo body slows it down again. Following the UFO with the camera While we can simply move the ufo around with the keys on a fixed background, it will be a more pleasant experience to have the ufo fixed and have the screen scroll around instead. This effect can be achieved by parenting the camera to the ufo so that wherever the ufo goes, the camera goes. Currently, our project is set up so that the viewport has a camera configured to it. But the camera is not available to our code. We will require the camera to be available in a variable so that it can be parented to the ufo object. To fix this, in the Init() function, extract the camera from the viewport into a variable by first removing this line: orxViewport_CreateFromConfig("Viewport"); to: orxVIEWPORT *viewport = orxViewport_CreateFromConfig("Viewport"); camera = orxViewport_GetCamera(viewport); And because the camera variable isn't defined, do so at the top of the code: #include "orx.h" orxOBJECT *ufo; orxCAMERA *camera; Now it is time to parent the camera to the ufo in the init() function using the orxCamera_SetParent function: ufo = orxObject_CreateFromConfig("UfoObject"); orxCamera_SetParent(camera, ufo); Compile and Run. Woah, hang on. That's crazy, the whole screen just rotated around when ufo. And it continues to rotate when hitting the ufo against the walls. See how the camera is a child of the ufo now? Not only does the camera move with the ufo, it rotates with it as well. We certainly want it to move with the ufo, but it would be nice ignore the rotation from the parent ufo. Add the IgnoreFromParent property to the MainCamera section: [MainCamera] FrustumWidth = 1024 FrustumHeight = 720 FrustumFar = 2.0 FrustumNear = 0.0 Position = (0.0, 0.0, -1.0) IgnoreFromParent = rotation Re-run. That's got it fixed. Now when you move around, the playfield will appear to scroll rather than it being the ufo that moves. This makes for a more dramatic and interesting effect. In Part 4, we will give the ufo something to do. The goal is to collect several pickups. 0 comments 9. The UFO This is part 2 of a series on creating a game with the Orx Portable Game Engine. Part 1 is here. We have a playfield, and now we need a UFO character for the player to control. The first step is the create the configuration for the ufo object in ufo.ini: [UfoObject] Graphic = UfoGraphic Position = (0, 0, -0.1) This indicates that the UfoObject should use a graphic called UfoGraphic. Secondly, its position will be centered in the playfield with (x,y) = (0,0). The -0.1 is the Z-axis, and this will be placed above the BackgroundObject whose Z-axis is set to 0. Then the UfoGraphic which the UfoObject needs: [UfoGraphic] Texture = ufo.png Pivot = center Unlike the background object, our ufo object will need to be assigned to a variable. This will make it possible to affect the ufo using code: Create the variable for our ufo object just under the orx.h include line: #include "orx.h" orxOBJECT *ufo; And in the Init() function, create an instance of the ufo object with: ufo = orxObject_CreateFromConfig("UfoObject"); Compile and run. You'll see a ufo object in front of the background. Excellent. Time to move to something a little more fun, moving the ufo. Controlling the UFO The ufo is going to be controlled using the cursor arrow keys on the keyboard. The ufo will be moved by applying forces. Physics will be set up in the project in order to do this. Also, we will use a clock to call an update function regularly. This function will read and respond to key presses. Defining Direction Keys Defining the keys is very straight forward. In the config file, expand the MainInput section in the ufo.ini by adding the four cursor keys: [MainInput] KEY_ESCAPE = Quit KEY_UP = GoUp KEY_DOWN = GoDown KEY_LEFT = GoLeft KEY_RIGHT = GoRight Each key is being given a label name, like: GoUp or GoDown. These label names are available in our code to test against. The next step is to create an update callback function in our code where the keys presses are checked: void orxFASTCALL Update(const orxCLOCK_INFO *_pstClockInfo, void *_pContext) { } And in order to tie this function to a clock (the clock will execute this function over and over), add the following to bottom of the Init() function: orxClock_Register(orxClock_FindFirst(orx2F(-1.0f), orxCLOCK_TYPE_CORE), Update, orxNULL, orxMODULE_ID_MAIN, orxCLOCK_PRIORITY_NORMAL); That looks very scary and intimidating, but the only part that is important to you is the parameter with “Update”. This means, tell the existing core clock to continually call our “Update” function. Of course you can specify any function name here you like as long as it exists. Let's test a key to ensure that our event is working well. Add the following code into the Update function: void orxFASTCALL Update(const orxCLOCK_INFO *_pstClockInfo, void *_pContext) { if (ufo) { if (orxInput_IsActive("GoLeft")) { orxLOG("LEFT PRESSED!"); } } } Every time Update is run, ufo is tested to ensure it exists, and then moves to check the input system for the label “GoLeft” (if it is active or pressed). Remember how GoLeft is bound to KEY_LEFT in the MainInput config section? If that condition is true, send “LEFT PRESSED!” to the console output window while the key is pressed or held down. Soon we'll replace the orxLOG line with a function that places force on the ufo. But before that, we need to add physics to the ufo. Compile and run. Press the left arrow key and take note of the console window. Every time you press or hold the key, the message is printed. Good, so key presses are working. Physics In order to affect the ufo using forces, physics need to be enabled. Begin by adding a Physics config section and setting Gravity with: [Physics] Gravity = (0, 980, 0) In order for an object in Orx to be affected by physics, it needs both a dynamic body, and at least one bodypart. Give the ufo a body with the Body property: [UfoObject] Graphic = UfoGraphic Position = (0, 0, -0.1) Body = UfoBody Next, create the UfoBody section and define the UfoBodyPart property: [UfoBody] Dynamic = true PartList = UfoBodyPart The body part is set to Dynamic which means that it is affected by gravity and collisions. A body needs at least one part, and so we need to define the UfoBodyPart: [UfoBodyPart] Type = sphere Solid = true The body part Type is set to be a sphere which will automatically size itself around the object's size, and the body is to be solid so that if it should collide with anything, it will not pass through it. Compile and Run. The ufo falls through the floor. This is because of the gravity setting of 980 in the y axis which simulates world gravity. Our game is a top down game. So change the Gravity property to: [Physics] Gravity = (0, 0, 0) Re-run (no compile needed) and the ufo should remain in the centre of the screen. The Physics section has another handy property available to visually test physics bodies on objects: ShowDebug. Add this property with true: [Physics] Gravity = (0, 0, 0) ShowDebug = true Re-run, and you will see a pinkish sphere outline automatically sized around the ufo object. For now we'll turn that off again. You can do this by changing the ShowDebug value to false, adding a ; comment in front of the line or simply just deleting the line. We'll set our ShowDebug to false: [Physics] Gravity = (0, 0, 0) ShowDebug = false Let's add some force to the ufo if the left cursor key is pressed. Change the code in the Update function to be: void orxFASTCALL Update(const orxCLOCK_INFO *_pstClockInfo, void *_pContext) { if (ufo) { const orxFLOAT FORCE = 0.8; orxVECTOR leftForce= { -FORCE, 0, 0 }; if (orxInput_IsActive("GoLeft")) { orxObject_ApplyForce(ufo, &leftForce, orxNULL); } } } The orxObject_ApplyForce function takes an orxVECTOR facing left and applies it to the ufo object. Compile and re-run. If you press and release the left arrow key, the ufo will move to the left. If you hold the left key down, the ufo will increase its speed and move out the left hand side of the screen. Even if you tap the left key once quickly, the ufo will still eventually travel out of the left of the screen. There is no friction yet to slow it down, or any barriers to stop it going out of the screen. Barrier Around The Border Even though the background looks it has a border, it is really only a picture. In order to create a barrier for the ufo, we will need to wrap the edges using some body parts. This means, the background object will also be given a body, and four body parts, one for each wall. Start with adding a body to the object: [BackgroundObject] Graphic = BackgroundGraphic Position = (0, 0, 0) Body = WallBody And then the body itself: [WallBody] Dynamic = false PartList = WallTopPart # WallRightPart # WallBottomPart # WallLeftPart This is different from the ufo body. This body is not dynamic. This means that it is a static body, one that cannot be affected by gravity. But dynamic objects can still collide with it. Also, there are four parts to this body, unlike the ufo which only had one. Start with the WallTopPart first: [WallTopPart] Type = box Solid = true TopLeft = (-400, -300, 0) BottomRight = (400, -260, 0) In this part, the type is a box body part. It is set to solid for collisions, ie so that a dynamic object can collide with it but not pass though it. Stretch the box to cover the region from (-400,-300) to (400, -260). At this point, it might be a good idea to turn on the physics debugging to check our work: [Physics] Gravity = (0, 0, 0) ShowDebug = true Re-run the project. The top wall region should cover the top barrier squares: Great. Next, we'll do the right hand side. But rather than copy all the same values, we'll reuse some from the top wall: [WallRightPart@WallTopPart] TopLeft = (360, -260,0) BottomRight = (400, 260, 0) Notice the @WallTopPart in the section name? This means: copy all the values from WallTopPart, but any properties in WallRightPart will take priority. Therefore, use the Type, and Solid properties from WallTopPart, but use our own values for TopLeft and BottomRight for the WallRightPart section. This is called “Section Inheritance”. This will come in very handy soon when we tweak values or add new properties to all four wall parts. Re-run the project, and there will now be two walls. Define the last two walls using the same technique: [WallBottomPart@WallTopPart] TopLeft = (-400,260,0) BottomRight = (400, 300, 0) [WallLeftPart@WallTopPart] TopLeft = (-400,-260,0) BottomRight = (-360, 260, 0) Now there are four walls for the ufo to collide with. Re-run and try moving the ufo left into the wall. Oops, it doesn't work. It still passes straight though. There is one last requirement for the collision to occur: we need to tell the physics system, who can collide with who. We'll cover that in Part 3. 0 comments 10. Overview Welcome to the 2D UFO game guide using the Orx Portable Game Engine. My aim for this tutorial is to take you through all the steps to build a UFO game from scratch. The aim of our game is to allow the player to control a UFO by applying physical forces to move it around. The player must collect pickups to increase their score to win. I should openly acknowledge that this series is cheekily inspired by the 2D UFO tutorial written for Unity. It makes an excellent comparison of the approaches between Orx and Unity. It is also a perfect way to highlight one of the major parts that makes Orx unique among other game engines, its Data Driven Configuration System. You'll get very familiar with this system very soon. It's at the very heart of just about every game written using Orx. If you are very new to game development, don't worry. We'll take it nice and slow and try to explain everything in very simple terms. The only knowledge you will need is some simple C++. I'd like say a huge thank you to FullyBugged for providing the graphics for this series of articles. What are we making? Visit the video below to see the look and gameplay of the final game: Getting Orx The latest up to date version of Orx can be cloned from github and set up with: git clone https://github.com/orx/orx.git After cloning, an$ORX environment variable will be created automatically for your system which will help with making game projects much easier. It will also create several IDE projects for your operating system: Visual Studio, Codelite, Code::Blocks, and gmake. These Orx projects will allow you to compile the Orx library for use in your own projects. And the $ORX environment variable means that your projects will know where to find the Orx library. For more details on this step, visit http://orx-project.org/wiki/en/tutorials/cloning_orx_from_github at the Orx learning wiki. Setting up a 2D UFO Project Now the you have the Orx libraries cloned and compiled, you will need a blank project for your game. Supported options are: Visual Studio, CodeLite, Code::Blocks, XCode or gmake, depending on your operating system. Once you have a game project, you can use it to work through the steps in this tutorial. Orx provides a very nice system for auto creating game projects for you. In the root of the Orx repo, you will find either the init.bat (for Windows) or init.sh (Mac/Linux) command. Create a project for our 2D game from the command line in the Orx folder and running: init c:\temp\ufo or init.sh ~/ufo Orx will create a project for each IDE supported by your OS at the specified location. You can copy this folder anywhere, and your project will always compile and link due to the$ORX environment variable. It knows where the libraries and includes are for Orx. Open your project using your favourite IDE from within the ufo/build folder. When the blank template loads, there are two main folders to note in your solution: config src Firstly, the src folder contains a single source file, ufo.cpp. This is where we will add the c++ code for the game. The config folder contains configuration files for our game.   What is config? Orx is a data driven 2D game engine. Many of the elements in your game, like objects, spawners, music etc, do not need to be defined in code. They can be defined (or configured) using config files. You can make a range of complex multi-part objects with special behaviours and effects in Orx, and bring them into your game with a single line of code. You'll see this in the following chapters of this guide. There are three ufo config files in the config folder but for this guide, only one will actually be used in our game. This is: ufo.ini All our game configuration will be done there. Over in the Orx library repo folder under orx/code/bin, there are two other config files: CreationTemplate.ini SettingsTemplate.ini These are example configs and they list all the properties and values that are available to you. We will mainly concentrate on referring to the CreationTemplate.ini, which is for objects, sounds, etc. It's good idea to include these two files into your project for easy reference. Alternatively you can view these online at https://github.com/orx/orx/blob/master/code/bin/CreationTemplate.ini and here: https://github.com/orx/orx/blob/master/code/bin/SettingsTemplate.ini   The code template Now to take a look at the basic ufo.cpp and see what is contained there. The first function is the Init() function. This function will execute when the game starts up. Here you can create objects have been defined in the config, or perform other set up tasks like handlers. We'll do both of these soon. The Run() function is executed every main clock cycle. This is a good place to continually perform a task. Though there are better alternatives for this, and we will cover those later. This is mainly used to check for the quit key. The Exit() function is where memory is cleaned up when your game quits. Orx cleans up nicely after itself. We won't use this function as part of this guide. The Bootstrap() function is an optional function to use. This is used to tell Orx where to find the first config file for use in our game (ufo.ini). There is another way to do this, but for now, we'll use this function to inform Orx of the config. Then of course, the main() function. We do not need to use this function in this guide. Now that we have everything we need to get start, you should be able to compile successfully. Run the program and an Orx logo will appear slowly rotating. Great. So now you have everything you need to start building the UFO game.   Setting up the game assets Our game will have a background, a UFO which the player will control, and some pickups that the player can collect. The UFO will be controlled by the player using the cursor keys. First you'll need the assets to make the game. You can download the file  assets-for-orx-ufo-game.zip which contains: The background file (background.png): The UFO and Pickup sprite images (ufo.png and pickup.png):   And a pickup sound effect (pickup.ogg): pickup.ogg Copy the .png files into your data/texture folder Copy the .ogg file into your data/sound folder. Now these files can be accessed by your project and included in the game.   Setting up the Playfield We will start by setting up the background object. This is done using config. Open the ufo.ini config file in your editor and add the following:   [BackgroundGraphic] Texture = background.png Pivot = center   The BackgroundGraphic defined here is called a Graphic Section. It has two properties defined. The first is Texture which has been set as background.png. The Orx library knows where to find this image, due to the properties set in the Resource section:   [Resource] Texture = ../../data/texture   So any texture files that are required (just like in our BackgroundGraphic section) will be located in the ../../data/texture folder. The second parameter is Pivot. A pivot is the handle (or sometimes “hotspot” in other frameworks). This is set to be center. The position is 0,0 by default, just like the camera. The effect is to ensure the background sits in the center of our game window. There are other values available for Pivot. To see the list of values, open the CreationTemplate.ini file in your editor. Scroll to the GraphicTemplate section and find Pivot in the list. There you can see all the possible values that could be used. top left is also a typical value. We need to define an object that will make use of this graphic. This will be the actual entity that is used in the game:   [BackgroundObject] Graphic = BackgroundGraphic Position = (0, 0, 0)   The Graphic property is the section BackgroundGraphic that we defined earlier. Our object will use that graphic. The second property is the Position. In our world, this object will be created at (0, 0, 0). In Orx, the coordinates are (x, y, z). It may seem strange that Orx, being a 2D game engine has a Z axis. Actually Orx is 2.5D. It respects the Z axis for objects, and can use this for layering above or below other objects in the game. To make the object appear in our game, we will add a line of code in our source file to create it. In the Init() function of ufo.cpp, remove the default line: orxObject_CreateFromConfig("Object"); and replace it with: orxObject_CreateFromConfig("BackgroundObject"); Compile and run. The old spinning logo is now replaced with a nice tiled background object. Next, the ufo object is required. This is what the player will control. This will be covered in Part 2.
3 comments

GameDev Contractors

1. ¡Saludos!
Espero que esté bien Me llegué a esta comunidad, y por el momento me siento muy cómodo entre todos ustedes. Grandes talentos y grandes proyectos. Es un placer para mí estar en un ambiente tan activo y grandioso. :] Mi nombre es Gerald, vivo en Islandia. Creo que me quedé en esta comunidad durante mucho tiempo, y no quería perder la oportunidad de dejar aquí mi oferta como productor musical, componiendo bandas sonoras para videojuegos. Trabajó en otros proyectos más pequeños, pero nunca tuvo la oportunidad de componer una banda sonora dedicada a un videojuego.  www.echoesofthestorm.org/listen   Echoes of the Storm es un proyecto personal como productor de música dedicado a videojuegos o contenido audiovisual. Realmente quiero participar en proyectos porque, al mismo tiempo, esto significa un desafío para mí, con ello, un mayor aprendizaje y oportunidades de mejora. Puedo componer en varios géneros musicales, aunque principalmente produzco música orquestal y folclórica en algunos casos. Luego también produzco heavy metal (a veces mezclándolo con orquestal) y música electrónica. Dejaré algunos audios adjuntos en este mensaje, pero también puedes escuchar algunas cosas más en mi sitio web (aún tengo que actualizarlo un poco). Si estás interesado en hacer música para tu proyecto, simplemente contáctame y podremos estar de acuerdo. Que tengas un buen día, gracias por leer y hasta pronto!
2. My name is Nick Torretta, I am a professional composer and founder of Elastic Music.  For almost a decade I have been writing music for all forms of media.  My work has been featured in internationally televised commercials, sitcoms, reality TV and films.  I have written custom scores for 7 indie game titles and I custom score projects for ad agencies and Boeing. I've just wrapped up a couple projects (including a full mod conversion endorsed by Blizzard) and I'm ready to take on more projects.  I've found video games to be the most satisfying and exciting projects! My rates are indie friendly, and I usually offer a hefty "first time" discount!  I also pride myself on flexibility, communication and working to achieve the game creator's vision instead of my own. You can view my portfolio at www.elasticmusicproductions.com.  I welcome your messages, questions or feedback and look forward to working with you to create something truly special.
3. We are a full-service 3D animation and art studio with over 10 years of experience in animation, game development, training simulators and other related industries. We are proud of our 3d team – consisting of best Ukrainian 3d professionals with extensive experience in AAA game titles, animated movies, cartoons. Our artists have background in gaming companies such as Crytek, Ubisoft, 4A Games, as well as big animation studios     Please find more info about us at tavo-art.com
4. Hey there! Jannik - that's me. I'm a freelance web developer since March 2016 and was a regular, employed web developer before - total experience - about five years. What can I help you with? Well, basically anything web development related. I bring a vast amount of experience in working with PHP, MySQL, PostgreSQL, JavaScript, jQuery, CSS(3), HTML(5) and Dojo amongst others. You can find a full list on my website. I've been working for a company called InnoGames (any many more) for quite a few years (one of the major browser/mobile game developers in Germany and Europe) - and I'm always working on my own browser- and client game projects, too. How much do I charge? It's a tough question. I usually charge about 33-35 EUR per hour (net) remote work during prime time (Monday-Friday, 9-to-5). However, I'm aware that there are lots of decent projects and start-ups out there on a budget - so I'm offering fixed prices and (much) lower rates for non-priority work I can do in the evenings and on weekends. General rule: It's negotiable - and I'm more willing to find a good rate for both of us if the project sounds interesting. Anyway. Should you be interested - don't shy away. I'll be available to answer your requests and find a good deal.
You can reach me by sending a mail to hello@janniklorenzen.de Thanks!
5. Hi, I'm an industry professional with a decade of freelancing experience. I specialize in projects that seek further funding through the creation of a demo/prototype/POC and have a limited budget. I've worked on a number of highlight projects in the past and deliberately choose to focus on indie projects now. If you have a great idea but are lacking a developer that can put it together, look no further! I'll even help you pitch through crowdfunding or publishers! https://www.linkedin.com/in/michelmony/ Cheers!
• Advertisement