1. Portability: My engine needs to work on whatever platform I want it do. "But Unity runs on everything, including <insert platform here>", it becomes a problem not being able to use your language of choice.
2. Licencing: No need to worry about licensing fees, which is great.
3. Optimization: Have you ever tried optimizing a closed source commercial engine? It sucks because you can't do it. Size optimization is one issue. One issue I see people talk about when it comes to Unity is minimum binary size. I already have a rather complex engine, and I can remove the complex components that aren't being used if need be. My engine generates very large executables (15mb in general, but VS13 takes 3 minutes to optimize it down to roughly 3mb). Sometimes, that's not desirable, especially if you are running on a platform with fixed resources. Another is rendering. Sometimes, I need certain functionality that Unity might not give me, such as GPU fencing, command buffers/lists, or direct hardware access on certain embedded platforms.
4. Custom needs: Unity can't do *everything*. It does many things, but sometimes, a closed source engine can limit your game in some ways, sorta like above.
Reasons I don't use Unity (don't take offense to this, I'm entitled to my opinion):
1. I wouldn't be caught dead writing a game in C# (my preference).
2. Pride as a seasoned and experienced programmer; I'm not a n00b.
3. I don't like Unity, or the fanboys who can't do a dammed thing without it, and yet criticize those who write their own.
I'm also going to say this (and I've said it before). When people hear the words "writing your own engine", they are immediately thinking "writing everything from scratch, hence re-inventing the wheel". This isn't always the case, and in mine, definitely not. My engine consists of multiple open source components with compatible licenses making it suitable for commercial projects. You don't have to write everything yourself. Let me give you a rundown as to how I chose my engine's components:
Tokamak for physics.
Stb for texture based ttf font rendering and ogg decompression.
Assimp and OpenCTM for 3D mesh parsing.
SDL for various portable solutions involving threading/synchronization, timing, OpenGL context management, input devices, etc.
Some misc code from the NVSDK used for debugging and other stuff.
NVIDIA's Gameworks SDK for lots of misc stuff, like the excellent open source and extensive math library.
NVTriStrip to "stripify" primitives.
jo_jpeg, a simple jpeg library I use for screenshots.
ezxml or irrXML for XML parsing.
Enet as a reliable UDP based networking client.
Angelscript for scripting.
What I have written is basically the glue to put everything together in a neat and organized set of interfaces. Some things I wanted to write myself, such as an extendable 3D rendering, audio and input interface that supports Direct3D, core OpenGL, OpenGL ES, OpenAL [soft], FMOD, OpenNI, Leap, etc. So putting this all together was done rather quickly, and done in about 2 months worth of work off and on. You might say that "I don't have that sort of time". Then fine. Time is the most valuable resource, as it is not renewable, but it's also important to use your time wisely, and considering my needs, it was well worth it, (and no, I didn't do nothing but write this engine; I worked on it in conjunction with a planned title).
This isn't an attempt to belittle those who use Unity, it's my defense from those who act like they are better than me because I don't. Do what works best for you. I've chosen my path, and it works best for me. If you need Unity or UE4, go for it.
EDIT: I ended up replacing NVTriStrip with TriStripper because I hear that it's not only faster, but has less bugs and has greater flexibility. Also added "recastnavigation", which uses Detour and Recast for AI navigation for 3D realms.
Well, there's a story behind the reason why I chose [Free]GLUT, and kept it.
This was initially a prototype concept from an idea I had once before going to bed. At the time, I just wanted to test it as quickly as possible plus it was an unseen benefit to be able to press a button, and the window changes to a borderless window the size of the desktop resolution. On top of that, I originally wrote this for MacOSX, and I didn't know how to initialize OpenGL without it before then. So, I kept using it.
For this game, FreeGLUT is fine. For my engine (which this game predates and hence, does not use), I use SDL because it contains various functions for system related stuff, and I can also use Direct3D with it.
Writing a game's save data to disk can easily be as simple as writing the contents of a structure to a .bin file. That's what I do for my game(s).
/* A carefully aligned structure holding your game save data */
bool save_game_data( struct savedata_t* savedata )
/* Attempt to create a new save game */
FILE* fp = fopen( "mysave.bin", "wb" );
/* If successful, write the data, and exit. If not, return a failure */
fwrite( savedata, 1, sizeof( struct savedata_t ), fp );
A game save can contain more than just variables, maybe something like a bitmap icon used as an avatar, etc. so you'd have to take alignment and formatting into consideration.
Another thing you could do would be to write some content to a .xml file then inject that and any other files necessary inside of a binary container such as a .zip file (which could have any extension desirable to mask that it's really a .zip file) so that everything is kept in one single file that can be read and/or written to easily. That's my two cents.
Maybe one of you knows how sprites were stored in 1997 or recognized the file signature.
For starters, keep in mind that you can't assume every DOS game uses the same resource file format. Usually they are custom designed to keep the every day person from easily reverse engineering it because devs generally don't want their assets stolen, so you could be infringing copyrights here depending on your intent. Keep in mind that there are some exceptions, but you certainly cannot count on those either.
If you're really serious about this, then you might want to start off with building good reverse engineering skills. Start by getting a good .exe disassembler and get a good knowledge of how x86 assembly works. If you don't know assembly, then there may be a rather steep learning curve ahead of you. I bought a book about reverse engineering, and it gives plenty of examples on reverse engineering functions in x86 assembly and discovering how code on a low level really works.
Listen to her. She knows what she's talking about.
That is the internet for you... Rule #37... the power of avatar images and game avatars.
Right. I'm still amazed how many people (even staff) keep mistaking L. Spiro for girl, even though he's explained the story behind that sketch he drew multiple times.
Btw, to the person who just rated down that comment... Not to be a jerk, but FYI, given the above statement, please don't get it twisted. I should have known that someone wouldn't catch the reference, and probably go "zomg misogyny"! Or maybe I just wrecked someone's fantasy about L. Spiro being a girl.
Drop your project for your own sake and for the sake of the others working with you. It is not fair to them that their hard work go to waste just because their programmer (you) has no clue how to program but just decided to jump into the deep end foolishly thinking he could learn to fly before learning to walk.
But the advice on how to learn programming remains constant. You still need to start with small projects and work your way up.
Listen to her. She knows what she's talking about.
Okay, so I'm porting my game to Windows Metro, because I believe it will be pretty well suited for it due to it's mechanics and minimalist art style. And of course, I'd like to target Windows 10 and take advantage of some of it's exclusive features, such as Cortana. Now, I've never actually used any APIs for Cortana before and I'm still rather new to writing apps for Windows Metro, but I think it would be a rather nifty feature to use in my game. So far, every example I find is for Windows Phone 8, which is great in all because I'm supporting that too, but nothing in C++ so far. Every example uses C#, and that's not the language my game uses.
So my question is (for those of you who are actively dev'ing with the Windows 10 preview), are the APIs basically the same between Windows Phone 8 and Windows 10? And where can I find the APIs for C++? All I can find is C# so far.
Well, I can at least recommend that you stick to making games and games-related stuff in your free time in indie projects or similar, even if you don't want to work for a game company ever again!
Yeah, that's the plan.
GL on the interview. I would love to take a C# job but I've pigeonholed myself into PHP at the moment and I don't want to become strongly identified with the language anymore. The junior hourly rates I was offered were even lower for me.
I already know I didn't get the job because I failed to answer the coding questions as efficiently as the interviewer wanted. So that's out the window.
For the C# dev position, I negotiated my salary from $22/hr to $25/hr. I still think that's rather low for a junior position, but oh well. I refuse to make $22/hr for a 3rd time in a row! Phone interview is tomorrow at noon.
bsr2000, on 15 Jan 2015 - 3:20 PM, said:
Hey just don't give up, I've been unemployed for a year, and I have more than 10+ years of experience in the gaming industry. No one wants to hire me...
How recent is your experience?
I worked on major AAA as a Level Designer, and I sent my resume to many companies but most of them never replied. Maybe because I don't have a US work visa to work there, and no one want to sponsor me...
That could be one reason. Since I don't live outside of the US, I can't comment on that. Aside from that, the level of pickiness has grown since the downturn of the economy. But like I asked, how "recent" is your experience?