Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Oct 2011
Offline Last Active Jan 27 2016 08:17 PM

#5141985 What programming skills for Unreal 4

Posted by on 25 March 2014 - 07:49 AM

It's pretty much a complete package as far as I can see, what programming skills would you need, assuming your not modifying the source(still cannot believe they are licensing the full source, that's 25 years worth of research and blood and sweat there).


We are talking about shaders/effects and some gameplay scripting such as LUA, or I think it's unreal script.....?


C++ for everything programming related and Blueprints (gameplay scripting, actor archetypes seem to be replaced with this as well.) Everything else seems to apply from UE3 to UE4, just learning how the editor works and the various tools available in it will get you far enough to make prototypes without going too deeply.

I've been toying around with it for the past couple of days, and the tools are nice for 20$. You can plop down $19 for one month and then cancel if you would like, they let you keep the source and all you lose by not continuing your subscription are updates and marketplace access (which isn't even available as of yet). Some of my friends have decided to go with 19$ every six months, since that was about how long it took to get UDK updates anyway.

#5115145 Database optimization

Posted by on 07 December 2013 - 11:13 AM

Actually real question is, is there a cache like mechanism (DB in memory ?) making this worthy?

You have to remember that SQL Server or whatever DBMS you use will have its trade offs, but more importantly you have to think about how your application uses and serves this data to its clients to truly nail down what those trade offs will be. 

At my current job we use a 2 layer stack, the first and more permanent storage are SQL server database instances that are built on a CQRS (Command Query Read Segregation) model and the most recently/frequently accessed data is cached in RavenDB.

The cool thing that we implemented recently was segregating the data into "components" to get a higher probability of hitting something in our RavenDB store. An example of what I mean by this is, instead of storing the player's entire save in the cache, you store pieces of it (their items, pieces of their skill tree, etc) separately so when you go to fetch a different player's save, most of that information is already cached and can be rebuilt without even hitting the database. The power of permutations will play in your favor this way, allowing you to load 90% or more of players' information from the fast NoSQL cache instead of having to do costly queries on the SQL DB.

CQRS is basically a way to scale your database queries (reads) independently of your database write operations (writes/updates). Yes, tweets come in at large volumes, but 90% of the time a client is fetching data. This goes more in depth: http://martinfowler.com/bliki/CQRS.html

Hope this helps!

#5022793 Is it worth investing time to learn 3D modeling.

Posted by on 18 January 2013 - 01:50 AM

If you want to get your hands on Autodesk 3DS Max, Maya, or Mudbox and you happen to be a student then you should check this out: http://students.autodesk.com/


Under free software are tons of products by Autodesk. I've used the latest 3ds max from here for various student game projects when I was in college. The best part is you can experiment with Maya and all of the great tutorials for it on 3dBuzz.com.

#5022777 Is it worth investing time to learn 3D modeling.

Posted by on 17 January 2013 - 10:55 PM

3D modeling is fun, addicting, and easy once you get the hang of it.




It's easy to get started and once you do making things like scenery objects, guns etc is all very easy. The hard part is finding good reference images or coming up with original ideas. Also, I had fun doing 3D animation because it gave me an excuse to buy foam swords and swing them at stuff to get an idea of how things should look. The hard part is modeling things with intense detail at high polygon counts, or making very detailed/long animations. 


Just like anything else, it takes time to get the hang of, but once you do it's a valuable skill to have as a programmer. It gives you a glimpse into how artists work and what kind of workflows they expect, among other things.

#5021057 In-Game Console

Posted by on 13 January 2013 - 05:01 AM

I don't know how I'd get started on binding input to the source, or even getting input to appear on the screen instead of using it to control the camera, as nife87 said above. 


I just added my console as one of the states in my game's state management system. That way it intercepts all of the inputs from the user while it's up, and when you're done you just pop it right off the state stack and go back to the game. You can use your game's internal logging system as a backing store for the console output also, which makes implementing it a bit easier because now your console window is a very watered down input parser/command execution host and log viewer. 

#5021051 Losing interest in game development...

Posted by on 13 January 2013 - 04:32 AM

The real trick is to avoid throwing everything out and starting over, and instead learn to apply refactoring rules to your existing code base. When you become a professional developer you refactor code about 10 times for every 1 time you write something totally new (and usually you are refactoring someone else's work).  This should also help keep you motivated, because by doing this, you'll always have something working to look at and tweak. Nothing sucks more than working for 3 weeks straight just to draw a triangle on screen.


This brings me to the next point, always try to get whatever your working on up and running as quickly as possible. This way, you always know if what you're doing is worth the effort (plus you actually have something to show off). In the industry, I believe this is called "Vertical Slicing".. correct me if I'm mistaken.


Lastly, the reason why programmers are paid so well is because we use our heads. Before you start blindly typing away in your IDE of choice, take a minute to conceptualize the system you're developing, what pieces make it up and more importantly how they fit together. See the pieces, see their relationships and then the implementation takes care of itself. Weigh the pros and cons and contrast the different ways of building the application to find the one that fits your needs best. You don't have to know every single way to design an application, just be aware that there is more than one, three or even fifty ways.

#4977936 Unreal Engine 3: When is source code access needed?

Posted by on 08 September 2012 - 03:25 AM

I'm of the opinion that UE3 source code access would only benefit you if you decided to integrate middle ware packages that didn't come with the engine (Euphoria, for example). Your company can drop 99 USD on a license for the Unreal Development Kit and still have C++ integration with Unreal script.

Most of the source code you'll be creating will be done in Unreal Script, which will be for things like gameplay, AI and scripted events. Any remaining high performance or specialized code (special math functions, database connections, player game save handling) can be done in C++ and used in Unreal Script like a library by using their built in interop API DLLBind.

I would recommend you peruse the Unreal Developers Network and contact Epic Games to get more detailed licensing information for your specific use case and project size. All of the information I present is from personal experience with Unreal Engine 3 (UDK specifically) as well as from the Unreal Developers Network.

#4976189 Absolute Beginner: How and Where to get these libraries? And other "?...

Posted by on 03 September 2012 - 03:16 PM

I would recommend that you start off with C# personally.


C# allows for much higher productivity than C++ and offers a lot of functionality in its "base" library. XNA has a large community with many tutorials as well, so there is a wealth of knowledge to pull from.

Even though you've started off with C++, I would recommend making the switch to C# until you're almost intermediate level ( like 8-12 months of constant programming ) and then go explore some other languages.

#4974931 about UDK

Posted by on 30 August 2012 - 03:49 PM

A few things about UDK

You can use C++ with UDK without having to pay for a license (its called DLLBind).

Unreal Script is a lot like C# in many ways, and offers many options for interop with other languages (you can invoke action script and C++ from Unreal Script as a matter of fact, and even .net assemblies can be consumed). The biggest challenge to learning Unreal Script isn't the language itself, but the API and how it works.

I've done quite a bit of Unreal Script and the biggest resource I've used to learn it is UDN (Unreal Developer's Network). I would recommend that you start there. Also feel free to PM me for more info.

#4966037 From java to c#

Posted by on 03 August 2012 - 10:07 PM

I jumped from Java into C# quite some time ago, and was surprised was how similar the languages are, though in C# I had to get use to the fact *everything* is an object.

Everything is an object in Java and as a matter I would say that your claim is backwards. In C# you have c-style structs which Java does not have. Also I would have to say (from experience) that doing C# and then going to C++ is a better route. Yes the two languages are very different, but they have many overlapping concepts and features. Pointers can be used in both languages, and you can invoke C++ code from C# applications using p-invoke (which is also MUCH easier to use than JNI by the way). The biggest thing to get a handle of when you move from C++ to C# is pointers, how memory is managed, scope and understanding the compilation process. I'm sure there are people who disagree with that, but those were the biggest gaps in my knowledge when crossing over.

Of course this is just my opinion, and I have to say that it's more important to just do what you feel is best and learn from your mistakes. Software development in general can become quite religious and sometimes for most people it boils down to what is trending instead of what may be optimal for what you want to do.

#4964553 Terraria Game Engine

Posted by on 30 July 2012 - 11:21 AM

If you get a program like ILSpy or .Net Reflector, you can actually decompile it and view the code. They didn't bother obfuscating it.. pretty ballsy.

#4962286 Easy programming language

Posted by on 23 July 2012 - 10:31 AM

I suggest you start out with something that is managed that also has a lot of tutorials.

Java will fit the bill perfectly for you in my opinion; it is very forgiving, has a long history and sports an easy to use API. Minecraft was created with Java, so take that for what it's worth. As far as Java editors go, I would go and look for Eclipse, specifically a version for Java SE and then install the latest JDK (Java Development Kit). Work at tutorials and small applications for a while and you'll be able to slowly make progress toward building "top notch" games. Note the use of the word slowly. It will take you a very long time to get to the point of making anything substantial, but it is very rewarding. My biggest piece of advice is to develop a passion for programming early on, and then the rest comes easy. Good luck.

#4957651 Packing The Game Resources

Posted by on 10 July 2012 - 10:43 AM

No games use .X as a native format, and security is but one of many reasons. Compression is not security. All games use their own proprietary format and you will be able to make your own as well. Instead of security, the reason most game companies use their own model formats is because they can control what data their model files contain. This is particularly important, since it does not make sense to keep data that your engine can not use, while at the same time it makes sense to be able to add data that your engine could use in the future. You need flexibility and thus you need your own format.

This is pretty much the biggest reason to use your own formats in my opinion. What you should really be caring about is how fast the file can load up and how small it is. For example, XNA uses .xnb which is just a simple binary format designed to be as close to the runtime representation as possible while cutting out as much extraneous information as they can. You probably would want to make some kind of management system that can handle the serialization and loading of this format at runtime (think ContentManager for XNA).

The guy who works one Tesla Engine goes over his binary serialization at his web site, and it is a very good description of how you would typically go about rolling your own content pipeline system.

#4956596 Help me change my life and career.

Posted by on 07 July 2012 - 02:19 AM


Google dislikes people who develop for Android, and provides them with terrible tools for programming. All people I have known who have worked on Android NDK have gone mad except one, and that is just because he is a “special” person who likes debugging with sprintf() and #if 0 instead of using breakpoints and watchpoints.

It really isn’t a joke. One of my coworkers confessed yesterday that since he got tasked with Android programming it is the first time in 5 or 6 years at this company that he has considered quitting. The other one literally has some kind of addiction to debugging, and so he is happy with Android programming.
Because that is basically all you are doing when working with the NDK. Pure raw unabridged debugging, and nothing else. Not moving forward, just debugging.

L. Spiro

I know this may be off topic, but this post is priceless

#4956594 3 different clients.. Which is father and child?

Posted by on 07 July 2012 - 02:15 AM

This is a fairly good beginning explanation of what a state is and where they can be seen.

One of the objectives you should consider when developing software is usability. Making 3 totally different "forms" or "windows" can create an experience that ranges from confusing to down right annoying (also, I consider this unprofessional as well since it makes your app look unpolished). If you handle these three states as, well.. states then you will have a much easier time understanding how to transition between them, which seems like the very thing you are asking about. If you create a state manager and delegate the actual functionality of the game to the child states, then the parent becomes your "State Manager" and the children are the "states". You should look into states as it has a lot of applications (Finite State Automata and AI for example) besides just managing views.