Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 21 Mar 2011
Offline Last Active Nov 28 2015 12:08 PM

#5263972 Advice From Former/Current Military Who Make Games

Posted by Gian-Reto on 28 November 2015 - 12:07 PM

For me, the key is to spend time on it in a systematic way, so it stays part of my life. It's amazing how much progress you make even if you spend only a little time on it daily.

Getting to the point where you left off last time is the difficult part here. For some aspects it takes time in itself (which is not bad, as it's tracing your steps, checking them again for correctness of decisions), for other aspects, you can start in seconds with just one look.




Pretty much this... if you only have 4 hours per week to spend on game dev, so be it. Just make sure you try to spend your 4 hours EVERY week... or at least as often as you can.


Those hours add up fast, and expecially when learning something new, skipping a week / scheduled time is the worst thing you can do. For one, every week you are not doing your scheduled "training", it becomes harder to get back into training... just as with PT for us civilians. And also, you will forget a lot if you do not keep using it.



The hard part is to start, when you lack confidence and direction as well as skill and expierience, and then from time to time when you have to solve a difficult problem that cannot be done in one or two weeks. Push through these though times, plan smart (maybe make sure you stretch the hard stuff to multiple settings so you have spent at least half of your weekly game dev time on something fun), and you will have a lot of fun with game development.


Good luck!

#5263672 Networking,make the hole game myselfe?

Posted by Gian-Reto on 26 November 2015 - 01:27 AM

Well, not every networked game needs a server... us old farts around here remember a time when most games that where "online" actually where peer-to-peer games, either played in the LAN or later with special Matchmaking servers.


Which of course comes with a whole host of its own problems, first of all the increased ability of players to cheat. But, if you accept that (and even client-server games today have to accept to some extent that even with the best security measures, cheating is still existing), you can cut out the biggest expense in an online game, or at least reduce its cost (if the server is only a "chat lobby" with matchmaking, you can probably host 10-100x as many players on the same hardware).


Will not be much simpler to develop though (you can cut out the whole server simulation / client synchronization part if you do it really peer to peer, the different clients still need to be synchronized... and many games still had a server, just one of the clients would start a server on one of the client machines).

#5263518 Survival Mmo

Posted by Gian-Reto on 25 November 2015 - 01:32 AM

If you are not an expierienced dev, forget about making an online game.


If you are not filthy rich or head a big studio, forget about doing an MMO.



Given that none of the above is true in your case (If one or both happens to be true for you, feel free to ignore my advice), just learn to create single player games first. Networking is about the hardest part to get right in game development, and all the other parts will already take years to learn and create. Learn to program, program old classics (pong, tetris, ...), learn to use a modern game engine, start doing small 3D games, release a game, then think about doing an online game. In this order.


And while doing that, a) make sure you can pay the bills, and b) make sure you have enough free time left for work/life balance. Let me tell you, all of that WILL fill years of your life before you should even start to think about doing online games, let alone an MMO.


Babysteps, man, babysteps.




About "is it a good idea": No.

Doing an MMO at the moment is a pretty bad idea. Are some big studios still doing it? Yes, of course. Most of them have given up, because they sunk millions into failed MMOs in the noughties. So many WoW clones have come and gone, some tried to survive by going free to play.

Most "MMOs" coming out today are "poor mans MMOs" that don't really try to fit 1000's of players into the same instance... they are glorified Matchmaking servers with a kind-of persistent world feeding players into normal 30 or 64 player matches.

Not that exiting, not MMO at all (Save the persistence if you call that MMO)... but seems like a compromise to keep cost down, and players do not seem to care.


Lesson 1: not everything that is called an MMO is an MMO! Make sure you do not use the monicker in a wrong way or you will face a lot of negative response for no reason (an MMO is seen as being pretty much impossible to do for a single dev, an online game with matchmaking is more achievable though, and your "MMO" could be just that)


Lesson 2: there is a time and a place for everything, and now is not the time for an MMO, and little space left for a new one! At least if you plan to do anything "traditional" (or, putting it more harshly, are copycatting the others). That might change once WoW has lost its last player, but that will most likely still take years... and if these players leaving the biggest MMO left will be in the market for a new MMO is highly questionable. It is very well possible that the WoW-leavers leave MMO playing for good, and what newcomers look for is not so clear yet. Maybe VR will give MMOs a new lease of life, maybe the fact that lots of big studios burned their hands doing MMOs will leave a big niche for some years (big companies are always oil tankers when it comes to reacting to the market).

Still, do extra market research before developing a game as time and resource hungry as an MMO.


Lesson 3: don't try to run before you can walk! Learn game development, then come back asking for online game development. You will be taken much more serious.

#5263515 Unity or Unreal?

Posted by Gian-Reto on 25 November 2015 - 01:06 AM


Epic may claim this but it is not true.  I still have a snapshot from 2009 which has the GOW source and the engine still has a Glide render path in it for Voodoo cards.  I also have the current version and there is a lot of shared code between the two. 



interesting... well, of course I went with Epics words, can't say if they are true or not (Unity will also not promote their engine with "newer rewritten, we keep our code alive for 8+ years!", so very well possible that Epic does the same).


But: you can at least tell that Epic TRIES to clean up old junk when moving to a new version. Which of course will break backwards compatibility (making it even harder to move a project from Unreal 3 to Unreal 4 for example), but seeing how bad the upgrade path for existing projects is in Unity (one of the reasons I took a break from Unity), and how much JUNK is left in the engine in Unitys case (If the deferred renderer would get as much attention by Unity like it does by Unreal, there would be less people still asking for the forward rendering path (yes I know there are still platforms and use cases that ask for a forward renderer)), I have to say I like Epics way of handling new engine versions better even if their claims are not 100% true.


Then there is the thing that Unity sometimes tries to implement something halfbaked, and relies way to much on 3rd party devs... the whole legacy deferred (Deferred lighting) renderer was a pretty lame duck... Unity users got stuck with this broken implementation for 3 years, while other engines already implemented a true deferred renderer. To this day FXAA is pretty much your only choice for Antialiasing if not using forward rendering in Unity... while better solutions have been around for years and are implemented by Unreal 4.



Not saying that it is okay to lie about a total rewrite of the engine, or that everything is all peachy in UE4 land (even now, after 2 years, people seem to still wait on important features that should have been in UE4 from the start)... just saying that in general, UE4 IS using less outdated junk.

#5263377 Unity or Unreal?

Posted by Gian-Reto on 24 November 2015 - 01:30 AM

Hello I have almost no coding/programming experience or game developement experience for that matter. I want to start making some small games to get started but I don't know which engine to use. So I ask which game engine I should use to create a 3D low poly, Online, PvP game (or work my way up to that). Or which engine should I use for any games period given my level of experience.


Just to add my 5 cents as a longtime Unity User (4 years total) and newbie Unreal Engine 4 user.


Ue4 is a fantastic engine, I am really excited about learning the ins and outs of it... but the more I learn, the clearer the picture gets.


IMO, Unity 5 is easier to grasp for a newbie, and lets you still work more efficient even if you have more expierience. It is clearly made from the ground up for Indies and Small Teams needing all the efficiency they can get, and Unity has the better Tutorials and API documentation.


Many things are neatly integrated into the Editor in Unity. And many things are simple that are not in Unreal.

Need to transfer something from one scene to another? Drag and Drop it from the Scene Object list to the Asset Browser, Unity will automatically create a prefab out of it. Intuitive. In Unreal, you need to make a blueprint out of it, and there are limits to what you can convert to blueprint. Only then can it be saved and used in another scene.

Need to create a cubemap out of 6 images to create your skybox from? Just create an empty cubemap in Unity, drag and drop your 6 images into the right slots, and Unity handles the rest. Unreal will ask you to use outside tools to create a DDS format image out of your 6 source image. Only that can be used as cubemap source.


There is Blueprint, but for me as a programmer this is just another Programming language to learn. I am sure once you master it you can drag and drop scripts together much faster than with writing code, but then you cannot look at an image of a blueprint script and reproduce that 1 to 1 because the node names differ from the name in the list you pick the nodes from.


If I had to start over... I most probably would start with Unity again.



Now, where there is light, there is also shadow. Unreal clearly has the edge when it comes to rendering quality, at least out-of-the-box. It is much more forgiving in making the best of the 3D models you feed it (Unity by contrast can be rather fickle, if some normal is not aligned correct or there is some pixel error in the normalmap, Unity will show it, while Unreal will often not). There are so many options to completly confuse the beginner, but giving the more expierienced a lot of control over many aspects of the renderer and engine.


So much stuff that need to be bought from the Asset Store in Unity comes out of the box with Unreal.


And then there is the engine source code... if you are an able programmer, and really need something that is not supported out of the box, you can make it happen.

More often than not, that means ugly workarounds in Unity because their engine core is still closed source. And you never know if your ugly workaround is still supported in a new engine version (happened to me, though that was a PhysX physics engine feature that got cut).



IMO, Unreal Engine 4 is written by professional game devs for TEAMS of professional game devs... you know, the teams where everyone is a specialist and knows his thing.

Unity 5 by contrast is made for the small Indie lone dev and small mobile teams.


Unreal Engine 4 can be clearly used for creating mobile games and by Indies and hobbyists... you just will need more time to get into it, and more tools to suplement engine editor features. Unity might just make you a little bit more efficient, if you are not fussed about the visual scripting and get able to learn C# (the C# API of Unity is really good).


Unity 5 clearly can be used by larger teams and for big fat PC games... you just need to massage the renderer more to get good graphics quality out of it for modern 3D PC games, you might need 3rd party assets to add missing engine features, and a 3D artist that knows how to make his models look good in the engine.



AFAIK Unity has never been rewritten from scratch... seems like the Unity team is just adding features with every new version, sometimes replacing systems, but often just adding to them (hence the bloat of different renderers for Unity, forward, legacy deferred, deferred). And they have started as an Indie and mobile friendly engine.

Unreal by contrast gets rewritten from scratch for every major release and started life as the engine for epics own games... thus it is clearly PC centric, and has less bloat. You can be sure no part of the engine is older than 2012 (Or whenever they started developing the version 4)... in Unity there might be still part in the engine from 2006, from Unity 1 days.



2 radically different approaches producing 2 similarly powerful and well supported engines capable of producing any kind of game. I personally would say Unity is just that little bit more approachable for a beginner, save the blueprint system (which might be more approachable for a non-programmer). Unreal is the right engine for everyone who "hits the roof" with Unity when trying to develop powerful PC class 3D games.




Now, in your case, you might want to start with something simpler than any of these engines before moving to them. Else you will face a quite steep learning curve with both of them.

If you want to bang your head against that learning curve from the beginning, or feel you have dabbled enough in creating small 2D games from scratch, I personally would give Unity 5 a go.

For small games with simple graphics, Unity 5 is more than enough, and you will find it less confusing (thanks to less options for many things) and the documentation more approachable (don't get me wrong, there is plenty of documentation on Unreal Engine 4, its just often hard to find the right page).


Better yet, take a month or two, download both engines and dabble in both. See which one you like more. Maybe you are the visual scripting guy, and you like many options in your engine editor. Maybe you find the unity editor more confusing, or your models just look terrible in Unity, and good out of the box in Unreal.

The differences are sometimes subtle, so by testing both, you can make a more educated choice.


And let me tell you that one last thing: don't try to haste your game development. spending 2 or 6 months in selecting an engine is not wasted time. Compared to the time you will spend developing each of your games even if you are expierienced, it is nothing (multiple years often for 3D games, at least when you are alone and without much of a budget). Compared to the time it will take you to learn everything about 3D game development, it is even less (maybe 3 years... maybe more. I have spent 6 years learning, 20 hours per week and more, and I still feel like a beginner often).

Spend some months with both engines, these months are well spent and meaningless in light of the total time you will spend with the rest of your journey.

#5262415 Game opening

Posted by Gian-Reto on 17 November 2015 - 09:25 AM


The character customisation is a big part of the game, cosmetic and probably stat wise although I'm not sure how I'm handling stats because there's no forced combat it's optional so you only really need to focus on stats if you're choosing to do the fighting. I might add a skill based system, though. Just not sure what skills you'd have in that kind of setting.



I understand that cosmetics can play a big part in some games, but you need to understand not all players care about it. If a system is purely cosmetic make sure it is not too time consuming and skippable (like a character editor... can be pretty anoying when there is no "autogenerate" button... not everyone wants to tweak the angle of the jawbone in fractions of inches).


If you do not know what the point of skills should be in your game, better leave it out. No point in developing a system that doesn't add to your design. That time certainly is better spent elsewhere. Same, to a lesser degree, with the non forced combat. If combat is not an important part of your game, are you sure your game needs it?





Yes it fits, and the bouncer later becomes your godfather and is there to give you advice



Well, that is important additional information that you should have given from the start. I was under the impression the bouncer was a "throwaway NPC"... in this case, at least the bouncer certainly has his place in the opening.

What about the parents? What is their role in the later game apart from "genetics"? Will they feature? Do you plan to do story elements where the choice of parents will become important apart from the opening setting? (which may or may not be not so important in the long run... how many people do remember how a RPG started? Most probably you only remember the ones that started "with a bang". 20+ hours of (hopefully good) gameplay and story will have buried your memories of the other, mostly generic and boring starting story settings).

#5262405 Best Systems for 3D Modeling, Texturing, Terrain Generation, Light Maps, Anim...

Posted by Gian-Reto on 17 November 2015 - 08:49 AM

You have a lot of different things up there... I hope you are not looking for a "one to rule them all" tool?


I will list the general tool used for what you have in the list:


1) Landscape Generator for automatic creation, Landscape tools in the engine or 3D modelling tool for manually created terrain

2) Any 3D Package: Poly Modelling or Sculpting tool, most probably involves some NURBS / CAD modelling along the way

3) Any 3D Package:Poly Modelling or Sculpting tool, NURBS / CAD modelling might be used too (for equipment for example)

4) Any 3D Package with animation capabilities, game engine 

5) Game engine usually... you can bake Light maps in practically all 3D Packages though.

6) What are you talking about? Light blocking volumes? This is an game engine editor feature. Light cookies? 2D Image Editor.

7) Game engine editor. If you write from scratch, you might use thirdparty frameworks like FMOD

8) Any Sound editing tool or DAW will do.


Generally, there are the big fat 3D Packages (Maya, 3DS Max, Blender, ...)... apart from Blender, which is free, they tend to be VERY expensive. You can get a a Maya LT sub, but it still costs 30$ per month for a feature reduced version of Maya.


These tools can do most or all tasks in that list (Blende for example brings its own game engine along, if you want to use that).



What Engine are you planning to use? Do you want to write from scratch instead of using an engine?



Some recommendations from my side:


Get Blender. Learn how to use it. That tool does it all, is completly free and open source, and even where there are better tools out there for some tasks, Blender is always handy to have for the small things other, more specialized tools cannot do.


1) If you are looking for great generated terrain, check out World Machine. Its node based workflow is daunting at first, but gives you a lot of freedom on how to setup your generation scripts, and the results do look pretty good if you tweak the eriosion nodes correctly.

If you want to go the manual route, and are using existing engines (for example Unity or Unreal Engine 4) I would suggest you create your terrain with the game engine editor landscape tools. Much easier to work with than polymodelling, and the endproduct can then use the game engines Terrain LOD system.


2) I personally use 3D Coat for creating vehicles, which is a Voxel Sculpting tool (apart from 3D Painting and Retopo)... now while this tool allows me to work in details without worrying about the general topology, it is quite limited when it comes to doing NURBS like modelling for complex anorganic forms. I use MoI as an additional tool just for that, which is kind of "CAD Light".

These are both paid tools, altough not very expensive ones for what you get. You can also use Blender for this task which is free. The sculpting tools in blender are more basic, but you will mostly use boxmodelling and NURBS modelling for Vehicles anyway, which Blender does just fine. As an additional boon, Blender can also be used for Mesh duplication (for example for duplicating the wheels so that they all use the same mesh and texture), which 3D Coat doesn't do. I also need Blender as a last step in my workflow because of that.

Animation for vehicles is not really needed, can be done in code. If you want to create animations that you can just trigger in code though, you will need an animation tool like the one Blender provides.


3) virtually the same as creating vehicles for the mesh. Less need for NURBS modelling, more need for good sculpting tools. Blender should do fine, even though tools like 3D Coat or ZBrush (more expensive) are way better and more specialized tool for organic sculpting.

You most probably will want to make your organic mesh animatable as a "rigged mesh", which means you will need to place bones and do weightpainting on your mesh. Blender also does this. It even has basic autorig tools. If you have money for it, you can use online services like Mixamo to help you autorig your models (quality might depend on your models topology and bone structure).

Lastly you will need to animate the model with your bones and rig. You can either a) buy stock animations from Mixamo or the game engine asset stores (can get expensive quickly), b) MoCap your animations with tools like iPi + some cams (Ps Eye cam or XBOX Kinect), which will need actors, a lot of time and space apart from some money for the hard and software, or c) you create your animations manually, again, Blender can help you here.


4) Already answered above...


5) I always use the game engine tools to bake the light maps. Makes it simple to a) see the result asap ingame without export/import, and b) makes sure the result is compatible with the format the game engine expects.

If you go without using a game engine you will not be able to do that... I think blender has capabilites baking such maps, though I lack any expierience here.


6) If you are talking about Light cookies (b/w textures that can give a light a certain "shape", thus for example mimic the shadows produced by a window frame, or fake cloud shadows for a sun in an isometric view:

I use 2D Image editors for creating these. Pretty straightforward for directional and spotlights. Pretty mind boggling complex for point lights (because of the whole cube mapping to spherical projection stuff). Does the job pretty well. Get Gimp if you need a free 2D Image editor. You will need it anyway later to tweak your textures even if you use the 3D Painting tools in Blender (or 3D Coat like I do).


7) If you use an existing engine like I do (Unreal Engine 4 currently), you do not need to worry about that. The engine will cover all the basic needs. For more complex stuff (like procedural music and stuff like that), you can either look in the asset stores for existing solutions, or code it yourself. But if its just about playing and looping sound, don't worry. Unity/Epic got you covered.

If you write from scratch, well, either code it yourself or find one of the many existing frameworks and middleware solutions... FMOD is an example, but most probably not free. There might be free ones


8) Depends what you need. If you need to tweak existing audio effects, any audio tool will do. You could use expensive DAWs like Reaper or Cubase, but that most probably is way to expensive to just use for such a simple task.

I have a cheap Music Maker, Magix Music Maker, that does the job for me... which is basically clipping, pitch shifting and combining existing effects I bought.

There are free tools like Audiacity that can be used for such simple tasks.


If you want to record your own Audio Effects, you will have to spend some money for hardware most probably. And then you will want to invest into a little bit more elaborate tool than just audiacity. But to be honest, never tried that. If you search though the game engine asset stores or some of the audio sites on the net, you will find sound effects practically every occasion, and if you search long enough, you might even find some tracks that are not too expensive (though audio generally is expensive... recording and editing sounds does take a lot of time and skill).



If you want a better, more targetted answer, then tell us EXACTLY what you are planning to do... which engine? What kind of game? What is your budget?

#5262401 Armour penetration and firearms

Posted by Gian-Reto on 17 November 2015 - 07:56 AM

There is a gaming logic to explosives being better than bullets to robots.


Robots are often lumped together with vehicles or tanks in games (when it comes to damage/armour classes). I know a "grenade" (which should be a typical frag grenade most of the time) is very different than a anti-tank warhead fired from a RPG-kinda weapon, but they often fill the same role in games.


I could of course (if i want to complicate things down the road:)

frag grenade = normal damage (strong vs unarmoured weak vs rest)

some other grenade (what type?) = piercing damage (strong vs armoured)

emp grenade = only strong vs robots.


Yeah this can go on forever... smile.png


Well, realistically seen, there IS some merit to lumping HEAT Projectiles (which is the antitank warhead used by RPGs) together with High Explosive Warheads.


Many modern RPG HEAT warheads do allow you some kind of dual purpose use by making it possible to use the warhead as HEAT warhead (thus a strongly focused explosion that will melt the copper and thus create the molten metal stream, but almost zero explosive effect), or as a makeshift explosive warhead (by triggering the explosives at a different time AFAIK)... The explosion is not as strong as with a HE Warhead, and there is not as much fragmentation as with a Fragmentation warhead (like what is commonly used in Hand grenades), but it is still enough to level brick walls, so this dual purpose HEAT warhead is most probably the best realworld equivalent to your "explosive" warhead.

Highly effective against armour and vehicles, not so effective against spread out infantry (where the lower explosive payload will make it less effective).



Of course, lumping together armoured and unarmoured vehicles is just as right or wrong as lumping together armoured or unarmoured organic targets. shooting a human in "power armour" vs an unarmoured human with a .5 inch bullet has the same difference in effectivity as shooting an armoured battleship or an oil tanker with a 16" HE shell...


Both the power armoured human as well as the battleship will get their paint chipped, and might get injured lightly (the human might be blown off his feet even though the armour will not be penetrated, the battleship might get some superstructure damage even though no vital systems will be harmed)... as for the others examples, its game over.



But, as said, such inconistencies with reality could be completly ignored if you don't care about it, or could be explained if you do care but still want to go forward with your design.

#5262253 Armour penetration and firearms

Posted by Gian-Reto on 16 November 2015 - 09:02 AM

Well the point of having energy-weapons be anti-robot is mostly gameplay-related. So you should collect different weapons for different situations.

As understood from my first post, the game is not at all suitable for details such as having target movement effect penetration (that might be realistic though im not very familiar with science-fiction weapons). Neither will there be different damage classes for different energy weapons.


Yeah robots work sort of like armoured but with a twist (mainly regards to energy, fire and explosives). Fire = anti-organic, Explosion = anti-robot.


But some game do use energy-weapons as anti-robot, so i hope the concept doesnt seem TOO unintuitive?

And what about the other stuff? The numbers and how i divide melee weapons between normal and piercing?


Okay, in this case its kinda "anything goes"... you can always come up with "explanations" if something is not really how stuff works in real life.


I see Thaumaturges point, if we are talking about CHEAP entertainment class electronics devices, true, not much stuff will be redundant (which is why many of the cheap electronic devices like USB Stick will certainly die within years, while you could theoretically build one that will keep going for decades)...

Depending on what the backstory is behind your robots, that might actually make (some) sense... entertainment robots built for home use for example instead of military robots (which should be tough as nails, the difference should be even greater than between average john doe and an elite soldier).


Well, yeah, most games treat the term "energy weapon" as another word for "weair magical device we cannot explain ouselves", and then find sciency sounding names to make people believe this is still "science fiction" when it has basically become "fantasy in space" long ago.

About 5% of Star Wars is Science Fiction... the Rest is all fantasy.... those lasers and light sabers and even their space craft physics? All made up for maximum cinematic impact, not based in science at all. "Lasers" where just all the rage and really science-fiction in the seventies, that is why george lucas called his weird beam weapons lasers.

Star Wars and George Lucas never did take the time to try to come up with explanations, they clearly didn't have sciencists and technicians as consultants when they created the first 3 movies, and they didn't care about it in the meantime.


Now, I am NOT a particular fan of mixing fact with fiction WITHOUT giving audiences a particular hint about which is fact and which is fiction... which is why I DO like mixing science-fiction and magic (never been troubled by the force at all), but I highly dislike when something called like something from the real world doesn't work like it does in the real world (in case of Star Wars "Lasers", light moving way slower than lightspeed, a laserbeam being visible even without dust particles in the air, or making a sound when the beam zips by).



But that is me and my Nerd rage. I personally would call a weapon that is basically "future tech so advanced I don't understand it myself" by a name that isn't recognizable to other "raging nerds" like me that might pick your game apart because your laser do not follow normal laws of physics. Calling it a "death ray" or "particle beam" allows you to come up with your own "physics" that do satisfy the needs of your game design without having players bicker about you bending the laws of physic. It is, after all, incredibly advanced future tech... which is indistinguable from magic... and we all know that magic is used as a "deus ex machina" very often to explain stuff in games that just has to work the way it does for gameplay reasons.


Apart from that naming issue, your energy weapons can basically do whatever you want them to do. As soon as you abandon realworld examples (which there are not many really built ones anyway of besides lasers and maybe some microwave based weapons), your imagination is the only limitation.



About your close combat attack types, sound about right to me... piercing doing more damage to organic creatures could model how they have a bigger tendency to suffer from bloodloss.


I am still not 100% onboard about mechanical creatures taking more damage from explosions... but again, you could come up with some explanations....


e.g: The robots are old rust-buckets that haven't been properly maintained for years, and cannot maintain themselves. They will keep going until their nuclear core malfunctions or their frame collapses under its own weight after taking enough damage from rust and the weather, but they have become more fragile than some of the mutants running around.

While they still don't bleed when cut and don't care much about heat, their shells and frames have become quite fragile and will collapse quickly when blown up with explosives.



If you frame the backstory correctly, almost anything is explainable somehow. You CAN imitate star wars in not even trying to explain things, if you are ready to face some nerd rage and people calling you out on it (George Lucas reply was simply "The Star Wars Universe follows different laws of physics" smile.png )

#5262230 Any one using both UE4 and Unity 5?

Posted by Gian-Reto on 16 November 2015 - 05:11 AM

Rendering is quite different in Unity 5.


As a background, I used Unity till this Fall, including Unity 5, and have switched now to Unreal Engine 4.8. I am using 3D Coat for sculpting, texture painting and Retopo / normal baking at the moment, which handles the differences between the two engines for me.

In the process I tried importing models baked for Unity 5 into UE4, and also the other way round. You will isntantly see lots of shading errors without adjustements


Normal Maps are especially standing out. They seem to follow different standarts (I guess DX vs OpenGL)... but I am not 100% sure it is only the normal map, could also be that the normals are claculated differently. Now, this could very well be a problem with the way 3D Coat exports models to FBX/OBJ, or with the import settings in both engines (which I usually leave at the standarts for UE4 with good results, but need careful tweaking in Unity 5)...



In the end following Hodgmans recommendation would be wise. Unity is MUCH more fickle when it comes to which models get rendered correctly and which exhibit all kind of weird shading errors than any other of the 3 big engines I have tested to date. It is certainly not the fire-and-forget process that is importing 3D models to UE4. Also, their PBR Rendering shaders ARE kind of different than what UE4 does. And then there are the different renderers... Forward, Deferred, Legacy deferred... each influencing how stuff looks aside from performance impacts. Whereas UE4 AFAIK just gives you deferred.

Unity seems to stick to incremental updates to their original engine from 2007(?), whereas Epic seems to rewrite the engines more or less from scratch, which might explain some of these oddities.



Get the free version of Unity 5, and test your model with the same setting as the client needs. Maybe let the client provide you with a "test setup", some kind of project that allows you to drop your model in, add it to a testscene that will then use the exact same postprocessing and camera settings as the final product to make sure your model does work with his settings.


That might not work 100% as there might be some things your client cannot share (like 3rd party assets from the asset store), but it is definitely worth talking to the client to see how you can best test your models for Unity 5 to give him a smoother expierience with your services.





There are thousands of different 3rd party shaders in Unity, especially the different PBR shading systems are still widely in use AFAIK. Some of these are quite different than the Unity 5 standart shader, so definitely make sure you ask your client what shader he/she uses exactly. That might make a big difference on how useful your model is to him/her

#5261790 from C# programming to game design

Posted by Gian-Reto on 12 November 2015 - 11:46 AM


I try to build a portofolio right now. And yes I try it with a game in unity 3d. It is a simple one but a nice idea that I have. The problem is that it cannot be anything close to the demo games that other people have from their gaming universities. Because these are their final year projects and to do them they form teams with everyone that they need (designers, programmers etc).



Good, it means you have expierience in one of the most used Game Engines for many Indie and Mobile Studios out there. That is valuable expierience that needs to go into your CV somehow.

Better yet, use it to create some portfolio pieces.


Now, when you compare your output with the output of others, keep 3 things in mind:


1) your portfolio is built for professionals, game devs themselves (hopefully... if you get around the HR drones in case of bigger studios)


2) these projects you are referencing were built by a team, you are alone. Nobody expects you to replace a full team. Especially game developers know just how much work even a simple game is.


3) The portfolio piece should present your skill doing a job. If that job is to produce art, it needs to feature good 3D or 2D art... but most probably that doesn't need to be embedded in a working game. If you are looking for a job as level designer, make sure the level design is really good. That doesn't mean you need the best art in the world. In fact, place holder art can be fully acceptable for a future employer looking at your portfolio piece. You want to show him you can come up with awesome ways to structure a level, make sure the level supports the overall game design and keeps true to a theme, and respects the technical limitations of the engine and game itself.

You might not even need a full game to show off your levels.


Get free and stock art if you do not feel confident using just colored geometric shapes. If you need a confidence boost, look at some prototypes from even big studios containing placeholder art. If you want to compare your portfolio pieces as level or game designer to something, maybe choose that, not finished games.


Don't get me wrong, a good looking, finished game will look awesome in your portfolio... maybe its just not the best use of your time if you are looking for a job right now to polish a game into a releasable state.



I try to build a portofolio right now. And yes I try it with a game in unity 3d. It is a simple one but a nice idea that I have. The problem is that it cannot be anything close to the demo games that other people have from their gaming universities. Because these are their final year projects and to do them they form teams with everyone that they need (designers, programmers etc).


About the AI I said that I find it energy draining because of the effoert it needs to write the code and not because of the many hours of working. It is harder to think of algorithms and numbers than to retrieve data from a database or  code the front end of a webpage (yes I have done all of these). Still it seems like the AI coding is my only option to enter the gaming world right now. Sure I could go to create their tools or to build their webpage but I doubt that it is anywhere close to game design. 



Ah, so I did misunderstand you... you just don't like coding that much.


I think then you should really concentrate on level design for now. Less coding needed, also an entry position in many studios from what I read, and some scripting/coding skills will be required at many places as you might be expected to do some scripting. Which in turn let you use your current skillset for landing a job. Kind of a bridge between coding, art and game design from what I understand.

#5261784 Armour penetration and firearms

Posted by Gian-Reto on 12 November 2015 - 11:23 AM


Is this only for "unarmoured robots"? Shouldn't you then also have an "amroured robots" category?

I get the impression that mechanical targets are assumed to be armoured, perhaps all possessing a hard outer casing.




Plasma rifles AFAIK would do a mixture of heat and kinetic damage (After all, plasma is just superhot matter)

In this specific case, I believe that plasmas are ionised, and so may produce some degree of electrical damage.


As to lasers, I would imagine that organic targets might tend to be cauterised by laser burns, while mechanical targets likely don't have an analogous effect.



Well, which makes the distinction between mecahnical and armoured targets even more jarring IF armoured means JUST armoured biological targets, because the mechanical targets take more damage from explosions.



Ah, good point about the ionized plasma. That makes sense. Still, the "superhot" aspect might damage biological targets more.



True about the cauterizing effect, thought about it too. On the other hand, mechanical targets might not need it to be just as little affected by lasers, as the damage of a laser weapons is either very localized (ray piercing target with a very narrow wound-/damagechannel), or it kind of cuts through the target (given the laser has enough energy and the target is not heat resistant enough), which would then result in cut off limbs and stuff.

I would say a machine will cope better with having a limb cut off. reduntand systems and likely no shock effect will make sure that the machine has no ill effect to fear (besides a bad limp from now on), while in case of a wound getting cauterized in case of a biological being, the machine might not need this effect at all because it has "less valves" inside to pump fluids to begin with.... while biological creatures will have blood vessels almost everywhere in their body, and blood loss can be lethal, machines might only have some valving pumping fluids for pneumatic joints, everything else is electric (where a cut cable doesn't mean bleeding to death, and can easely be made redundant) 


Then there is the fact that a lot of the energy of lasers can be reflected away from the target by polishing the surface of the target.... which again, is most probably not an option for unarmoured biological targets, but is for unarmoured machines.


In the end I don't think lasers should do more damage to either class of target. If anything, they should rely on the speed of the target to determine their damage (very high damage to stationary target, the faster the target goes, the harder it is for the firer to concentrate the ray on a small area, the less damage a laser can do)

#5261764 Armour penetration and firearms

Posted by Gian-Reto on 12 November 2015 - 10:15 AM


What should the community engaging outside of the game discuss if your game design is "too obvious"? How could the skillers and number crunchers show off if everything is easy to learn and grasp?


Unless your game is about the crunching I don't view this as much of a benefit -- you have the crunchers in deep conversations with one another, and you have more casual players listening in to see what they should mimic, but what does that really buy you? I doubt if that discussion appeals to anyone not already playing your game, so I'd wager its not bringing in hordes of new customers. The level of chatter maybe looks good, but if its not directed at a positive effect, that's all it is -- chatter. Perhaps if you have an IAP-driven game where the discussion helps drive sales it has a business impact, but if you're relying on subtleties, controversy, and differing opinions to stoke sales figures, you're fleecing your customers.


I'd personally much rather have player's engagement directed at playing the game, rather than playing the meta-game. Let them share their excitement about the game, not the meta-game. Let them make videos about how much fun the game is, not about how deep the meta-game is. Again, I've got some bias here since I don't like deep simulations, but I think its not much use to foster that kind of community unless it actually furthers what the game is about, and I certainly would not build extraneous depth into a game to manufacture it where it doesn't belong.



I think there is just as much personal opinion as "depends on the game" in both your opinion and mine on the topic, but I would like to address some points and add some anecdotes:


You want players to keep being engaged with your game (if you strictly have a premium upfront cost model, you just want to engage them long enough for them to feel they got their moneys worth of entertainment)...

How exactly you manage that is different depending on your game, your ingame economy and revenue model, the meta game surrounding the game, and how attractive it is to youtubers and twitchers.


Now, what translates to sales or engagement is hard to measure... personally I'd try to engage people on as many levels as possible. And a deep "meta-game" can add to that. Maybe not for you, or every player of the game. Hell, most people don't even know there is an official forum for your game. But your most hardcore fans, the creme de la creme of your most loyal customers, the guys that will stick with your game no matter what (until you happen to anger them with some changes smile.png), they will use the forum as their social playground to mingle and network. This will be a valuable place for you to collect feedback and hand out official and unofficial ("planned leaks") information to the community.


You can be dead certain, when the information reaches your forum, it will reach youtube within days (given there is enough interest in your game)...


So having some form of meta-game, something to keep the hardcore fans chatting on your forum WILL be good not only for the community, but for you and your game. It is sometimes incredible what kind of free, volunteer support you can get from an engaged community. I certainly wouldn't say that what effort you put into building a community and forum for the top 5% most active players is only going to affect 5% of your playerbase. So feed them, keep them engaged. See what makes them tick. Of course the game you build will decide what kind of players will make up the core of your community, but IMO it is safe to say the chance of them being crunchers or at least parttime-crunchers is much higher than for the less hardcore part of your community.



I am all for keeping systems lean and mean, only building complexity in where needed. Certainly see if adding complexity adds to the game or if it just burns CPU cycles and confuses players for no gain.

But there are merits to keep some complexity in: Modern tank-adrcade-sims uniliterally feature a realistic armour and damage model. Impact angle, projectile speed and speed drop over distance, ballistic curve, different armour zones, sometimes different armour qualities are all modelled. Model for internal damage is also modelled to some degree, altough here simplification was employed to make a much too complex reality simpler (damage done to the internal space of a tank is extremly diverse... in fact, a lot of tanks taken out where just left by the crew fearing for ammo explosion or a fuel fire).


Why did these games go to that lengths to model a realistic armour and projectile trajectory model? When a simpler "facing side" 4 zone model could simplify the multi-armour zone model, impact angle could be ignored, or you could save a lot of calculations by not taking shell speed or a ballistic trajectory into account?

When in fact 90% of todays shooter that look ultrarealistic have just such simple internal amrour and damage models behind their realistic graphics?


Why, on the other hand, go with just some dozens of internal modules, HP and saving throws, without accuratly modelling spalling, or crew psychology?


The point is, the designers most likely decided a) this game should concentrate on the tank-nuts to get a loyal community that will not leave their game for the newest "my little pony" simulator when that appears on iOS, b) tanks needed to be about the big gun and the heavy armour, so there was value in concentrating on the shooting and armour penetration aspect of the expierience, and c) compared to what happens when a tank gets penetrated, the physics controlling the projectile in flight and armour penetration where comparatively simple and predictable.


They gave the tank nuts a game that allowed them to capture "the feel" of controlling a tank, which will always be about lining up the tank gun and trying to get around the opponents armour, without triggering nerd-rage because some of the most important things where not modelled (which got triggered briefly when people started arguing if the calculations of riccochets where actually correct or not). All the while abstracting and simplifying all the "hard work" parts of playing a simulator even tank nuts wouldn't care about... no switching gears or stuff like that.


Is the resulting meta-game good or bad for the game? Seeing that most of the streamers and bloggers keep up to date by visiting the official forums of these games, them being a lively place thanks to all the complexity that fuel thread after thread does help keeping them engaged too.


But even beyond the meta-game there is a lot these games gain by making some part of their gameplay more complex. Without more or less realistic vehicle physics, and the detailed armour mechanics the games would be FPSes just like call of duty. Nothing to set them apart other than the players model being skinned as tanks.

The more detailed physics and armour model has a deep effect on how the game is played though. Movement and positioning is slow, as is reloading your gun.

- You will NOT spray and pray!

- You will not jumpshot over an enemy!

- For most tanks, if you get into a tight situation, its to late to get out! Either the team helps, or you need to slug it out!

- As long as you have enough armour, you can actually take some hits without damage! But you need to work for it, angle your tank, angle your turret between shots, use terrain features to hide weakspots.


-> end result is you get a game that is just as or even more relying on skill as twitch FPS... but no longer the guy with the fastest mousehand and triggerfingers wins, but the guy that plans ahead, plays as a teamplayer, knows his tanks and the enemies tank, and knows the basics about how to position your tank to maximize protection.


Could the same have been achieved with simpler gameplay mechanics? Maybe. On the other hand, these games are quite successfull and these mechanics run on servers handling > 100'000 CCU, while nobody REALLY complains about the level of complexity, so while it might never reach CoD like masses of players because of its complexity, it still seem to work just fine.


The complexity can backfire a lot of course, seems World of Warships is just seeing their last update explode in their face... what was changed? They padded the complex ship armour models with 0 armour zones (for technical reasons I guess)... these zones triggered internal armour penetrations when the internal armour actually held up, leading to too high damage rolls. That was fixed... apparently there was another bug in the damage model before that go masked by the first bug, leading to all penetrations being treated as "over penetrations" (The shell passes through the ship without the explosive charge going off)...

Result? Massive reduction of damage done by gunfire... game is almost unplayable for some ship classes (among them the most popular one, Battleships, which rely exclusively on guns). 

THAT is the real price of complexity in my eyes, not users being confused (which can be mitigated with good tutorials and balancing complex and simplified parts well).





DmgClass       DmgToArmoured / DmgToRobot


normal           40   / 40

piercing          75   / 60

Energy           50   / 100  (lasers, plasma rifles etc)

Explosion       50   / 100

Fire                100 / 20

EMP               0    / 100


Thoughts? I want different weapons to have different roles, this is why energy is good vs robots and only ok vs armoured. Fire and explosion also have very different behaviour.

Numbers will be tweaked but this gives the idea.


 Totally agree with normal, fire and EMP damage.


Why does Energy and Exlposions do less damage to armoured organical stuff than to robots? Is this only for "unarmoured robots"? Shouldn't you then also have an "amroured robots" category?


A Robot will certainly not take more damage from both weapon type than an organical creature. Laser damage is actually heat-based, you could make some point that organical creatures take more damage because of that. Plasma rifles AFAIK would do a mixture of heat and kinetic damage (After all, plasma is just superhot matter)... again, why whould machines take more damage than organical beings?

I am sure you can come up with exotic "beam weapons" that send rays with an EMP like effect... but then you could come up with rays that kill biological creatures but do not affect machines, so it really evens out.


I either wouldn't make a distinction between machines and biological creatures and just keep the two version "armoured"/"unarmoured", or make the difference that machines are immune to some type of damage (Fire) while biological life is immune to an EMP, while keeping armoured/unarmoured distinctions for both.

If biological life tends to loose out (maybe you do want to make them squishier), you could give them selfhealing abilities machines lack... most biological life has a limited ability for self healing, which machines currently lack. They are more robust to make up for it, having redundant systems and all.

#5261599 from C# programming to game design

Posted by Gian-Reto on 11 November 2015 - 10:25 AM

Before you even think of moving into that direction....


Did you ever try to create a game? If you are passionate enough about it to swap your current career for it (and from what I get, you will take more risk and longer hours for lower pay when moving from IT into the games Industry), you should already start building things in your free time. There are many positive effects when doing this as a hobby first:



a) you can try your hand at multiple things (game design, level design, programming, art, if you want to) that might be hard to get into as entry positions (or with your current education)


b) you can try and see if game development REALLY is what you are looking for. You will of course not get the full expierience when doing things as a lone hobbist compared to working for a big studio, but you might get some things that are hard to grasp for outsiders normally (for example how utterly hard it is to even make simple GOOD games)


c) you have something to show if you decide to go this route and start applying for jobs in 6 months or so. Finding a job without prior expierience in the industry is most probably hard enough, having a portfolio that shows that you have SOME expierience and are passionate about building games cannot hurt.



Oh, and I really don't want to sound harsh or anything, but "...that AI programming is too energy consuming for me..." doesn't sound like game development in general is a good fit for you. Maybe I understood the sentence wrong, but expect long hours and regular crunch time in the game dev industry. It doesn't seem to be as bad as some people make it everywhere (black sheep and all), but compared to general IT you will work more for less pay most probably.

#5261593 Making Your First Game Is Only 7 Steps Away

Posted by Gian-Reto on 11 November 2015 - 10:08 AM

"So follow this step by step “Dive into the gaming industry” manual I prepared for you and let me know how it went."


And then he goes on to tell people to download a finished sample project and explains how to build for Android and Install the game on an Android handset... and that is the full tutorial. Simple, yes! Useful, not so much... 

You just got 1% of what goes into creating an Android game, now lets go back to step -109, which is the actual start of "How to build that sample project you just downloaded and pressed build for".



Lets restart and be more constructive:

- What exactly is the purpose of this blog post? Clearly the most important thing for newcomers to learn is NOT how to click the build button and install an APK on their devices?

- What is up with people still believing in the "loosing weight in 7 simple steps" or "learning C++ in 21 hours" scam? Okay, even if they do that, why go with that click-bait title?


If you really want to target game dev newbs, I think you should rethink your manual there. If you think you have to deal with the short attention span type of audience, take shortcuts (for example start with an example project, that part is good), but show them how to ACTUALLY USE Unity instead of trying to fake a simplicity that isn't there...

Yes building for different platforms is just a button click away... and we all know how well that will work without platform specific optimizations. Besides that small fact you haven't shown the newb actually much to get him started in the Unity editor.


- What about asset importing?

- What about using the Scene editor?

- What about the Game mode, about the stats and game testing?

- How about explaining the basics of the editor that are not as intuitive as Unity would like people to believe?



Anyway, if you are serious about it, good luck. Hope you rework your tutorial, because there is certainly room for another GOOD tutorial for beginners.