Jump to content

  • Log In with Google      Sign In   
  • Create Account

Josh Petrie

Member Since 11 Jun 2003
Offline Last Active Private

#5241611 Know almost nothing about Game Development; Here to learn

Posted by Josh Petrie on 20 July 2015 - 03:59 PM

I think you should focus on actually realizing one of those games before worrying about things like "franchises."


If, as you say, you are not much for the actual programming of games, then it's good to look at (as you seem to have done) using Unity or Unreal or some other toolchain-focused engine that minimizes the amount of actual programming you'd need to do, so you basically only need to worry about the small amount of programming logic necessary to implement the unique specifics of your games.


RPGs are perhaps reasonable for this, as mechanically they can be rather simple and rather involve lots of content production, which is a thing you can handle without being a programmer yourself. Content production still takes time, though, so be careful to temper the scope of your first game.

#5241536 Working on C++ Visual Studio projects across multiple PCs?

Posted by Josh Petrie on 20 July 2015 - 09:23 AM

Github or similar source control systems are generally the solution to this; they offer superior change tracking and control than Dropbox, especially when you have to deal with merging simultaneous changes from more than one developer. If you're just one person, Dropbox or Google Drive should work fine. 

Your actual problem is somewhat orthogonal:


sometimes the project will include a library or header file that is somewhere else relative to the project, or it will need to include an entire library such as boost




Version control won't solve this, this is purely a project organizational issue. Your dependencies (libraries you use) for a project should usually be part of that project. I usually stick them in an "External" or "Dependency" folder. Then you can set up your VS projects (or whatnot) to refer to them via relative paths and they will always be correct on any machine. This is useful because it also lets you use different versions of common libraries for different projects, if you need to, and to make sure that you can build with minimal fuss from a single checkout.

The general exception to this guideline is really large dependencies, such as the DirectX SDK, which you cannot legally redistribute or which are too large to reasonable self-host. For those, you should generally set up paths using environment variables or find the appropriate paths via "configure"-like scripts that are run once on each fresh checkout of a project prior to building.

#5241533 Is formal education in Programing/Arts obligatory for game designers?

Posted by Josh Petrie on 20 July 2015 - 09:17 AM

Am I doomed to never find a job in game design companies?




Game design is generally considered a different area of the field from game programming; which is it you're interesting in?


Finding a job as a programmer without a degree in a field generally considered directly related might be slightly harder, primarily because you're likely to be relatively less-familiar with programming if you've only started studying it post-degree than somebody who was using it during their degree, and due to a slightly increased chance of failing a resume filter for not having the "right" degree. 


You can overcome these downsides with a strong portfolio that demonstrates you do have programming ability, at which point your non-traditional degree may become an asset (suggesting a more well-rounded potential employee).


So no, it's not impossible at all.

#5241084 Good C++ engines?

Posted by Josh Petrie on 17 July 2015 - 12:07 PM

as I can't install Microsoft Visual studio in my computer



Why not? That information may be relevant to suggesting technology.


With its own compiler also please



Engines don't usually include entire compilers in their toolchain unless they also offer a specialized languages; they may ship with pre-built libraries or installation packages supporting one compiler or another, and as such may be more easy to set up with Code::Blocks versus Visual Studio (or whatever). But generally the compiler is orthogonal to the issue of which engine you'll use. 


What C++ development environment do you currently use, if not Visual Studio?

#5240922 Help me to clear up my confusion about OpenGL

Posted by Josh Petrie on 16 July 2015 - 04:28 PM

Since this is the OpenGL forum, let's please keep the discussion to constructive commentary on OpenGL and not derail it overmuch with "you should use this thing instead" sideswipes.

#5240921 [Solved] Resizing window eventually makes program run out of memory.

Posted by Josh Petrie on 16 July 2015 - 04:26 PM

So, sorry for making you waste your time. This problem is solved. Thank you.


You can add a column for GDI objects in the task manager (view -> select columns, check GDI objects). Occasionally useful for this kind of thing.

#5240544 Online University for Teaching Game Development ?

Posted by Josh Petrie on 15 July 2015 - 12:05 PM

I don't necessarily think you need to enroll in an online game development school for that (particularly as such schools tend to be dubious at best); perhaps a place like lynda.com might be better, some place where you could pick and choose the videos you watched to tailor them to what you want to learn. It doesn't sound like you want to find an online school for the degree, rather you just want to learn things to work on your project, so you should probably stay away from "schools" and look more for places that just have individual video lessons (which I presume you expect you learn better from than written tutorials and the like).


What about the documentation resources provided to you with the Unreal Engine have you found lacking?

#5240500 Online University for Teaching Game Development ?

Posted by Josh Petrie on 15 July 2015 - 09:25 AM

Why? What is your goal?

#5240322 How do game designers communicate?

Posted by Josh Petrie on 14 July 2015 - 02:21 PM

Six years isn't that long at all, and if it's six year spent exclusively designing within a very narrow space, I wouldn't really rate his opinion particularly high as far as being reflective of the rest of the industry.

#5240291 Moving from MonoGame to SharpDX/SlimDX

Posted by Josh Petrie on 14 July 2015 - 11:45 AM

Read the DirectX documentation on MSDN; since both APIs are just wrappers, it will all apply and even if you don't know C++ very well it should be fairly obvious what the structures/functions map to in C#. 


Note that SlimDX doesn't actually have D3D12 support yet.

#5240266 How to send boost::archive::text_oarchive with socket?

Posted by Josh Petrie on 14 July 2015 - 10:01 AM

There are some problems with this code.. I don't want to create a file "text.txt".. But I serialization step crashes if I create the fs as ofstream fs(nullptr);.


text_archive takes an ostream, not neccessarily an ofstream. The latter is an "output file" stream, and consequently if you don't want to create a file, you shouldn't use an "output file" stream; ofstream expects a valid filename in the constructor, which nullptr isn't, thus the crashes.
As fastcall says, an ostringstream or some other ostream implementation that doesn't involve file IO is probably want you want.

#5240264 Has anyone got a feeling of this when you were starting as game developer?

Posted by Josh Petrie on 14 July 2015 - 09:52 AM

Practically speaking you are almost always going to be building on the stuff other people before you have built. There is nothing wrong with that, and while it's a useful attitude to have to a degree, because it can drive you to explore how the "next level down" the abstraction stacks works (and thus gain a greater understanding), it can also be a pitfall. It can also lead you to travelling too far down that stack to build your own versions of things that really you have no business bothering with because they're just tangential and unrelated to the core values of your projects.


Build what is important to your project and what will set it apart. Buy the rest.


A practical example of how dangerous this attitude can get is the Handmade Hero project. A very interesting academic exercise, but the amount of time spent during that project on "reinventing" stuff at a relatively unclear boundary is astounding, and it shows in the amount of the time the project has gone on versus the currently available product. Nobody whose goal is actually to produce a game should be operating like that.


You should thus find a way to tame this feeling of yours, so you can let it guide you where it's important but know when to stop, look at the bigger picture, and say "I don't really need to be inventing my operating system to write this game."

#5240259 What game engine should I use?

Posted by Josh Petrie on 14 July 2015 - 09:36 AM

FIFE (the Flexible Isometric Free Engine) is designed around isometric games, mainly, unlike other more general-purpose options. This means it will help deal specifically with a lot of annoyance you might otherwise have building the "isometric" aspects of a game in a more general 2D or 3D engine. It comes with editing tools, like a map editor, saving you from having to build or repurpose one.


Originally it was designed to emulate the early Fallout games (one of the F's used to stand for Fallout). I see it now supports top-down maps, which is new last time I checked on it; one of the developers used to be a regular in #gamedev.


It's a very mature engine, having been around much longer than Unity and the like, and is still actively maintained.

#5240130 How do game designers communicate?

Posted by Josh Petrie on 13 July 2015 - 02:59 PM

A lead game designer that I'm working with claims that game designers simply write GDD and submit it to the programmers who read it and program based on the document. Is that true?



Hahah, no. That is a massive oversimplification at best, and if this person serious believes that's an ideal way to get anything done I would consider that a huge red flag.


Game development is ideally an iterative process; while designers might come up with initial plans and designs, there should be a constant feedback loop between the designers and the programmers (and the artists, QA, and everybody involved). This enables refinement and shared understanding that's critical to have, especially in such a creative industry. 


Every studio I've worked at that was not totally dysfunctional worked this way; how exactly this communication happens may vary (email/Slack/Flowdock/turning around at your desk and talking/etc), but it should always exist and continue up until (and maybe after) each feature ships.

#5239749 [SlimDX] Information on the history of SlimDX

Posted by Josh Petrie on 11 July 2015 - 10:07 AM

We used IRC to collaborate quite a lot; this means most of our really interesting technical conversations are probably lost to the ages, unless one of the #gamedev IRC regulars could be convinced to dig up archived logs from that era and look for SlimDX references.


I wrote about some of the technical issues we ran into on my old blog. One of the longer-reaching problems we had, in my opinion, was with object lifetime. We used IDisposable as a convenient way to wrap the COM reference counting semantics, but this ended up being a bad idea because the concepts did not map 1:1, even after we implemented an object table holding all the SlimDX object references to ensure we kept only a single reference count. We also had some second thoughts about making a huge, monolithic DLL as well, which we could alleviate if we also chose to implement more interfaces instead of concrete classes.


Our decision to hand-wrap everything in C++/CLI also became rather tedious after a while, which leads us to SlimDX 2 and SharpDX, which I'll touch on later.


One year, Mike made us SlimDX mugs (I think this was for Christmas?). They looked like this:




The spaceship is from our Asteroids sample. The line and file count metrics are almost certainly wrong now.




Our logo and names.




This is the best part. The triangle is from our MiniTri sample. The code is probably our favorite bug we ever had in the project. It's certainly mine, at least.


  • Where there any interesting dynamics when 3rd party game studios used SlimDX in their games?


Not that I recall. It was really cool to discover that studios were using it for various reasons, and even now I still smile when I see it in the distributions of various bits of middleware. There was one incident where we noticed that somebody was distributing the DLL incorrectly (they didn't include the license text file), but I don't think we bothered to do anything about it. 


It has opened quite a few doors for us, in various ways. It was the primary motivating reason (as far as I know) for Promit and I to get Microsoft MVP awards in the DirectX and/or C++ areas for several years. We've all gotten some commercial or contracting work out of it at one point or another, and it makes for interesting interview talking points when you run into people who have used it (which is still surprisingly often, for me at least). It was a pretty great time.


What's the story with SharpDX?



For me, SharpDX was a very interesting lesson in properly stewarding your open-source projects. 


While we were thinking about what we wanted to do for a "version 2" of the SlimDX API, one of the issues the amount of boilerplate hand-maintained C++/CLI we had to write for everything. Alexandre (who heads up SharpDX) had published a blog post detailing a process for parsing the DX SDK headers and generating interop stubs that could be used to save most of the tedious work. We thought this was a cool idea and asked him if he'd like to help us work on SlimDX and leverage that idea. He agreed, and we gave him commit access to the repository. 


What we should have done was spend more time talking with him about our vision for the project, and his own, as well as other mechanical stuff like our coding standards and philosophy towards building and organizing a project. The three of us had largely never had an issue in that area, being able to immediately discuss things with each other on IRC and having all of us started on the project in its infancy. Bringing somebody new on so much later, he didn't have any of that background or integration or guidance - and we failed to provide it for him - and so he naturally did what he assumed we wanted him to do and started making huge sweeping changes to roll his prototype work into SlimDX in ways we didn't expect or necessarily approve of. We didn't have GitHub back then, there was no reviewing of pull requests, you just checked right in. 


After some rather tense emails and rollbacks it quickly became apparent that we'd all kind of screwed up this relationship, but the damage was done at that point and Alex decided to go off on his own with SharpDX; and at that point I think we all wanted him to. We were all pretty fed up and the whole experience left a pretty bad taste in everybody's mouth. It's a shame, because we could have handled it so much better.


How have the rise of other .NET based game engines (mostly Unity, it would appear) affected interest in SlimDX?


It's hard to tell, since they go for different demographics, and also because many of the technology in question has come along after vigorous active development on SlimDX ended. Microsoft put D3D into a sort of extended hibernation after the June 2010 SDK, and not much new happened, and so consequently we didn't have much work to do on the API beyond the occasional bug fix. It was basically a "finished product," with a few bits and pieces that could have been shorn up (primarily Windows 8 support) but nobody was particularly interested in doing those because of the generalized lack of interest in Windows 8. 


We did start prototyping our ideas for SlimDX 2, which included a variant of Alex's interop generation. I was never particularly pleased with how much manual drudgery was still required after parsing the headers, and I started to lose interest in the project once I'd implemented what I thought was the interesting bit (the interop trampolines). Eventually I stepped away from the project to work on other stuff, as I was rather burnt out on the project in general by then, and wasn't very actively developing things on Windows at the time anyway.


Plans for the future?


I too have heard Promit make overtures about D3D12 support in some lighter-weight form, but I also know he's super busy so I'm not sure if and when that will materialize.